Os perigos da dependência de código de terceiros

Existem algumas coisas realmente boas sobre o modo como o software funciona na Internet. Para começar, há uma enorme rede não oficial de milhões de pessoas contribuindo para um enorme repositório de fragmentos de código que ajudam a alimentar mais milhões de aplicativos.

Toda vez que você vê um pequeno link na parte inferior de uma página da Web que diz “Powered by So-So-So”, você está testemunhando esse efeito colaborativo em ação.

E, claro, a principal razão pela qual as pessoas gostam desse compartilhamento e colaboração de terceiros é que ele pode economizar muitas horas em tempo de desenvolvimento, porque você não está reinventando algo que já existe. Mas mesmo com esses grandes benefícios do sistema de compartilhamento de código de terceiros, há vários motivos pelos quais você pode querer evitar o uso desses fragmentos de código, como estamos prestes a ver…

1.Possíveis riscos de segurança

Como praticamente todo o código que impulsiona qualquer coisa na Web é de código aberto, é justo apostar que, se houver alguma carga maliciosa em um determinado aplicativo, ela será rapidamente descoberta pela comunidade de desenvolvedores e rapidamente corrigida.

Mas muitos desses fragmentos de código são baixados centenas ou até milhares de vezes por dia, e nem toda equipe administrativa está fazendo um bom trabalho em manter um sistema seguro de compartilhamento de código.

Quanto maior e mais complexo for um aplicativo, mais fácil será infectá-lo adicionando algumas linhas de código em algum lugar obscuro. Quase ninguém leva tempo para investigar cada linha de código em um aplicativo, porque geralmente eles assumem que o código pode ser confiável.

Um programador altamente qualificado pode geralmente fazer um bom trabalho de ofuscar a natureza maliciosa do código, e apenas outro programador altamente qualificado descobrirá qual é o seu propósito… se o fragmento de código malicioso for detectado.

2. Você não é dono

Esta é realmente uma combinação de problemas. A primeira é que você pode estar sujeito a vários termos de licenciamento. Quando você tem vários fragmentos de código usados ​​em uma única página da Web ou aplicativo, você pode estar sujeito a vários termos e condições de licenciamento diferentes, e alguns deles podem estar em conflito entre si.

É claro que dificilmente alguém se incomoda em ler essas listas tediosas de termos e condições, mas isso pode ser um erro. Em particular, seria um erro se alguma condição no contrato de licença fizesse com que você viole alguma lei em seu país de origem ou no país em que seu servidor está localizado.

A outra questão é que, se você não possui código, você não tem controle sobre ele, e você pode não necessariamente entender tudo o que ele faz ou como funciona. Isso significa que, se alguém fizer alguma alteração no código, poderá ficar com essa alteração, especialmente se você instalar atualizações, correções, atualizações e novas versões com fidelidade, assim que forem lançadas como estáveis, ou se depender totalmente da entrega de conteúdo. redes para suas soluções de terceiros.

3. Você frequentemente consegue muito mais do que precisa

O código de terceiros geralmente funciona para fazer o trabalho que você quer, mas às vezes ele contém todos os tipos de recursos extras que você não precisa e provavelmente nunca usará. Em alguns casos, você não pode remover esses recursos extras com facilidade ou mesmo em tudo. Você também pode ter que comprometer. O recurso pode fazer algo muito próximo do que você pretende, mas não exatamente o que você pretende. Você está negociando a grandiosidade por ter menos trabalho a fazer, e isso nem sempre é um bom negócio.

4. Múltiplos níveis de dependência de terceiros podem levar a problemas reais

Muitos projetos de código aberto usam os mesmos fragmentos de código de terceiros de maneiras diferentes para produzir seu software. Na maioria das vezes isso não é uma coisa ruim, mas pode levar a problemas. Atualmente, muitos desenvolvedores nem instalam os fragmentos que estão usando, mas os instalam em tempo de execução de redes de distribuição de conteúdo sob demanda. O perigo disso foi ilustrado de forma espetacular pelo Incidente do Left-Pad de 2016.

Cada cadeia é tão forte quanto seu elo mais fraco. Esse encadeamento de dependências significa que, se algum link em algum lugar ao longo da cadeia for quebrado ou comprometido, toda a cadeia estará em risco de mau funcionamento. Em algumas situações isso pode ser muito caro. Ninguém suspeitaria do poder contido nas linhas de código 11 contidas naquela pequena função benigna chamada Left-Pad, mas quando esse elo da cadeia falhava, ele fazia com que muitos grandes sites parassem de funcionar. A maior parte disso era que a maioria das pessoas que usavam o Left-Pad não fazia ideia de que estavam usando, o que ele fazia ou como resolver o problema. Como declarado no item 2, se você não for o proprietário, você pode não necessariamente entendê-lo.

O Left-Pad era uma função muito simples que apenas adiciona alguns espaços ao lado esquerdo de uma linha para garantir que a linha tenha o tamanho correto. Agora, a questão aqui é que qualquer programador competente poderia replicar essa funcionalidade facilmente. Não há absolutamente nenhuma necessidade de qualquer aplicativo depender dessa função de terceiro e, no entanto, milhares de sites estavam usando software que o incluía, incluindo Netflix, Facebook e Reddit. Foi apenas um golpe de sorte que, neste caso, foi uma função muito simples que quebrou a cadeia, e não uma função realmente complicada que tinha sua própria cadeia de dependências.

A linha inferior é se você pode construir você mesmo, você provavelmente deveria!

Em última análise, a decisão sobre o uso de blocos de código de terceiros em seu projeto se resume a uma série de decisões complicadas que nunca devem ser tomadas de ânimo leve. Os fatores que você precisa considerar são segurança, legalidade, custo, tempo e estabilidade.

Para tornar o processo de decisão mais simples, a seguinte condição de teste provavelmente ajudará.

SE qualquer um desses fatores for verdadeiro:

  • a função que você quer é simples
  • você (ou sua equipe) tem a capacidade de criar a função
  • há muito tempo para criar a função
  • sua aplicação precisa de boa segurança
  • você tem preocupações sobre possíveis problemas legais associados ao licenciamento de terceiros
  • é importante que seu aplicativo nunca falhe

Então você deve construir você mesmo,

Talvez seja mais eficiente usar as funções de terceiros, desde que você esteja ciente dos possíveis problemas e tenha uma estratégia em vigor para o que você fará se esses problemas surgirem.

imagem de cabeçalho cortesia de Stephanie Tucker

Bogdan Rancea

Bogdan é um membro fundador da Inspired Mag, acumulando quase 6 anos de experiência neste período. Em seu tempo livre, ele gosta de estudar música clássica e explorar artes visuais. Ele é muito obcecado com fixies também. Ele é dono do 5 já.