O OWASP Top 10 2025 colocou Software Supply Chain Failures em A03. A mudança é mais ampla do que uma troca de nome para a antiga categoria de componentes vulneráveis e desatualizados: ela reconhece que o risco aparece na seleção, obtenção, construção, promoção e distribuição do software.
De componente vulnerável a falha de cadeia
Uma análise restrita pergunta se uma biblioteca possui CVE conhecida. Uma análise de cadeia também pergunta de onde ela veio, quem a publicou, se o artefato foi alterado, como entrou no build e quais controles permitem promovê-lo.
| Visão focada no componente | Visão de Software Supply Chain |
|---|---|
| A versão possui vulnerabilidade conhecida? | A origem, identidade e integridade do componente são confiáveis? |
| Existe atualização disponível? | O processo consegue selecionar, testar e promover a atualização com segurança? |
| O manifesto declara a dependência? | Dependências transitivas e artefatos realmente entregues estão inventariados? |
| A ferramenta gerou um alerta? | A política consegue bloquear, aprovar, registrar exceções e produzir evidência? |
Essa ampliação inclui riscos em gerenciadores de dependência, sistemas de build, repositórios de artefatos, pipelines, ferramentas de distribuição e processos de atualização. A pergunta deixa de ser apenas “qual componente usamos?” e passa a incluir “por qual caminho esse componente ganhou confiança?”.
Por que a categoria chegou ao A03
Na pesquisa com a comunidade usada na edição 2025, Software Supply Chain Failures ficou em primeiro lugar: exatamente 50% dos respondentes a classificaram como a categoria nº 1. O resultado final do OWASP Top 10, porém, não é definido apenas pela votação. A OWASP combina a pesquisa da comunidade com dados submetidos e análise editorial.
A presença limitada em conjuntos de dados e os 11 CVEs associados não significam que metade das aplicações observadas tenha esse problema nem que a categoria seja universalmente a terceira mais frequente. Cadeias de software são difíceis de representar por CVE porque muitas falhas envolvem processo, confiança, identidade, infraestrutura e distribuição, não uma vulnerabilidade isolada em código.
O posicionamento em A03 deve ser lido como sinal de impacto e relevância sistêmica. Um comprometimento em uma dependência, conta de mantenedor, pipeline ou repositório pode se propagar para muitos consumidores antes que exista um indicador tradicional de vulnerabilidade.
O que muda no desenho de controles
1. O controle começa na seleção
Políticas precisam operar antes do download ou da introdução no build. Isso inclui origem permitida, idade do componente, integridade, histórico do mantenedor, licenças, vulnerabilidades conhecidas e sinais de comportamento malicioso.
2. O inventário inclui dependências transitivas
Manifestos diretos não descrevem toda a composição. O inventário precisa refletir dependências transitivas e o artefato efetivamente produzido. SBOMs ajudam, desde que sejam atualizadas, vinculadas a versões e usadas em processos de monitoramento e resposta.
3. Build e promoção são fronteiras de confiança
Credenciais, runners, plugins, actions, registries e repositórios podem alterar o que chega ao usuário. Segregação de funções, menor privilégio, assinatura, proveniência e políticas de promoção reduzem a chance de uma alteração não autorizada atravessar o pipeline.
4. Atualização precisa ser contínua e testável
Atualizar rapidamente exige mais do que receber um alerta. A equipe precisa localizar os consumidores, avaliar compatibilidade, executar testes, reconstruir artefatos, promover a correção e confirmar distribuição.
- 01Seleçãoorigem, identidade e política
- 02Ingestãointegridade e sinais de risco
- 03Buildambiente, credenciais e proveniência
- 04Promoçãoaprovação e segregação
- 05Distribuiçãoassinatura e canal confiável
- 06Monitoramentonovas vulnerabilidades e incidentes
Como verificar seu ambiente
- Dependências externas entram diretamente da internet ou passam por um ponto controlado?
- O inventário cobre dependências transitivas e o artefato entregue?
- O pipeline fixa versões e valida integridade de actions, plugins e imagens?
- Credenciais de build e publicação possuem menor privilégio e rotação?
- Artefatos recebem assinatura ou proveniência verificável?
- Políticas de promoção bloqueiam riscos e registram exceções com responsável e validade?
- A organização consegue localizar e reconstruir rapidamente todos os consumidores de um componente?
Responder “sim” à existência de uma ferramenta não encerra a avaliação. É preciso verificar cobertura, qualidade do dado, enforcement, exceções e capacidade de resposta.
Fontes e referências
- OWASP Top 10:2025 — A03 Software Supply Chain Failures
- OWASP Top 10:2025 — Introduction and methodology
- OWASP Software Component Verification Standard
Quer avaliar as fronteiras de confiança do seu CI/CD?
A Xmart apoia times na avaliação de arquitetura, políticas e controles para reduzir exposição na Software Supply Chain.
