Cadeia de suprimentos de software: o risco que se herda

Quase toda discussão de segurança começa pelo perímetro: quem entra, o que passa, o que é bloqueado. Existe, porém, uma categoria de risco que atravessa qualquer perímetro por convite — porque você mesmo instalou, com as suas credenciais, no seu pipeline, e confiou por definição.

É a cadeia de suprimentos de software. E ela cresceu de forma desconfortável: os ataques mais que dobraram globalmente em 2025, com mais de 70% das organizações relatando ao menos um incidente ligado a software de terceiros. Só em 2025 foram identificados mais de 454.600 novos pacotes maliciosos, levando o acumulado histórico a ultrapassar 1,2 milhão.

A tese em uma frase: você não escolhe a maior parte do código que roda na sua empresa — ele chega por dependência transitiva, atualização automática e imagem base — e a defesa não é revisar o que é impossível revisar, é reduzir o que um componente comprometido consegue fazer.

Por que o ataque à cadeia de suprimentos é tão eficiente

Três características o tornam desproporcionalmente rentável para quem ataca.

A confiança é automática. O seu pipeline baixa e executa a dependência sem revisão humana, com as mesmas permissões do seu código. Não há decisão a ser tomada — o processo foi desenhado para não ter fricção, e é essa ausência de fricção que o ataque usa.

Você não escolhe a maior parte do que instala. Uma aplicação moderna declara algumas dezenas de dependências diretas e acaba com centenas de transitivas — dependências das dependências. Ninguém auditou aquele pacote de três linhas que faz uma coisa trivial e que foi puxado por um framework que você escolheu por bons motivos.

O retorno escala. Comprometer uma empresa rende uma empresa. Comprometer um pacote que dez mil empresas usam rende dez mil, e o atacante escolhe depois quais valem a pena.

Os vetores mais comuns: conta de mantenedor comprometida (frequentemente por infostealer, o que fecha um círculo desagradável), typosquatting — publicar um pacote com nome parecido com um popular —, invasão da infraestrutura de build e dependência abandonada cujo domínio ou conta é assumido por outra pessoa.

Vale notar que isso não é exclusividade do open source. A infraestrutura de distribuição de firmware que acelerou o crescimento da botnet Aisuru é o mesmo tipo de ataque, aplicado a dispositivo: o aparelho baixou o malware da atualização oficial.

SBOM: o inventário que responde a pergunta certa

Quando uma vulnerabilidade grave é divulgada, existe uma pergunta simples que a maioria das empresas leva dias para responder: "a gente usa isso?".

O SBOM (Software Bill of Materials) existe para tornar essa resposta instantânea. É um inventário legível por máquina de todos os componentes de um software, com versões — a lista de ingredientes.

Duas coisas que o SBOM não faz, e que a expectativa exagerada costuma atribuir a ele:

• Ele não diz se você está vulnerável, só se o componente está presente. Presença não é exploração: o código pode estar lá e nunca ser chamado.
• Ele não se mantém sozinho. SBOM gerado uma vez e guardado numa pasta é documentação morta; ele precisa ser gerado a cada build, senão descreve um software que não existe mais.

Feita essa ressalva, é a peça que falta na maioria das empresas — e o custo de adotar é baixo. As ferramentas são gratuitas e a integração ao pipeline leva uma tarde.

Complementarmente, o SLSA é um framework que trata da integridade do processo de build, com níveis graduados — do registro básico de proveniência até plataformas endurecidas com proveniência à prova de adulteração. SBOM responde "o que tem dentro"; SLSA responde "dá para confiar em como isso foi construído".

O que a regulação já exige

Este assunto saiu do campo das boas práticas.

SBOMs já são exigidos pela Ordem Executiva 14028 nos EUA, pelo Cyber Resilience Act europeu e por diretrizes da FDA para dispositivos médicos.

O CRA é o que mais deve afetar empresa brasileira que exporta ou vende software para a Europa, e o calendário é curto:

• A partir de setembro de 2026: obrigação de reportar vulnerabilidades ativamente exploradas e incidentes graves.
• Até dezembro de 2027: conformidade completa — documentação, controles de segurança ao longo do ciclo de vida e SBOM.
• Retenção de dez anos da documentação de segurança após a colocação do produto no mercado.

Note a diferença de filosofia em relação ao debate brasileiro. O CRA regula o produto e quem o fabrica; o Marco Legal da Cibersegurança em discussão no Senado foca em quem opera infraestrutura crítica. São recortes complementares, e o Brasil só está discutindo um deles — argumento que desenvolvi no post sobre quem deve comandar a cibersegurança no Brasil.

Para quem só consome software, o efeito prático chega por contrato: clientes regulados vão passar a pedir SBOM e evidência de processo. Nesse momento, isso deixa de ser risco técnico e vira requisito comercial.

Por onde começar

Em ordem de retorno sobre esforço, e assumindo equipe pequena.

1. Fixar versão. Instalar sempre a última versão automaticamente em produção transforma qualquer publicação maliciosa em deploy imediato. Use arquivo de lock, fixe versão, e faça a atualização passar por revisão e por um intervalo de espera. A janela entre a publicação de um pacote malicioso e a sua remoção do repositório costuma ser curta — esperar alguns dias antes de adotar uma versão nova elimina boa parte do risco de graça.

2. Gerar SBOM no build. Ferramentas gratuitas, integração de uma tarde. Guarde o SBOM junto com o artefato, não numa pasta separada.

3. Tirar segredo de longa duração do pipeline. Este é o item de maior impacto e o menos óbvio. Um build comprometido que encontra credencial permanente — chave de nuvem, token de registro, senha de banco — transforma um incidente de dependência num incidente de infraestrutura. Segredo de vida curta, emitido sob demanda, torna o roubo inútil. É a mesma lição do post sobre ataques agênticos.

4. Restringir o que o build pode fazer. O pipeline não precisa de acesso irrestrito à internet nem de permissão de administrador na nuvem. Menor privilégio aplicado ao CI é raro e barato.

5. Escanear dependências continuamente, não uma vez. O pacote que era seguro no build de ontem pode ter uma vulnerabilidade divulgada hoje. O valor está na repetição.

6. Reduzir a superfície. A dependência mais segura é a que não existe. Vale perguntar, antes de adicionar: isso justifica o risco de manutenção e de comprometimento? Nem toda função de três linhas precisa vir de fora.

Para quem não desenvolve software

Se a sua empresa apenas usa, três medidas continuam valendo:

• Atualização também é vetor. O caso do firmware da botnet mostra que "sempre atualize" precisa de uma emenda: atualize de fonte oficial, e desconfie de atualização que chega por canal diferente do habitual.
• Inventarie os fornecedores de software. É a versão corporativa do SBOM: quais sistemas de terceiros têm acesso aos seus dados e à sua rede, e o que acontece se um deles for comprometido.
• Coloque a cláusula no contrato. Prazo de notificação de incidente do fornecedor para você. Se ele for comprometido, você precisa saber antes do seu cliente.

O ponto que fica

A cadeia de suprimentos é o lugar onde a segurança encontra um limite honesto: não dá para auditar o que você não escreveu, e a quantidade torna a revisão impossível. Quem promete resolver isso com uma ferramenta está vendendo tranquilidade, não segurança.

O que sobra é uma estratégia diferente — em vez de tentar garantir que nada malicioso entre, reduzir o que um componente malicioso consegue fazer quando entrar. Versão fixa, SBOM gerado a cada build, segredo efêmero, pipeline com menor privilégio.

É a mesma lógica que atravessa quase tudo em segurança moderna: você não controla a entrada, controla o alcance.