Pedidos de SBOM de clientes: como responder

Fornece componentes ou software embarcado a fabricantes? Consulte o guia de SBOM para fornecedores, que trata de contratos, VEX e de uma SBOM por versão de software entregue.

Porque é que os clientes estão a perguntar agora

• O Cyber Resilience Act. Os fabricantes que vendem na UE precisam de uma SBOM do seu próprio produto e têm de ter cuidado com os componentes que integram, pelo que a questão vai descendo pela cadeia de abastecimento.
• NIS2. As entidades essenciais e importantes têm de tratar da segurança da cadeia de abastecimento. A diretiva não menciona as SBOM, mas uma SBOM é uma forma de um comprador ver o que um fornecedor distribui. Consulte SBOM como evidência de NIS2, ISO 27001 e SOC 2.
• Regras setoriais. A secção 524B da FDA exige uma SBOM para dispositivos cibernéticos, e outros setores têm regras próprias.
• O trabalho de vulnerabilidades do próprio cliente. Um cliente que sabe o que está no seu produto consegue perceber se uma nova CVE o afeta sem abrir um pedido de suporte.

O que acordar antes de enviar seja o que for

Pergunta	Porque é importante
Que produto e que versão?	Uma SBOM descreve uma versão. Envie a que o cliente usa, não a do build mais recente.
Que formato?	A maioria dos pedidos aceita CycloneDX ou SPDX. Pergunte se precisam de uma versão específica.
Com que profundidade?	As dependências de nível superior podem não bastar. Conte com um pedido das transitivas.
Uma vez ou em cada versão?	Um contrato pode prever uma nova SBOM para cada versão, o que exclui tudo o que seja feito à mão.
Em que condições?	Uma SBOM mostra como o seu produto é construído. Acorde as condições de confidencialidade e a forma de entrega do ficheiro.

O que contém uma boa resposta

• Uma SBOM no formato acordado, para a versão exata que o cliente usa.
• Todos os componentes com nome, versão, fornecedor, licença e um identificador de pacote.
• As relações de dependência, para que um pacote transitivo possa ser rastreado até ao que o trouxe.
• A data, a ferramenta que a produziu e o build de onde veio.
• Uma nota honesta sobre tudo o que a SBOM não cobre (veja completude da SBOM).

Para ver o aspeto dos ficheiros, consulte exemplos de SBOM. Sobre os dois formatos, consulte CycloneDX vs SPDX. Para saber o que o cliente provavelmente vai verificar à chegada, consulte a checklist de qualidade de SBOM.

Erros que voltam mais tarde

• Enviar o build mais recente em vez do distribuído. Por defeito, os builds não são reprodutíveis, pelo que recompilar o mesmo commit não garante a mesma SBOM. Só a SBOM do build que produziu a versão mostra o que o cliente recebeu.
• Montá-la à mão para a ocasião. Satisfaz o pedido uma vez, e terá de repetir o trabalho para o próximo cliente e a próxima versão. Consulte automatização de SBOM.
• Prometer mais do que consegue repetir. "Enviamos uma em cada versão" é uma frase fácil num contrato e difícil de cumprir sem automatização.
• Tratar a SBOM como o fim da história. A pergunta seguinte é "estão afetados por esta CVE?", e chega quando chegar a próxima grande vulnerabilidade.

Como estar preparado para o próximo pedido

Os pedidos tornam-se fáceis quando a SBOM já existe. Produza uma para cada versão no pipeline que a compila, guarde-a com a versão e monitorize-a quanto a novas vulnerabilidades. A partir daí, um pedido resume-se a uma descarga e a uma nota curta, e pode responder à pergunta seguinte a partir do mesmo registo.

Como o CRACI trata disto

O CRACI regista uma SBOM de cada build de GitHub Actions executado nos seus runners, pelo que cada versão já tem uma quando alguém a pede.

• Exportação em CycloneDX ou SPDX, incluindo as dependências transitivas e as vulnerabilidades encontradas nos componentes.
• Evidências do próprio build. Todos os componentes da SBOM estiveram no build, e as dependências ocultas que as ferramentas baseadas em lockfiles não detetam ficam registadas.
• Um estado de completude em cada job, para que saiba o que está a enviar antes de o enviar.
• Histórico de builds. Pode ver builds anteriores e as respetivas SBOM, e que builds continham uma dependência vulnerável, dentro do seu período de retenção.
• Respostas à pergunta seguinte. O CRACI reavalia continuamente as SBOM monitorizadas, suporta VEX e mostra que produtos executam que versões na vista de inventário.

Pedidos de SBOM de clientes: perguntas frequentes

Somos obrigados a dar a nossa SBOM aos clientes?

Depende do seu mercado e dos seus contratos. O Cyber Resilience Act torna a SBOM parte da documentação técnica, que é entregue a uma autoridade de fiscalização do mercado mediante pedido, e não exige a sua publicação. O direito de um cliente a recebê-la decorre normalmente do contrato, por isso verifique o que acordou.

Que formato de SBOM devemos enviar?

CycloneDX ou SPDX, conforme o que o cliente pedir. Se não tiver preferência, qualquer um serve. Pergunte se as ferramentas do cliente precisam de uma versão específica.

Temos de incluir as dependências transitivas?

O Cyber Resilience Act pede, no mínimo, as dependências de nível superior, mas muitos compradores esperam a árvore completa, e as vulnerabilidades estão muitas vezes em pacotes transitivos. Uma SBOM completa é a resposta mais segura.

A SBOM deve ser entregue ao cliente ao abrigo de um NDA?

Essa decisão é sua e do seu cliente. Uma SBOM mostra de que é feito o seu produto, pelo que muitos fornecedores a partilham ao abrigo do contrato existente ou de um NDA, em vez de a publicarem.

Com que frequência devemos enviar uma SBOM atualizada?

Com a frequência que acordarem. As dependências mudam a cada versão, pelo que uma nova SBOM por versão é o ponto de partida honesto, e isso só é viável se a SBOM sair do build.

E se o cliente perguntar por uma versão mais antiga?

Precisa da SBOM do build que produziu essa versão. O CRACI conserva o histórico de builds dentro do seu período de retenção, 180 dias por defeito, com retenção personalizada no plano Enterprise, por isso exporte tudo o que precise de guardar durante mais tempo.

Nunca fizemos uma SBOM. Por onde começamos?

Comece pela versão que o seu cliente usa e por uma ferramenta que trabalhe a partir do seu build real. Se usa GitHub Actions, mover o build para runners do CRACI dá-lhe uma SBOM registada desde a primeira execução.