Introdução ao SBOM (Software Bill of Materials) para rastreabilidade de dependências

1. O que é um SBOM e por que ele é essencial?

Um SBOM (Software Bill of Materials) é uma lista detalhada e estruturada de todos os componentes, bibliotecas, módulos e dependências que compõem um software. Assim como uma lista de ingredientes em um produto alimentício permite rastrear a origem de cada componente, o SBOM oferece transparência total sobre o que está dentro de uma aplicação.

No contexto atual de segurança de software, onde ataques à cadeia de suprimentos (supply chain attacks) se tornaram cada vez mais frequentes — como os incidentes envolvendo SolarWinds e Log4j — o SBOM deixou de ser uma boa prática opcional para se tornar uma necessidade estratégica. Ele permite:

  • Transparência: conhecer exatamente quais componentes estão em uso
  • Gestão de riscos: identificar vulnerabilidades conhecidas em dependências
  • Compliance: atender a regulamentações como a Ordem Executiva 14028 dos EUA e requisitos setoriais

Sem um SBOM, uma organização pode estar executando software com centenas de dependências desconhecidas, cada uma representando um ponto potencial de falha ou ataque.

2. Formatos e padrões de SBOM

Existem dois principais formatos padronizados para SBOM, ambos mantidos por comunidades abertas:

SPDX (Software Package Data Exchange): Desenvolvido pela Linux Foundation, é o formato mais maduro e abrangente. Suporta descrição detalhada de licenças, relacionamentos entre componentes e informações de segurança. É amplamente utilizado em projetos de código aberto e governamentais.

CycloneDX: Criado pela OWASP, é um formato mais leve e orientado a segurança. Oferece suporte nativo a vulnerabilidades, avaliação de risco e metadados de componentes. Tornou-se o formato preferido para integração com ferramentas de segurança modernas.

Ambos os formatos podem ser representados em JSON ou XML, e há ferramentas que convertem entre eles, garantindo interoperabilidade.

3. Componentes essenciais de um SBOM

Um SBOM bem estruturado deve conter:

  • Identificação de dependências diretas e transitivas: dependências diretas são aquelas explicitamente incluídas pelo desenvolvedor; transitivas são dependências das dependências
  • Metadados: versão exata de cada componente, licença de uso, fornecedor ou mantenedor, e hashes criptográficos (SHA-256) para verificação de integridade
  • Relacionamentos: hierarquia entre componentes (ex: "contém", "depende de", "compila a partir de")
  • Ciclo de vida: informações sobre quando o SBOM foi gerado e sua validade

Exemplo de um SBOM simplificado em formato CycloneDX:

{
  "bomFormat": "CycloneDX",
  "specVersion": "1.5",
  "version": 1,
  "metadata": {
    "timestamp": "2025-01-15T10:30:00Z",
    "tools": [
      {
        "vendor": "anchore",
        "name": "syft",
        "version": "1.18.0"
      }
    ]
  },
  "components": [
    {
      "type": "library",
      "name": "log4j-core",
      "version": "2.17.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "licenses": [
        {
          "license": {
            "id": "Apache-2.0"
          }
        }
      ],
      "hashes": [
        {
          "alg": "SHA-256",
          "content": "a1b2c3d4e5f6..."
        }
      ]
    },
    {
      "type": "library",
      "name": "jackson-databind",
      "version": "2.15.3",
      "purl": "pkg:maven/com.fasterxml.jackson.core/jackson-databind@2.15.3"
    }
  ]
}

4. Como gerar um SBOM na prática

Diversas ferramentas open source permitem gerar SBOMs automaticamente a partir do código-fonte ou de imagens de contêiner:

  • Syft: ferramenta da Anchore que gera SBOMs a partir de sistemas de arquivos, imagens Docker e repositórios
  • Trivy: scanner de vulnerabilidades que também gera SBOMs em formato CycloneDX
  • CycloneDX CLI: utilitário oficial da OWASP para geração e validação de SBOMs

Exemplo de comando para gerar um SBOM com Syft a partir de uma imagem Docker:

syft packages docker:nginx:latest -o cyclonedx-json > sbom-nginx.json

Para integrar em um pipeline CI/CD (ex: GitHub Actions):

- name: Generate SBOM
  run: |
    syft packages . -o cyclonedx-json > sbom.json
- name: Upload SBOM artifact
  uses: actions/upload-artifact@v4
  with:
    name: sbom
    path: sbom.json

5. Uso do SBOM para rastreabilidade e gestão de vulnerabilidades

O verdadeiro valor de um SBOM emerge quando ele é correlacionado com bancos de vulnerabilidades conhecidas, como:

  • NVD (National Vulnerability Database): mantido pelo NIST, contém CVEs catalogadas
  • OSV (Open Source Vulnerabilities): banco de dados aberto mantido pelo Google
  • GitHub Advisory Database: base de avisos de segurança do GitHub

Com um SBOM em mãos, é possível identificar rapidamente se uma biblioteca específica é afetada por uma CVE recém-descoberta:

trivy sbom sbom.json --severity HIGH,CRITICAL

Isso permite ações de remediação direcionadas: atualizar a dependência para uma versão corrigida, aplicar um patch ou substituir o componente problemático. Em vez de vasculhar manualmente todo o código, a equipe de segurança sabe exatamente onde agir.

6. SBOM no ciclo de vida do software e compliance

O SBOM não é um artefato único — ele deve ser gerado em múltiplos pontos do ciclo de vida:

  • Durante o desenvolvimento: a cada build, gerar um SBOM atualizado
  • No momento da liberação: incluir o SBOM como parte do pacote de entrega
  • Em produção: manter histórico de SBOMs para auditoria retrospectiva

Regulamentações como a Ordem Executiva 14028 (EUA) e requisitos da FDA para software médico exigem que fornecedores de software forneçam SBOMs aos seus clientes. O compartilhamento seguro pode ser feito via assinatura digital e armazenamento em repositórios confiáveis.

7. Desafios e boas práticas na adoção de SBOM

Desafios comuns:
- Dependências transitivas podem gerar SBOMs com milhares de entradas
- Falsos positivos em scanners de vulnerabilidades
- Manter SBOMs atualizados em ambientes de microsserviços dinâmicos

Boas práticas:
- Automatizar a geração de SBOMs em cada build
- Armazenar SBOMs em repositórios versionados (ex: junto com o código-fonte)
- Integrar com ferramentas como Snyk, OWASP Dependency-Check ou Grype para análise contínua
- Validar periodicamente a acurácia dos SBOMs gerados

8. Futuro do SBOM e tendências em segurança de software

O ecossistema de SBOM está evoluindo rapidamente:

  • SBOMs assinados: uso de assinaturas criptográficas (ex: com Sigstore/Cosign) para garantir autenticidade e integridade
  • VEX (Vulnerability Exploitability eXchange): complemento ao SBOM que indica se uma vulnerabilidade específica é realmente explorável no contexto da aplicação
  • SLSA (Supply-chain Levels for Software Artifacts): framework de níveis de maturidade para segurança da cadeia de suprimentos
  • IA para análise: ferramentas baseadas em inteligência artificial começam a automatizar a análise de dependências e sugerir correções

A combinação de SBOM com VEX e SLSA promete criar um ecossistema onde cada artefato de software tenha rastreabilidade completa, desde a origem até a implantação.

Referências