Pular para conteúdo

A03:2025 – Falhas na Cadeia de Suprimentos de Software icon

Contexto

Esta categoria foi a mais votada na pesquisa da comunidade para o Top 10, com exatamente 50% dos entrevistados classificando-a como a nº 1. Desde sua aparição inicial no Top 10 de 2013 como "A9 – Utilização de Componentes com Vulnerabilidades Conhecidas", o risco cresceu em escopo para incluir todas as falhas na cadeia de suprimentos (supply chain), não apenas aquelas que envolvem vulnerabilidades conhecidas. Apesar desse aumento de escopo, as falhas na cadeia de suprimentos continuam sendo um desafio para identificação, com apenas 11 vulnerabilidades (CVEs) possuindo as CWEs relacionadas. No entanto, quando testada e reportada nos dados contribuídos, esta categoria apresenta a maior taxa média de incidência, de 5,19%. As CWEs relevantes são CWE-477: Use of Obsolete Function, CWE-1104: Use of Unmaintained Third Party Components, CWE-1329: Reliance on Component That is Not Updateable e CWE-1395: Dependency on Vulnerable Third-Party Component.

Tabela de Pontuação

CWEs Mapeadas Taxa Máx. de Incidência Taxa Média de Incidência Cobertura Máxima Cobertura Média Exploit Médio Ponderado Impacto Médio Ponderado Total de Ocorrências Total de CVEs
6 9.56% 5.72% 65.42% 27.47% 8.17 5.23 215,248 11

Descrição

Falhas na cadeia de suprimentos de software são interrupções ou outros comprometimentos no processo de construção, distribuição ou atualização de software. Frequentemente, são causadas por vulnerabilidades ou alterações maliciosas em códigos de terceiros, ferramentas ou outras dependências das quais o sistema depende.

Você provavelmente está vulnerável se:

  • Você não rastreia cuidadosamente as versões de todos os componentes que utiliza (tanto no lado do cliente quanto no servidor). Isso inclui componentes usados diretamente, bem como dependências aninhadas (transitivas).
  • O software é vulnerável, sem suporte ou desatualizado. Isso inclui o sistema operacional, servidor web/aplicação, sistema de gerenciamento de banco de dados (DBMS), aplicações, APIs e todos os componentes, ambientes de runtime e bibliotecas.
  • Você não realiza varreduras de vulnerabilidades regularmente e não assina boletins de segurança relacionados aos componentes que utiliza.
  • Você não possui um processo de gerenciamento de mudanças ou rastreamento de alterações em sua cadeia de suprimentos, incluindo o rastreamento de IDEs, extensões e atualizações de IDE, alterações no repositório de código da sua organização, sandboxes, repositórios de imagens e bibliotecas, a forma como os artefatos são criados e armazenados, etc. Cada parte da sua cadeia de suprimentos deve ser documentada, especialmente as mudanças.
  • Você não realizou o endurecimento (hardening) de cada parte da sua cadeia de suprimentos, com foco especial no controle de acesso e na aplicação do menor privilégio.
  • Seus sistemas de cadeia de suprimentos não possuem separação de funções (separation of duties). Nenhuma pessoa sozinha deve ser capaz de escrever o código e promovê-lo até a produção sem a supervisão de outro ser humano.
  • Componentes de fontes não confiáveis, em qualquer parte da stack tecnológica, são usados ou podem impactar ambientes de produção.
  • Você não corrige ou atualiza a plataforma subjacente, frameworks e dependências de maneira oportuna e baseada em riscos. Isso acontece comumente em ambientes onde o patching é uma tarefa mensal ou trimestral sob controle de mudanças, deixando as organizações expostas por dias ou meses a riscos desnecessários antes de corrigir as vulnerabilidades.
  • Os desenvolvedores de software não testam a compatibilidade de bibliotecas atualizadas ou corrigidas.
  • Você não protege as configurações de cada parte do seu sistema (consulte A02:2025 – Configuração Insegura).
  • Seu pipeline de CI/CD possui segurança mais fraca do que os sistemas que ele constrói e implanta, especialmente se for complexo.

Como Prevenir

Deve haver um processo de gerenciamento de patches para:

  • Gerar e gerenciar centralizadamente a Lista de Materiais de Software (SBOM – Software Bill of Materials) de todo o seu software.
  • Rastrear não apenas suas dependências diretas, mas também as transitivas, e assim por diante.
  • Reduzir a superfície de ataque removendo dependências não utilizadas, recursos desnecessários, componentes, arquivos e documentação.
  • Inventariar continuamente as versões de componentes tanto do lado do cliente quanto do servidor (ex: frameworks, bibliotecas) e suas dependências usando ferramentas como OWASP Dependency Track, OWASP Dependency Check, retire.js, etc.
  • Monitorar continuamente fontes como CVE (Common Vulnerability and Exposures), NVD (National Vulnerability Database) e Open Source Vulnerabilities (OSV) em busca de vulnerabilidades nos componentes utilizados. Use ferramentas de análise de composição de software (SCA), cadeia de suprimentos ou ferramentas de SBOM focadas em segurança para automatizar o processo. Assine alertas de vulnerabilidades de segurança relacionadas aos componentes que você usa.
  • Obter componentes apenas de fontes oficiais (confiáveis) através de links seguros. Prefira pacotes assinados para reduzir a chance de incluir um componente modificado ou malicioso (consulte A08:2025 – Falhas de Integridade de Software e Dados).
  • Escolher deliberadamente qual versão de uma dependência utilizar e atualizar apenas quando houver necessidade.
  • Monitorar bibliotecas e componentes que não possuem manutenção ou que não criam patches de segurança para versões antigas. Se a correção não for possível, considere migrar para uma alternativa. Caso não seja viável, considere implantar um patch virtual para monitorar, detectar ou proteger contra o problema descoberto.
  • Atualizar regularmente seu CI/CD, IDE e qualquer outra ferramenta de desenvolvimento.
  • Evitar a implantação de atualizações em todos os sistemas simultaneamente. Use implantações em estágios ou canary deployments para limitar a exposição caso um fornecedor confiável seja comprometido.

Deve haver um processo de gerenciamento de mudanças ou sistema de rastreamento para monitorar alterações em:

  • Configurações de CI/CD (todas as ferramentas de construção e pipelines)
  • Repositórios de código
  • Áreas de sandbox
  • IDEs de desenvolvedores
  • Ferramental de SBOM e artefatos criados
  • Sistemas de registro (logging) e logs
  • Integrações de terceiros, como SaaS
  • Repositórios de artefatos
  • Registros de contêineres

Realize o hardening dos seguintes sistemas, o que inclui habilitar MFA e restringir o IAM:

  • Seu repositório de código (o que inclui não armazenar segredos, proteger ramificações/branches e realizar backups).
  • Estações de trabalho de desenvolvedores (patching regular, MFA, monitoramento e mais).
  • Seu servidor de build e CI/CD (separação de funções, controle de acesso, builds assinados, segredos com escopo de ambiente, logs à prova de adulteração, entre outros).
  • Seus artefatos (garanta a integridade via proveniência, assinatura e carimbo de tempo; promova artefatos em vez de reconstruí-los para cada ambiente; garanta que os builds sejam imutáveis).
  • Infraestrutura como código (gerenciada como qualquer código, incluindo o uso de PRs e controle de versão).

Cada organização deve garantir um plano contínuo para monitoramento, triagem e aplicação de atualizações ou mudanças de configuração durante toda a vida útil da aplicação ou portfólio.

Exemplos de Cenários de Ataque

Cenário #1: Um fornecedor confiável é comprometido com malware, levando ao comprometimento dos seus sistemas de computador quando você realiza a atualização. O exemplo mais famoso disso é provavelmente:

Cenário #2: Um fornecedor confiável é comprometido de tal forma que se comporta de maneira maliciosa apenas sob uma condição específica.

Cenário #3: O ataque à cadeia de suprimentos Shai-Hulud em 2025 foi o primeiro verme (worm) npm autopropagável bem-sucedido. Os ataques inseriram versões maliciosas de pacotes populares, que utilizavam um script pós-instalação para coletar e exfiltrar dados sensíveis para repositórios públicos do GitHub. O malware também detectava tokens npm no ambiente da vítima e os utilizava automaticamente para publicar versões maliciosas de qualquer pacote acessível. O verme atingiu mais de 500 versões de pacotes antes de ser interrompido pelo npm. Este ataque foi avançado, de rápida propagação e danoso; ao visar máquinas de desenvolvedores, demonstrou que os próprios desenvolvedores são agora alvos principais em ataques de cadeia de suprimentos.

Cenário #4: Componentes normalmente rodam com os mesmos privilégios da própria aplicação, portanto, falhas em qualquer componente podem resultar em sério impacto. Tais falhas podem ser acidentais (ex: erro de codificação) ou intencionais (ex: um backdoor em um componente). Alguns exemplos de vulnerabilidades exploráveis em componentes descobertos são:

  • CVE-2017-5638, uma vulnerabilidade de execução remota de código (RCE) no Struts 2 que permite a execução de código arbitrário no servidor, sendo responsabilizada por violações significativas.
  • CVE-2021-44228 ("Log4Shell"), uma vulnerabilidade de dia zero de execução remota de código no Apache Log4j, responsabilizada por campanhas de ransomware, mineração de criptomoedas e outros ataques.

Referências

Lista de CWEs Mapeadas