SBOM: Software Bill of Materials para transparência

1. O que é uma SBOM e por que ela importa para Devs

Uma Software Bill of Materials (SBOM) é uma lista formal e aninhada que documenta todos os componentes, bibliotecas, dependências diretas e transitórias, além das respectivas versões que compõem um software. Pense nela como a "lista de ingredientes" de uma aplicação — essencial para entender o que realmente está sendo executado em produção.

Para desenvolvedores de segurança, a SBOM é uma ferramenta crítica por três razões fundamentais:

  • Rastreamento de vulnerabilidades: Quando uma nova CVE (Common Vulnerabilities and Exposures) é divulgada, a SBOM permite identificar instantaneamente quais artefatos em seu ecossistema são afetados.
  • Defesa contra supply chain attacks: Ataques como o do SolarWinds (2020) demonstraram que comprometer uma única dependência pode afetar milhares de organizações. A SBOM oferece visibilidade total da cadeia.
  • Conformidade regulatória: A Ordem Executiva 14028 (EUA), diretrizes da CISA e especificações da NTIA tornaram a SBOM um requisito para software fornecido ao governo americano. Padrões como o ISO 5230 também estão emergindo globalmente.

2. Formatos e estruturas de SBOM

Dois formatos dominam o ecossistema, cada um com propósitos distintos:

CycloneDX (OWASP)

Focado em segurança e análise de risco de componentes. Suporta metadados ricos para vulnerabilidades, licenças e pedigree de componentes. Ideal para pipelines DevSecOps.

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "metadata": {
    "timestamp": "2025-01-15T10:00:00Z",
    "tools": [{"vendor": "OWASP", "name": "CycloneDX CLI"}]
  },
  "components": [
    {
      "type": "library",
      "name": "lodash",
      "version": "4.17.21",
      "purl": "pkg:npm/lodash@4.17.21"
    }
  ]
}

SPDX (Linux Foundation)

Originalmente criado para gestão de licenças, evoluiu para incluir segurança. Excelente para auditoria legal e compliance, mas menos detalhado em metadados de vulnerabilidade comparado ao CycloneDX.

SPDXVersion: SPDX-2.3
DataLicense: CC0-1.0
SPDXID: SPDXRef-DOCUMENT
DocumentName: my-app-1.0.0
PackageName: lodash
PackageVersion: 4.17.21
PackageLicenseConcluded: MIT

Quando usar cada formato:
- CycloneDX: Para integração com ferramentas de segurança (Grype, Dependency-Track), análise de risco em tempo real e DevSecOps.
- SPDX: Para auditoria legal, relatórios de licenciamento e conformidade com padrões abertos.

3. Gerando SBOMs no pipeline de desenvolvimento

Ferramentas nativas de linguagem

# Node.js
npm sbom --format cyclonedx > sbom.json

# Python
pip freeze > requirements.txt
# Converter para SBOM usando CycloneDX CLI
cyclonedx-py requirements.txt --format json > sbom.json

# Go
go mod graph > go-mod-graph.txt
# Processar com Syft
syft packages dir:. -o cyclonedx-json > sbom.json

Geradores dedicados

Syft (Anchore): Gera SBOMs a partir de imagens Docker, sistemas de arquivos e repositórios.

syft packages my-image:latest -o cyclonedx-json > sbom-latest.json

Trivy (Aqua Security): Além de scanner de vulnerabilidades, gera SBOMs em múltiplos formatos.

trivy image --format cyclonedx --output sbom.json alpine:3.19

CycloneDX CLI: Ferramenta oficial para gerar, validar e converter SBOMs.

cyclonedx validate --input-file sbom.json
cyclonedx convert --input-file sbom.spdx --output-format cyclonedx

Integração contínua (CI/CD)

# Exemplo de stage em GitLab CI para gerar SBOM
generate-sbom:
  stage: security
  script:
    - syft packages . -o cyclonedx-json > sbom-$CI_COMMIT_SHORT_SHA.json
  artifacts:
    paths:
      - sbom-*.json
    expire_in: 30 days

4. Consumindo SBOMs para segurança proativa

A SBOM só é útil se for consumida ativamente. Ferramentas como Grype e Dependency-Track permitem correlacionar componentes com bancos de vulnerabilidades (NVD, OSV, GitHub Advisory Database).

# Grype: escaneia SBOM contra CVEs conhecidas
grype sbom:sbom-latest.json --only-fixed

# Dependency-Track: plataforma contínua de análise de componentes
curl -X POST https://dt.example.com/api/v1/bom \
  -H "X-Api-Key: $API_KEY" \
  -F "bom=@sbom-latest.json"

Alertas automáticos: Configure webhooks para receber notificações quando uma nova CVE afeta componentes listados na SBOM. Por exemplo, integração com Slack ou PagerDuty via Dependency-Track.

5. SBOM e cadeia de suprimentos: dependência e transparência

Verificação de assinatura e integridade

Use Sigstore (Cosign) para assinar SBOMs e garantir que não foram adulteradas:

cosign sign-blob --key cosign.key sbom-latest.json > sbom-latest.sig
cosign verify-blob --key cosign.pub --signature sbom-latest.sig sbom-latest.json

Compartilhamento via OCI registry

Armazene SBOMs junto com as imagens de contêiner:

oras push registry.example.com/my-app:sbom \
  --artifact-type application/vnd.cyclonedx+json sbom-latest.json

Políticas de aceitação

Estabeleça gates no pipeline: só permitir integração de dependências que fornecem SBOM verificada. Ferramentas como Ratify ou Kyverno podem enforce essas políticas.

6. Boas práticas e armadilhas comuns

✅ Boas práticas

  • Gere SBOM a cada release: Automatize a geração em cada tag ou merge na branch principal.
  • Versionamento da SBOM: Associe o hash do artefato (SHA256) à SBOM para rastreabilidade.
  • Valide a SBOM: Use cyclonedx validate antes de armazenar.

⚠️ Armadilhas comuns

  • SBOMs petrificadas: Gerar uma SBOM no início do projeto e nunca atualizar. Vulnerabilidades surgem diariamente.
  • Dependências transitórias não resolvidas: Ferramentas como npm ls --all ajudam a capturar dependências aninhadas.
  • Falsos positivos: Uma SBOM pode listar componentes não utilizados em runtime. Use ferramentas de análise de uso real (ex.: OWASP Dependency-Check com modo de evidência).
# Exemplo de dependência transitória não resolvida
npm ls --all --depth=5 | grep lodash
# Saída esperada: lodash@4.17.21 (dependência transitória via express)

7. SBOM em ação: fluxo de resposta a incidentes

Cenário: Descoberta da CVE-2024-XXXXX em lodash@4.17.20 (crítica, CVSS 9.8).

Passo 1: Consultar SBOM

grep -A 5 '"lodash"' sbom-producao.json | grep '"version"'
# Saída: "version": "4.17.20"

Passo 2: Identificar todos os artefatos afetados

for sbom in $(find . -name "sbom-*.json"); do
  if grep -q '"4.17.20"' "$sbom"; then
    echo "Artefato afetado: $sbom"
  fi
done

Passo 3: Priorizar correção
- Atualizar para lodash@4.17.21 (versão corrigida)
- Gerar nova SBOM com syft packages . -o cyclonedx-json > sbom-fix.json
- Assinar e publicar a nova SBOM

Automação pós-incidente:

# Diff de SBOM entre versões
cyclonedx diff --from sbom-v1.0.0.json --to sbom-v1.0.1.json
# Saída: lista de componentes adicionados, removidos e alterados

Referências