O seu cliente quer uma SBOM: guia para fornecedores de componentes e software

Este guia destina-se a fornecedores integrados numa cadeia de abastecimento industrial: ECU, ecrãs, controladores, gateways, acionamentos, stacks de Linux embarcado e módulos de firmware. Se vende software e um cliente enviou um pedido pontual, comece por como responder a um pedido de SBOM de um cliente, que trata esse caso.

Porque é que os OEM estão a pedir agora

O pedido de SBOM de um OEM é normalmente a regulamentação desse OEM a chegar-lhe à porta através de um contrato. É essa regulamentação que decide o que o OEM tem de ter, e quanto disso é passado para si.

O Cyber Resilience Act

Ao abrigo do Cyber Resilience Act, Regulamento (UE) 2024/2847, um produto com elementos digitais inclui componentes de software ou de hardware colocados no mercado separadamente (artigo 3.º, ponto 1). Um componente que vende por si só na UE é um produto de pleno direito, e a sua empresa é o fabricante, com a sua própria obrigação de SBOM: o anexo I, parte II, ponto 1, pede uma SBOM num formato de uso corrente e legível por máquina que abranja, no mínimo, as dependências de nível superior dos produtos. Se o componente se destina a ser integrado noutros produtos, as suas instruções também têm de dar a informação de que o integrador precisa para cumprir os requisitos essenciais (anexo II, ponto 8, alínea f)).

O OEM tem obrigações que também chegam até si. Tem de exercer a devida diligência ao integrar componentes provenientes de terceiros (artigo 13.º, n.º 5) e, quando encontra uma vulnerabilidade num componente que integrou, tem de a comunicar à pessoa ou entidade que fabrica ou mantém o componente (artigo 13.º, n.º 6). As orientações da Comissão sobre o CRA de julho de 2026 dizem que a evidência de devida diligência "may consist of documentation obtained from the component manufacturer", e não mencionam SBOM; na prática, uma SBOM é muitas vezes a documentação que os OEM pedem. As obrigações de notificação aplicam-se a partir de 11 de setembro de 2026 e o regulamento aplica-se na íntegra a partir de 11 de dezembro de 2027. As peças sobresselentes fabricadas segundo a mesma especificação dos componentes que substituem estão excluídas (artigo 2.º, n.º 6). Para o resto do regulamento, consulte o que é o CRA e o guia do CRA.

Veículos

O CRA não se aplica a produtos abrangidos pelo Regulamento (UE) 2019/2144, o regulamento de homologação de veículos (artigo 2.º, n.º 2, alínea c)). Os componentes de veículos homologados chegam ao mercado ao abrigo de regras próprias dos veículos, e essas regras nunca mencionam uma SBOM.

• O Regulamento n.º 155 da ONU (cibersegurança) obriga o fabricante a recolher e verificar informação "through the supply chain so as to demonstrate that supplier-related risks are identified and are managed" (5.1.1(a)), a mostrar como o seu sistema de gestão da cibersegurança "will manage dependencies that may exist with contracted suppliers, service providers or manufacturer's sub-organizations" (7.2.2.5) e a "identify and manage, for the vehicle type being approved, supplier-related risks" (7.3.2).
• O Regulamento n.º 156 da ONU (atualizações de software) exige que todas as versões de software iniciais e atualizadas sejam identificáveis de forma única (7.1.1.2) e, para cada RX Software Identification Number (RXSWIN), "an auditable register describing all the software relevant to the RXSWIN" (7.1.2.3).
• A ISO/SAE 21434 organiza o trabalho de cibersegurança entre OEM e fornecedor como atividades distribuídas, com a repartição acordada num cybersecurity interface agreement.
• O Auto-ISAC SBOM Informational Report (fevereiro de 2025) dá as orientações do próprio setor.

No setor automóvel, uma SBOM chega como requisito contratual, não legal.

Automação industrial

A IEC 62443-4-1 aplica-se a fornecedores de produtos de sistemas de automação e controlo industrial. Não menciona SBOM, mas a prática 6, gestão de questões relacionadas com a segurança (DM-1 a DM-6), e a prática 7, gestão de atualizações de segurança (SUM-1 a SUM-5, incluindo a SUM-3, "Dependent component or operating system security update documentation"), são onde uma SBOM serve de evidência.

Máquinas

O Regulamento (UE) 2023/1230 relativo às máquinas aplica-se a partir de 20 de janeiro de 2027 e não menciona SBOM. Os seus requisitos essenciais de proteção contra a corrupção (anexo III, 1.1.9) pedem que o software crítico para a conformidade seja identificado e protegido, que a máquina consiga identificar o software nela instalado que é necessário para funcionar em segurança, e que seja recolhida evidência das intervenções nesse software. As máquinas com elementos digitais também estão abrangidas pelo CRA, ao contrário dos veículos homologados, e é por isso que os fabricantes de máquinas pedem agora SBOM aos seus fornecedores. Consulte o CRACI para fabricantes de máquinas e IoT industrial.

NIS2 e clientes certificados

Se fornece entidades essenciais ou importantes, por exemplo no setor dos semicondutores, o artigo 21.º, n.º 2, alínea d), da NIS2 obriga o seu cliente a tratar da segurança da cadeia de abastecimento. Não menciona SBOM. Os clientes convertem-no em questionários, e os controlos 5.21 e 8.8 do Anexo A da ISO/IEC 27001 são onde uma SBOM serve de evidência. Consulte SBOM como evidência de ISO 27001, SOC 2 e NIS2.

Os regimes lado a lado

Regime	Aplica-se a	Menciona uma SBOM?	O que chega ao fornecedor
Cyber Resilience Act	Produtos com elementos digitais no mercado da UE, incluindo componentes vendidos separadamente	Sim, anexo I, parte II (1)	Diretamente, se colocar o componente no mercado; através da devida diligência do OEM (art. 13.º, n.º 5) e das comunicações de vulnerabilidades (art. 13.º, n.º 6)
UN R155 e R156	Fabricantes de veículos que procuram a homologação	Não	Gestão do risco de fornecedores (R155 7.2.2.5, 7.3.2) e identificação de software (R156), através de contratos
ISO/SAE 21434	Engenharia de cibersegurança de veículos rodoviários, OEM e fornecedores	Não na sua descrição pública	Atividades distribuídas e um cybersecurity interface agreement
IEC 62443-4-1	Fornecedores de produtos de sistemas de automação e controlo industrial	Não	Diretamente, se for o fornecedor do produto; as SBOM servem de evidência para DM e SUM
Regulamento relativo às máquinas	Máquinas e produtos conexos no mercado da UE	Não	Identificação e proteção do software (anexo III 1.1.9); o CRA aplica-se em paralelo
NIS2	Entidades essenciais e importantes	Não	Questionários de segurança da cadeia de abastecimento e cláusulas contratuais (art. 21.º, n.º 2, alínea d), e n.º 3)

Seja qual for a via, o cliente precisa do mesmo: uma SBOM exata para cada versão de software que entrega.

O que os OEM costumam pedir

Os requisitos variam de OEM para OEM, mas convergem na mesma lista. Verifique a sua SBOM face a ela antes da primeira entrega.

Requisito	Expectativa habitual
Formato	CycloneDX ou SPDX, JSON ou XML, com uma versão mínima da especificação. A BSI TR-03183-2 define CycloneDX 1.6 ou posterior, ou SPDX 3.0.1 ou posterior.
Campos	Alinhados com os CISA 2026 Minimum Elements ou com a BSI TR-03183-2: autor, carimbo temporal e, para cada componente, nome, versão, produtor e identificadores
Identificadores	Um package URL sempre que o ecossistema o tenha, um CPE quando não tem, para que os componentes possam ser associados às bases de dados de vulnerabilidades
Licenças	Identificadores de licença SPDX. O especialista em licenças do OEM lê-os para avaliar o copyleft e outros riscos de licenciamento.
Hashes	Um hash de cada binário entregue, para que o OEM possa confirmar que a SBOM descreve o ficheiro que recebeu. O BSI pede SHA-512.
Profundidade	Dependências transitivas, não apenas o nível superior
Granularidade	Uma SBOM por versão de software ou número de peça entregue
Entrega e resposta	Um canal de entrega, e prazos de resposta para questões sobre vulnerabilidades

Muitos OEM verificam estes pontos automaticamente à chegada. Consulte a checklist de qualidade de SBOM para saber o que o seu cliente vai verificar e com que ferramentas, e exemplos de SBOM para ver o aspeto dos campos num ficheiro.

A sua SBOM quando há pouco ou nenhum open source

Uma ECU ou um controlador bare-metal com firmware proprietário gerado a partir de modelos tem uma SBOM honesta que pode ser curta: a aplicação proprietária, o seu bootloader, as bibliotecas ou a calibração de um fabricante de semicondutores, e qualquer open source, como uma biblioteca de criptografia. É uma resposta válida. As regras:

• Indique os componentes proprietários com os seus próprios identificadores: nome, versão e a sua empresa como produtor.
• Declare as incógnitas conhecidas, como uma biblioteca de um fornecedor cujo conteúdo não consegue ver.
• Nunca encha a SBOM para parecer exaustiva, e nunca omita uma biblioteca open source por ser pequena.

Para ecrãs e gateways baseados em Linux passa-se o contrário: centenas ou milhares de componentes, incluindo o kernel, o bootloader e os pacotes do sistema base (consulte dispositivos ligados). Uma SBOM que indica apenas a sua aplicação e algumas bibliotecas é a primeira coisa que uma equipa recetora assinala. Se compila com Yocto, consulte porque é que os scanners não veem o que está nos builds Yocto.

Contratos: o que acordar antes da primeira entrega

Cláusula	Porque é importante
Produtos e versões de software abrangidos	Para que ninguém discuta mais tarde se uma variante ou uma versão de serviço precisava de SBOM
Formato e versão da especificação	O pipeline de receção deles pode rejeitar qualquer outra coisa
Campos e o framework que seguem	"BSI TR-03183-2 v2.1.0" ou "CISA 2026 Minimum Elements" é verificável; "uma SBOM completa" não é
Momento da entrega	Cada versão, cada versão de software enviada ao OEM e cada correção
Canal de entrega	O portal de fornecedores do OEM, uma troca segura de ficheiros ou email ao abrigo de um NDA
Confidencialidade	Um NDA ou o acordo de fornecimento existente, que identifique a SBOM como informação confidencial
Restrições de utilização	Apenas gestão de vulnerabilidades e conformidade, sem partilha posterior sem consentimento
Notificação de vulnerabilidades, nos dois sentidos	O OEM comunica as vulnerabilidades que encontra no seu componente (CRA art. 13.º, n.º 6); a sua empresa comunica-lhe as suas
Expectativas quanto a VEX	Que formato, e com que rapidez avalia uma nova CVE
Conservação	Durante quanto tempo guarda a SBOM de cada versão, em linha com o período de suporte do produto
Exatidão e incógnitas conhecidas	Uma cláusula honesta sobre o que a SBOM pode e não pode cobrir protege ambas as partes

O SBOM Sharing Primer da CISA descreve o caso automóvel da mesma forma: os pedidos de SBOM "would be included in standard information exchange agreements (e.g., non-disclosure agreement, cybersecurity interface agreement, development interface agreement)".

Partilhar sem expor propriedade intelectual

Uma SBOM não é o seu código-fonte. Indica nomes, versões, produtores, licenças, hashes e relações dos componentes. Não contém o seu código, os seus algoritmos, os seus dados de calibração nem o seu projeto.

• O CRA não obriga os fabricantes a tornar a SBOM pública (considerando 77). Esta é entregue a uma autoridade de fiscalização do mercado mediante pedido fundamentado (anexo VII, ponto 8).
• As orientações de partilha da CISA descrevem os canais habituais para software proprietário: email ao abrigo de um NDA, o portal de fornecedores do cliente ou uma troca segura de documentos, ou um portal próprio com controlo de acessos, com contratos a reger a confidencialidade e o acesso.
• Opções práticas: uma SBOM completa por OEM ao abrigo de contrato; identificadores para as partes proprietárias que não revelem nomes internos de projetos; e um documento VEX separado, para poder atualizar o estado de uma vulnerabilidade sem reenviar a SBOM.

Com que frequência, e o que acontece depois da entrega

• Uma nova SBOM para cada versão de software que entrega, com o mesmo identificador que o OEM grava ou regista. Nos veículos, isso liga-se à identificação de software do R156.
• Uma SBOM corrigida quando encontra um erro numa que enviou.
• Uma declaração VEX ou um aviso de segurança quando avaliou uma vulnerabilidade.

A pergunta seguinte, "estão afetados pela CVE-X?", chega com a próxima grande vulnerabilidade. Esteja preparado para responder por versão entregue, o que só é possível se tiver guardado a SBOM de cada uma.

VEX: o que o seu cliente vai esperar a seguir

Um documento VEX indica se um produto é afetado por uma vulnerabilidade. Os Minimum Requirements for VEX da CISA (abril de 2023) definem quatro estados: not_affected, affected, fixed e under_investigation. Uma declaração not_affected deve indicar uma de cinco justificações, ou então uma declaração de impacto:

• component_not_present
• vulnerable_code_not_present
• vulnerable_code_not_in_execute_path
• vulnerable_code_cannot_be_controlled_by_adversary
• inline_mitigations_already_exist

Uma declaração affected precisa de uma declaração de ação: o que o cliente deve fazer. O VEX existe em três formatos: o perfil VEX do CSAF 2.0, o CycloneDX VEX e o OpenVEX. A saída SPDX 3.0 do Yocto inclui dados VEX por omissão (a variável SPDX_INCLUDE_VEX).

Exemplo prático. Um ecrã baseado em Linux inclui o OpenSSL 3.0.8. A CVE-2023-0464 descreve um consumo excessivo de recursos ao verificar cadeias de certificados X.509 que incluem restrições de política. O processamento de políticas está desativado por omissão, e o software do ecrã nunca o ativa. O fornecedor envia uma declaração OpenVEX ilustrativa:

{
  "@context": "https://openvex.dev/ns/v0.2.0",
  "@id": "https://example.com/vex/display-fw-5.3.0-2023-0464",
  "author": "Example Displays Product Security",
  "timestamp": "2026-11-11T09:00:00Z",
  "version": 1,
  "statements": [
    {
      "vulnerability": { "name": "CVE-2023-0464" },
      "products": [{ "@id": "pkg:generic/example/[email protected]" }],
      "status": "not_affected",
      "justification": "vulnerable_code_not_in_execute_path",
      "impact_statement": "X.509 policy processing is disabled by default and the firmware never enables it."
    }
  ]
}

Produzir SBOM de forma repetível

Como compila	Forma realista de produzir a SBOM
Software compilado em CI	Gerar a SBOM no build que produz o software entregue, e guardá-la com a versão
Linux embarcado baseado em Yocto	A saída SPDX do próprio Yocto (create-spdx), verificada quanto ao que omite, ou um registo do build Yocto
Firmware bare-metal de ferramentas baseadas em modelos	Uma biblioteca ou ferramenta geradora, nunca um editor de texto, mantida a cada versão e validada antes do envio
Binários de terceiros que integra	Peça a SBOM ao seu próprio fornecedor; análise binária como substituto até ela chegar

Seja qual for a via, valide o ficheiro antes de o enviar. A checklist de qualidade de SBOM indica os validadores que o seu cliente provavelmente vai executar, CycloneDX vs SPDX ajuda com o formato e normalizar a geração de SBOM trata de torná-la igual em todas as equipas.

Onde entra o CRACI

Para fornecedores que compilam no GitHub Actions, o CRACI substitui os runners alojados pelo GitHub e regista uma SBOM de cada build, pelo que cada versão entregue já tem uma.

• A SBOM indica o que o build efetivamente trouxe, incluindo dependências transitivas, com um package URL por pacote e a licença declarada de cada componente.
• A SBOM de cada job tem um estado de completude, para que saiba o que está a enviar antes de o enviar.
• As SBOM exportam como CycloneDX ou SPDX, e o CRACI suporta VEX.
• As SBOM monitorizadas são reavaliadas à medida que são publicadas novas vulnerabilidades, e o histórico de builds mostra que builds continham uma dependência vulnerável, dentro do seu período de retenção.
• Os builds Yocto correm nos runners do CRACI e estão documentados.
• É possível adicionar SBOM de terceiros, para que os componentes comprados sejam monitorizados juntamente com os seus próprios builds.

Quando o CRACI não é a resposta

• Não tem CI, ou compila em GitLab, Jenkins ou num servidor de builds. Hoje o CRACI suporta apenas o GitHub Actions; outros sistemas de CI estão no roadmap.
• O seu firmware é gerado a partir de ferramentas baseadas em modelos sem obtenção de pacotes. Um gravador de builds acrescenta pouco aí.
• Precisa de alojar SBOM para muitos OEM num portal de partilha, ou de assinar SBOM. O CRACI não oferece nenhuma das duas coisas.
• Os seus builds têm de correr na sua própria infraestrutura. Os runners alojados pelo cliente estão no roadmap.
• O seu cliente quer prova da gestão de segurança da sua organização, como um certificado ISO 27001 ou respostas a um questionário NIS2. Uma SBOM é evidência para parte disso, não uma certificação. O certificado ISO 27001 da própria CRACI abrange o serviço do CRACI, não o da sua empresa.

SBOM para fornecedores: perguntas frequentes

O meu cliente, um OEM, pediu uma SBOM. Sou obrigado a fornecê-la?

Muitas vezes é o contrato que o exige, mais do que a lei. Se coloca por si próprio um componente com elementos digitais no mercado da UE, o Cyber Resilience Act exige a sua própria SBOM. Caso contrário, a obrigação é do OEM, que a passa para si através da devida diligência e do acordo de fornecimento.

O CRA aplica-se a componentes que vendo a um fabricante?

Se colocar o componente no mercado da UE separadamente, sim: o artigo 3.º, ponto 1, inclui componentes de software ou de hardware colocados no mercado separadamente. Se só chega ao mercado dentro do produto do OEM, o OEM é o fabricante e tem de exercer a devida diligência sobre o seu componente (artigo 13.º, n.º 5). Os componentes de veículos homologados estão fora do CRA (artigo 2.º, n.º 2, alínea c)).

O UN R155 ou a ISO/SAE 21434 exigem uma SBOM?

Não. O R155 nunca menciona uma SBOM; obriga o fabricante do veículo a gerir os riscos relacionados com fornecedores. A ISO/SAE 21434 organiza o trabalho de cibersegurança com fornecedores através de interface agreements. No setor automóvel, as SBOM chegam como requisito contratual.

Que formato e campos vai um OEM esperar?

Normalmente CycloneDX ou SPDX em JSON ou XML, alinhados com os CISA 2026 Minimum Elements ou com a BSI TR-03183-2: autor e carimbo temporal e, por componente, nome, versão, produtor, package URL ou CPE, licença e hash, com dependências transitivas.

Com que frequência tenho de enviar uma SBOM atualizada?

Para cada versão de software que entrega, sempre que corrigir um erro, e com uma declaração VEX ou um aviso de segurança quando tiver avaliado uma vulnerabilidade. Acorde o momento de entrega no contrato.

Partilhar uma SBOM expõe a nossa propriedade intelectual?

Não. Uma SBOM indica nomes, versões, produtores, licenças, hashes e relações dos componentes, não código-fonte, algoritmos nem dados de calibração. Partilhe-a ao abrigo de um NDA ou do acordo de fornecimento, com a utilização restrita à gestão de vulnerabilidades e à conformidade. O CRA não exige que seja pública.

O que é o VEX, e o meu cliente vai pedi-lo?

O VEX indica se um produto é afetado por uma vulnerabilidade: not_affected, affected, fixed ou under_investigation, com uma justificação para not_affected. Conte com um pedido depois da próxima vulnerabilidade muito noticiada num componente que distribui.

O firmware da nossa ECU não tem open source. Como é a nossa SBOM?

Curta e honesta: a aplicação proprietária, o bootloader, eventuais bibliotecas ou calibração do fabricante de semicondutores e qualquer open source, como uma biblioteca de criptografia, cada um com os seus próprios identificadores, mais as incógnitas conhecidas. Não a encha.