Saltar para o conteúdo
folhas.io
secure by design para produtos ligados· Artigos

Artigos

SBOM para firmware embebido: o que o CRA pede e como se gera sem mentir

A lista de materiais de software exigida pelo CRA não se escreve à mão. Para firmware, a única SBOM credível sai do sistema de build, e o scan de binários serve para o que não construímos nós.

Publicado

O Cyber Resilience Act exige, no Anexo I, Parte II, que o fabricante identifique e documente os componentes do produto, incluindo através de uma SBOM em formato legível por máquina que cubra, no mínimo, as dependências de topo. A SBOM não tem de ser pública: faz parte da documentação técnica e é entregue às autoridades de fiscalização quando pedida.

Para uma aplicação web, isto é trabalho de uma tarde. Para firmware, é onde a maioria dos fabricantes vai falhar, e falhar de uma forma específica: entregando uma SBOM que parece completa e não é.

O problema do firmware

Uma imagem de firmware embebido tipicamente não tem gestor de pacotes a bordo. Não há base de dados dpkg ou apk para um scanner consultar. Quando se aponta uma ferramenta de análise de composição a um rootfs extraído, a cobertura depende do que sobreviveu à compilação: assinaturas de binários, banners de versão, strings. O resultado são lacunas grandes e silenciosas, porque a ferramenta não sabe o que não encontrou.

A consequência prática: uma SBOM gerada por scan de binário sobre firmware é um ponto de partida, e não chega como documento de conformidade.

A regra que resolve quase tudo

A SBOM credível sai do sistema de build, não do binário. O sistema de build é o único sítio que sabe exatamente o que entrou na imagem, com que versão, com que patches e com que licença.

Os três ecossistemas dominantes já fazem isto nativamente:

  • Yocto: a classe create-spdx está incluída por omissão via INHERIT_DISTRO desde o Kirkstone (4.0). Um build normal da imagem produz um .spdx.json no diretório de deploy, derivado dos mesmos inputs que produziram o binário. Para quem prefere CycloneDX, a meta-layer meta-cyclonedx produz SBOM CycloneDX 1.6/1.7 com CPE e purl corrigidos para melhor correspondência com o NVD.
  • Buildroot: make legal-info gera o manifesto completo de pacotes, versões e licenças; o conversor cyclonedx-buildroot transforma-o em CycloneDX JSON.
  • Zephyr: west spdx gera documentos SPDX 2.3 para a aplicação, o Zephyr, o build e as dependências de módulos. Atenção à limitação documentada: blobs binários de fornecedores e bibliotecas fora da árvore não entram; têm de ser acrescentados como componentes externos ou documentados como lacunas.

E o que não construímos nós?

É aqui que a análise de binários tem o seu lugar legítimo: o bootloader entregue pelo fornecedor do SoC, o blob de rádio, a biblioteca pré-compilada de um parceiro. Para esses, uma ferramenta de composição binária produz um documento que depois se reconcilia com o manifesto do build. O método são dois inventários, um do que controlamos e um do que herdámos, fundidos num só documento, com as lacunas identificadas como tal.

Diagrama: o sistema de build gera a SBOM do que construímos; o scan de binário inventaria os componentes herdados; os dois reconciliam-se num único documento final, com as lacunas declaradas.
Dois inventários, um documento: o build responde pelo que construímos, o scan pelo que herdámos.

Que formato

Os dois formatos aceites na prática são SPDX (norma ISO/IEC 5962) e CycloneDX (ECMA-424). A orientação técnica alemã BSI TR-03183-2, o documento mais citado por auditores e organismos notificados no contexto do CRA, recomenda CycloneDX 1.6+ ou SPDX 3.0.1+. CycloneDX tem um tipo de componente nativo firmware e suporte VEX integrado, o que o torna a escolha natural para o fluxo CRA; o Yocto produz SPDX nativamente. A resposta pragmática para quem usa Yocto: gerar ambos.

Como referência de conteúdo mínimo, os “minimum elements” norte-americanos (atualizados pela CISA em julho de 2026, substituindo a versão NTIA de 2021) continuam a ser a bitola prática: fornecedor, nome, versão, identificador único (purl e/ou CPE), relação de dependência, autor e data da SBOM. O campo que mais vale é a versão: a correspondência com vulnerabilidades é precisa ao número. “Usamos OpenSSL” não diz nada; “OpenSSL 3.0.11” diz exatamente que advisories se aplicam.

O que isto significa para quem fabrica

Três decisões que tomamos no nosso próprio produto, e que recomendamos a qualquer equipa:

  1. A SBOM é um artefacto do pipeline. Gera-se em cada build com tag, guarda-se ao lado do binário, e nenhum humano a escreve ou corrige à mão. Se o processo exige edição manual, o processo está errado.
  2. A SBOM só é útil ligada a monitorização. Um inventário parado é conformidade de papel; ligado a uma ferramenta de acompanhamento de CVE (por exemplo Dependency-Track), torna-se o sistema de alerta que alimenta a obrigação de gestão de vulnerabilidades do próprio CRA, e o gatilho do processo de reporte de 24h/72h.
  3. As lacunas declaram-se. Um blob que não conseguimos decompor é uma linha na SBOM com essa indicação, não uma omissão. Perante uma autoridade de fiscalização, uma lacuna documentada é um estado; uma omissão descoberta é outro problema.

Fontes