Os riscos ocultos nas dependências de código aberto

Os patches do php2shell (CVE-2026-109618 e CVE-2026-109619) para o PHP em fim de vida (EOL) já estão disponíveis. Como as respostas do atendimento de vendas estão mais demoradas do que o normal devido à alta demanda, a maneira mais rápida de obter os pacotes corrigidos é adquirir o ELS para Runtimes on-line (abre em uma nova aba). Leia as perguntas frequentes sobre os patches

Vá direto para um resumo gerado por IA desta postagem do blog

  • Resuma esta postagem com o Perplexity
  • Resuma esta postagem com o Gemini

A maioria dos desenvolvedores acredita que os problemas de segurança decorrem de código mal escrito.

Um recurso desenvolvido às pressas, uma verificação de validação que ficou de lado, uma tarefa pendente que se arrastou por muito tempo… a história que costumamos contar a nós mesmos é simples: se escrevermos um código melhor, a segurança melhora.

Essa história fazia fazia sentido. Hoje, está incompleta.

As aplicações modernas raramente falham porque os engenheiros, de repente, se esqueceram de como escrever software seguro. Elas falham porque o risco agora vem embutido nos componentes dos quais dependemos — bibliotecas, frameworks, SDKs e utilitários provenientes do ecossistema de código aberto. Grande parte do código executado dentro de uma aplicação em produção nunca foi escrito pela equipe que a opera.

Essa é a ideia por trás do nosso novo e-book, O Cavalo de Tróia no Seu Código: Protegendo Dependências Transitivas e Riscos Herdados em Software de Código Aberto.

O livro explora uma mudança que muitas equipes de engenharia e segurança estão apenas começando a compreender plenamente: no software moderno, o risco costuma ser herdado, e não criado.

O risco que vem junto com suas dependências

Pense na última vez que você instalou uma biblioteca.

Você executou o comando `npm install`, `pip install` ou adicionou uma nova dependência ao seu projeto. Em questão de segundos, o gerenciador de pacotes baixou a biblioteca que você queria e instalou discretamente tudo o que era necessário para sua execução.

Por trás dessa instalação rápida, no entanto, algo muito maior aconteceu. Uma única dependência geralmente traz consigo todo um grafo de componentes adicionais — subdependências, utilitários, bibliotecas auxiliares e ferramentas que sua equipe nunca avaliou diretamente. Esses componentes podem, por sua vez, depender de outros, criando uma cadeia de execução profundamente aninhada que pode conter centenas de pacotes.

Visto de fora, parece que você adicionou uma biblioteca.

Na verdade, é possível que você tenha importado toda uma cadeia de suprimentos.

É por isso que o e-book usa a metáfora do Cavalo de Tróia. Você introduz intencionalmente uma ferramenta confiável em seu sistema porque ela resolve um problema e acelera o desenvolvimento. Mas, dentro dessa ferramenta, há outros componentes que você não convidou explicitamente. Eles chegam automaticamente, ocultos por trás da conveniência dos ecossistemas modernos de pacotes.

Na maioria das vezes, isso funciona exatamente como se espera. O código aberto acelera a inovação e permite que as equipes criem sistemas muito mais sofisticados do que poderiam por conta própria. Mas isso também significa que uma parte significativa da superfície de ataque do seu aplicativo provém de código que sua equipe nunca revisou.

As partes mais profundas da árvore

Uma das dinâmicas mais interessantes nas cadeias de suprimentos de software modernas é onde o risco tende a se acumular.

As dependências reconhecidas pelos desenvolvedores — frameworks populares e bibliotecas amplamente utilizadas — recebem atenção constante. Elas contam com grandes comunidades, atualizações frequentes e muitos olhos atentos às vulnerabilidades.

Mas, à medida que nos aprofundamos na árvore de dependências, a visibilidade diminui rapidamente.

Essas camadas mais profundas costumam ser pequenas bibliotecas utilitárias que lidam com tarefas como análise de strings, formatação de datas ou gerenciamento de auxiliares internos para outros pacotes. Elas podem ser mantidas por um único desenvolvedor, atualizadas com pouca frequência ou herdadas discretamente por milhares de aplicativos por meio de frameworks de origem.

No entanto, elas são executadas no mesmo ambiente de execução que todos os demais componentes do seu aplicativo.

O resultado é uma espécie de ponto cego de segurança: as partes da pilha com menor visibilidade ainda podem influenciar o comportamento de todo o sistema.

Nosso e-book explora como essa dinâmica de “árvore profunda” gera riscos herdados que muitas equipes têm dificuldade em identificar com clareza — mesmo quando utilizam ferramentas de segurança padrão.

Por que corrigir um risco herdado é mais difícil do que criá-lo

Adicionar dependências é fácil. Eliminar os riscos associados a elas, não.

Quando uma vulnerabilidade é descoberta nas camadas mais profundas de uma árvore de dependências, o código afetado pode já estar incorporado em artefatos de compilação, imagens de contêiner e implantações em produção. A atualização do componente pode exigir alterações coordenadas em frameworks, plug-ins e serviços internos.

Nesse ponto, a correção deixa de ser um simples remendo. Torna-se uma decisão operacional mais ampla, que envolve estabilidade, compatibilidade e o momento do lançamento.

Essa tensão é uma das razões pelas quais as vulnerabilidades herdadas podem persistir por mais tempo do que qualquer um gostaria. A dificuldade não é que as equipes as ignorem; é que corrigi-las com segurança muitas vezes exige lidar com as realidades dos sistemas de produção.

O livro analisa como essas dinâmicas se manifestam em ambientes reais e por que as orientações tradicionais de segurança às vezes não levam isso em conta.

Entendendo o sistema com clareza

Desenvolver com código aberto significa aceitar que os aplicativos não são mais apenas conjuntos de códigos escritos pela sua equipe. São ecossistemas de componentes interconectados, cada um com seu próprio histórico de manutenção, postura de segurança e ciclo de vida.

Compreender esse ecossistema — e como os riscos se propagam por ele — está se tornando uma das competências mais importantes tanto para desenvolvedores quanto para equipes de segurança.

O e-book explora como o risco herdado se comporta de maneira diferente da dívida técnica tradicional, por que as árvores de dependência tornam as vulnerabilidades mais difíceis de detectar e remover e como as organizações podem reduzir a exposição sem desestabilizar os sistemas dos quais dependem.

Uma olhada por dentro do Cavalo de Tróia

Se você já se perguntou como as vulnerabilidades ocultas nas camadas mais profundas das pilhas de dependências acabam influenciando incidentes de segurança no mundo real, este e-book oferece uma análise detalhada dos mecanismos por trás desse fenômeno. Desde a ilusão da verificação de dependências até os desafios operacionais de eliminar riscos herdados, ele traça o caminho que as vulnerabilidades percorrem, desde bibliotecas ocultas até ambientes de produção.

E, talvez o mais importante, o artigo explora como as equipes podem repensar as estratégias de segurança em um mundo em que controlar cada linha de código não é mais viável.

Porque, em softwares modernos, as vulnerabilidades mais perigosas da sua pilha de tecnologia podem não ser aquelas que você mesmo criou.

Talvez sejam os que vieram junto com o produto.

Se você quiser conhecer a história completa, pode baixar o e-book aqui:

O Cavalo de Tróia no seu código: Protegendo dependências transitivas e riscos herdados em software de código aberto

O Cavalo de Tróia já está dentro da cidade. A questão é se você entende o que veio junto com ele.

 

Resumo
Os riscos ocultos nas dependências de código aberto
Nome do artigo
Os riscos ocultos nas dependências de código aberto
Descrição
A maioria das vulnerabilidades não é criada pela sua equipe. Elas surgem por meio das dependências. Conheça os riscos das dependências transitivas em nosso e-book.
Autor
Nome da editora
TuxCare
Logotipo da editora

Junte-se a mais de 4.500 profissionais de Linux e código aberto!

2 vezes por mês. Sem spam.

Índice
Obtenha as respostas sobre segurança de código aberto de que você precisa

Junte-se a mais de 4.500 profissionais de Linux e código aberto!

2 vezes por mês. Sem spam.