SBOM: Guia Completo de Software Bill of Materials

O que é SBOM

SBOM (Software Bill of Materials) é um inventário formal e estruturado de todos os componentes que compõem uma aplicação de software. Assim como uma lista de ingredientes em um produto alimentício, o SBOM lista todas as bibliotecas, frameworks, e dependências utilizadas, incluindo suas versões e origens.

O conceito ganhou relevância após incidentes como Log4Shell (Log4j), onde organizações levaram dias ou semanas para identificar quais de suas aplicações usavam a biblioteca vulnerável. Com SBOM, essa resposta pode ser instantânea.

Elementos de um SBOM

• Nome do componente: Ex: log4j-core
• Versão: Ex: 2.14.1
• Fornecedor/Autor: Ex: Apache Software Foundation
• Identificador único: Ex: CPE, PURL, SWID
• Relação de dependência: Dependência direta ou transitiva
• Hash/Checksum: Para verificação de integridade
• Licença: Ex: Apache 2.0, MIT, GPL

Por que SBOM é Importante

O problema Log4Shell

Em dezembro de 2021, uma vulnerabilidade crítica foi descoberta no Log4j (CVE-2021-44228). A biblioteca é usada em milhões de aplicações Java. Organizações enfrentaram perguntas críticas:

• Quais de nossas aplicações usam Log4j?
• Qual versão?
• É uma dependência direta ou transitiva?
• Quais vendors que usamos são afetados?

Sem SBOM, responder essas perguntas requer análise manual de cada aplicação - processo que levou semanas para muitas empresas enquanto a vulnerabilidade estava sendo ativamente explorada.

Regulamentações e compliance

• Executive Order 14028 (EUA): Fornecedores do governo federal devem fornecer SBOM
• EU Cyber Resilience Act: Exige SBOM para produtos com elementos digitais
• FDA: Recomenda SBOM para dispositivos médicos
• NIST SP 800-218: Guidelines para secure software development incluem SBOM

Benefícios operacionais

• Resposta a vulnerabilidades: Identificar rapidamente aplicações afetadas
• Gestão de licenças: Garantir compliance com licenças open source
• Due diligence em M&A: Avaliar risco de software em aquisições
• Transparência para clientes: Fornecer visibilidade da composição do software
• Auditoria e compliance: Demonstrar controle sobre supply chain de software

Formatos: CycloneDX vs SPDX

Exemplo CycloneDX (JSON)

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.17.1",
      "purl": "pkg:maven/org.apache.logging.log4j/[email protected]",
      "licenses": [{"license": {"id": "Apache-2.0"}}],
      "hashes": [{"alg": "SHA-256", "content": "abc123..."}]
    }
  ]
}

Qual escolher?

• Use CycloneDX se: Foco em segurança, integração com ferramentas de segurança, precisa de VEX
• Use SPDX se: Foco em compliance de licenças, requisito de cliente específico, padrão ISO necessário
• Na prática: Muitas ferramentas suportam ambos; CycloneDX é mais comum em contextos de segurança

Como Gerar SBOM

Ferramentas por ecosistema

Multi-linguagem

• Syft (Anchore): Gera SBOM de containers, filesystems, código fonte
• Trivy (Aqua): Scanner de vulnerabilidades que também gera SBOM
• cdxgen: Suporta múltiplas linguagens, focado em CycloneDX
• Microsoft SBOM Tool: Ferramenta oficial da Microsoft

Java/Maven

Node.js/npm

Python/pip

Containers

Integração em CI/CD

# GitHub Actions exemplo
- name: Generate SBOM
  uses: anchore/sbom-action@v0
  with:
    image: ${{ env.IMAGE }}
    format: cyclonedx-json
    output-file: sbom.json

- name: Scan SBOM for vulnerabilities
  uses: anchore/scan-action@v3
  with:
    sbom: sbom.json
    fail-build: true
    severity-cutoff: high

Gestão e Consumo de SBOM

Armazenamento

• Junto com artefato: SBOM armazenado no registry junto com a imagem/pacote
• Repositório centralizado: Sistema dedicado para gestão de SBOMs
• Assinatura: SBOM assinado para garantir integridade (Sigstore, in-toto)

Plataformas de gestão

• Dependency-Track (OWASP): Open source, ingere SBOMs e monitora vulnerabilidades
• GUAC (Google): Graph for Understanding Artifact Composition
• Snyk: SCA comercial com suporte a SBOM
• Sonatype Nexus: Lifecycle management com SBOM
• JFrog Xray: Análise de composição integrada ao Artifactory

Workflow típico

1. Build time: SBOM gerado automaticamente no pipeline
2. Storage: SBOM armazenado junto ao artefato ou em repositório central
3. Continuous monitoring: Plataforma monitora novas vulnerabilidades
4. Alerting: Time notificado quando componente no SBOM tem CVE nova
5. Response: SBOM permite identificar rapidamente aplicações afetadas

VEX e Contextualização

VEX (Vulnerability Exploitability eXchange) complementa o SBOM fornecendo contexto sobre se vulnerabilidades em componentes realmente afetam a aplicação específica.

O problema

Um componente pode ter uma vulnerabilidade, mas ela pode não ser exploravel no contexto da sua aplicação. Exemplo: vulnerabilidade em função de parsing XML do Log4j, mas sua aplicação nunca usa XML com Log4j.

Status VEX

• Not Affected: Vulnerabilidade não afeta este produto
• Affected: Vulnerabilidade afeta e requer ação
• Fixed: Vulnerabilidade foi corrigida nesta versão
• Under Investigation: Ainda avaliando impacto

Implementação Prática

Fase 1: Piloto (1-2 meses)

• Selecionar 2-3 aplicações críticas para piloto
• Implementar geração de SBOM no pipeline
• Escolher formato (recomendado: CycloneDX para segurança)
• Validar qualidade do SBOM gerado

Fase 2: Expansão (2-4 meses)

• Implementar Dependency-Track ou similar para gestão
• Expandir geração de SBOM para mais aplicações
• Integrar alertas de vulnerabilidade com workflow existente
• Definir processo para triagem de alertas

Fase 3: Maturidade (6+ meses)

• SBOM obrigatório para todas as aplicações em produção
• VEX para contextualizar vulnerabilidades
• SBOMs de vendors/terceiros coletados e analisados
• Métricas de cobertura e tempo de resposta

Conclusão

SBOM evoluiu de nice-to-have para requisito essencial de segurança de software. A complexidade das aplicações modernas, com centenas de dependências transitivas, torna impossível gerenciar riscos de supply chain sem visibilidade automatizada da composição do software.

A boa notícia é que ferramentas maduras existem para gerar e gerenciar SBOMs automaticamente. O investimento em implementar SBOM paga-se rapidamente na primeira vez que você precisa responder "somos afetados por esta vulnerabilidade?" em minutos em vez de dias.