Um SBOM é o mesmo que uma página de conformidade de licenças?

Um SBOM é um inventário de componentes legível por máquina, construído para ferramentas de segurança e cadeia de fornecimento, não para divulgação de licenças. Os elementos mínimos da NTIA definem-no como fornecedor, nome do componente, versão, identificadores únicos, relações de dependência, e autor, o que são dados de identidade para correspondência de vulnerabilidades, e não texto de licença revisto.

As ferramentas de segurança associam CVEs a identidades de componentes. A documentação do Anexo I da CRA espera listas de componentes em formatos comuns. As equipas de resposta a vulnerabilidades rastreiam o raio de impacto através de dependency graphs.

Os campos de licença de um SBOM são pontos de partida, não aprovações. Os identificadores SPDX em CycloneDX vêm muitas vezes dos metadados do registo npm, que são frequentemente errados, incompletos, ou marcados como NOASSERTION. As equipas de AppSec raramente anexam o texto integral de licenças GPL ou de SDK proprietários a uma exportação de SBOM.

• Identidade do componente (nome, versão, PURL, hash), para correspondência de vulnerabilidades.
• Metadados de fornecedor e autor, para rastreabilidade da cadeia de fornecimento.
• Formato legível por máquina (CycloneDX, SPDX), para ferramentas e documentação regulamentar.
• Input para a documentação de componentes da CRA e programas de segurança de produto.
• Deteção de deriva quando o CI gera um novo SBOM a cada build.
• Não é: divulgação de licenças de terceiros legível por humanos, para revisão jurídica.
• Não é: texto integral de licença, aviso, ou blocos de atribuição por componente.
• Não é: portões de publicação que confirmem que um humano reviu cada obrigação.

A divulgação de licenças dá texto de licença revisto e legível por humanos, atribuição, e avisos associados a um lançamento específico, o que um SBOM não dá. Um SBOM responde a “que componentes estão aqui” para ferramentas de segurança; a divulgação responde a “o que somos legalmente obrigados a reproduzir quando lançamos isto” para as compras e o jurídico.

A divulgação de licenças de terceiros responde a perguntas de compras e jurídico: que software open source e de terceiros está neste produto, sob que licenças, com que aviso e atribuição, a partir de que lançamento revisto.

Em equipas de engenharia com várias pessoas, as dependências mudam constantemente. Um engenheiro integra um patch; outro adiciona um SDK; os pacotes transitivos mudam. Um registo de divulgação só funciona se for reimportado, revisto de novo, e republicado quando a base de código muda, quer o aloje num URL, quer anexe uma exportação a um questionário.

• Inventário revisto por produto lançado, não metadados brutos do registo.
• Texto integral de licença para cada componente no âmbito, não apenas o identificador SPDX.
• Atribuição e aviso de direitos de autor onde a MIT, Apache, BSD, GPL os exigirem.
• Linhas de copyleft e licenças personalizadas bloqueadas até revisão explícita.
• Âmbito de produto claro: que SKU ou lançamento o registo cobre.
• Aprovação de publicação: alguém responsável antes da partilha externa.
• Processo de manutenção: atualização quando os lockfiles ou SBOMs mudam.

Mantenha esta tabela à mão quando um questionário pedir tanto “SBOM” como “conformidade de licenças open source”. Sobrepõem-se no inventário, mas não no entregável.

Não. Pode gerar ficheiros CycloneDX perfeitos em cada lançamento e ainda assim falhar numa revisão de compras que pede conformidade de licenças, porque um SBOM lista componentes, mas não reproduz o texto de licença, os avisos, e a atribuição que as obrigações de distribuição exigem.

O comprador abre o seu anexo, vê nomes de componentes e a palavra “MIT”, e pergunta onde está o texto da licença.

A CRA empurra as organizações a documentar componentes, o que acelera a adoção de SBOM. Não substitui décadas de expectativa dos compradores de que os fornecedores mantenham divulgação de licenças de terceiros. A documentação de segurança de produto da UE e as secções de licenças em RFPs enterprise são vias paralelas.

As equipas de segurança são responsáveis pela gravidade de vulnerabilidades, patches, comunicação de incidentes. As obrigações de licença (aviso, atribuição, condições de copyleft) precisam de um responsável que reveja antes da partilha externa. Esse responsável raramente é a mesma pessoa que faz merge dos PRs do Dependabot.

O modelo eficiente importa o mesmo SBOM ou lockfile para ambos os pipelines. A segurança consome o SBOM para CVEs e documentação da CRA. A conformidade importa o mesmo ficheiro para uma fila de revisão: cada componente precisa de revisão, texto integral, aprovação, e depois publicação num registo de divulgação.

Quando o SBOM muda no próximo lançamento, ambas as equipas reagem. A segurança volta a verificar vulnerabilidades. A conformidade volta a rever as linhas de licença novas ou alteradas. Uma fonte de inventário, dois resultados. Nenhum dos resultados substitui o outro.

• Importar CycloneDX, SPDX, ou lockfiles, uma vez por candidato a lançamento.
• Segurança: verificação de vulnerabilidades, documentação da CRA, rastreabilidade de incidentes.
• Conformidade: correspondência de licenças, anexo de texto integral, escalamento de copyleft, portão de publicação.
• Publicar o registo de divulgação a partir do snapshot aprovado (página ou exportação, conforme o comprador exigir).
• Verificação de deriva: sinalizar alterações no SBOM que ainda não têm nova aprovação de conformidade.

Carregar o JSON de um SBOM num portal de fornecedores e chamar-lhe conformidade de licenças. Colar identificadores SPDX numa folha de cálculo sem texto. Presumir que uma verificação de licenças do FOSSA ou Snyk equivale a divulgação revista, sem portões de publicação.

Gerar um PDF a partir de ferramentas de SBOM uma vez e reutilizá-lo em vários lançamentos, enquanto os engenheiros continuam a integrar dependências. O mesmo problema de snapshot desatualizado que qualquer exportação estática, seja qual for o formato.