Supply Chain de Software: O Vetor de Ataque que Cresceu 742% em Três Anos
O Log4Shell, descoberto em dezembro de 2021, afetou estimados 3 bilhões de dispositivos em todo o mundo. A vulnerabilidade estava em uma biblioteca open source usada em dezenas de milhares de aplicações — muitas delas em organizações que nunca tinham ouvido falar do Log4j antes da crise. Não importava o nível de sofisticação do time de segurança: se o software que você comprou, contratou ou baixou usava a biblioteca, você estava exposto.
Esse é o risco de supply chain de software em sua forma mais pura: a vulnerabilidade não está na sua organização, não está no fornecedor direto, mas em um componente que o fornecedor do fornecedor usa. E você só descobre quando já é tarde.
Por que os ataques de supply chain crescem mais rápido que os ataques diretos
A lógica é econômica. Uma empresa grande com equipe de segurança madura pode ter defesas robustas: EDR avançado, SOC 24x7, segmentação de rede, autenticação multifator universal. Atacá-la diretamente é caro e incerto.
Mas essa mesma empresa usa 50, 100, 200 fornecedores de software. Cada um deles é uma superfície de ataque potencial — e muitos têm acesso privilegiado aos sistemas da empresa: agentes de monitoramento com acesso root, pipelines de CI/CD com credenciais de deploy, integrações de API com acesso a dados de clientes. Comprometer um desses fornecedores é comprometer todos os seus clientes simultaneamente.
O relatório Sonatype de 2023 documentou 245.032 ataques maliciosos a repositórios de software open source — um crescimento de 742% em relação a 2020. Não é tendência. É uma mudança estrutural no cenário de ameaças.
O que torna supply chain de software diferente de TPRM tradicional
TPRM tradicional avalia o fornecedor como uma organização: seus processos, suas políticas, sua postura de segurança geral. Supply chain de software exige um nível adicional: avaliar o que o fornecedor entrega — o código, as dependências, os componentes — não apenas como ele opera.
Um fornecedor pode ter ISO 27001, processos de desenvolvimento seguro (SSDLC) documentados e equipe de segurança competente — e ainda assim entregar software com uma dependência vulnerável no terceiro nível da árvore de dependências, porque ninguém mapeou até lá.
SBOM: visibilidade como primeiro controle
Software Bill of Materials (SBOM) é o inventário de todos os componentes de um software — bibliotecas, dependências diretas e transitivas, suas versões e licenças. É o equivalente de um rótulo de ingredientes para software. O executivo americano Joe Biden assinou em 2021 uma ordem executiva tornando SBOM mandatório para software adquirido pelo governo federal dos EUA. A tendência regulatória é global.
Para gestores de risco, a questão prática é: seus fornecedores críticos de software conseguem fornecer um SBOM? E você tem processo para cruzar esse SBOM com bases de vulnerabilidades (NVD, OSV, CISA KEV) de forma contínua — não apenas na contratação?
Controles prioritários para gestores de risco
Além do SBOM, os controles com maior retorno para mitigação de risco de supply chain de software incluem: (1) Segregação de acesso de fornecedores — nenhum agente de terceiro deve ter acesso mais amplo do que o estritamente necessário para sua função. (2) Monitoramento de integridade de atualizações — verificar assinaturas digitais de pacotes e updates antes de aplicar em produção. (3) Detecção de anomalias em pipelines — identificar comportamentos atípicos em processos de CI/CD que podem indicar comprometimento. (4) Plano de resposta específico para incidentes de supply chain — que é diferente de um incidente convencional, porque o vetor inicial está fora do seu perímetro de controle.