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
Atualizado

Nota de atualização (23 out 2026). A lista de elementos mínimos segue agora a versão final publicada pela CISA e parceiros a 29 jul 2026. Acrescentámos o limite do número de versão quando há correções sem versão nova, com o caso do PHP de outubro de 2026.

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 continuam a ser a bitola prática. A versão final, publicada a 29 de julho de 2026 pela CISA com a NSA, o FBI e parceiros internacionais (entre eles o BSI, a ANSSI e o NCSC-NL), substitui a da NTIA de 2021. Por componente pede: produtor do componente (o antigo “fornecedor”; a própria CISA avisa que não é o mesmo que o “fabricante” do CRA), nome, versão, identificadores (purl e/ou CPE), relação de dependência, hash (valor e algoritmo) e licença. Sobre a própria SBOM pede: autor e assinatura do autor, data e hora, versão da SBOM, formato e versão do formato, ferramenta e versão da ferramenta, e contexto de geração (“antes do build”, “build”, “depois do build”). Este último campo é a regra deste artigo em formato de dados: diz se a SBOM saiu do build ou de um scan de binário.

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 número de versão tem um limite conhecido. Muitas distribuições Linux, e sistemas de build como o Yocto, aplicam correções de segurança como patches, sem mudar a versão de origem do componente. Em outubro de 2026, ao corrigir as falhas conhecidas como PHP2Shell, o projeto PHP publicou também correções mínimas para os ramos 7.4, 8.0 e 8.1, já em fim de vida, como ramos no repositório de código, sem versão numerada nem tarball. Nesses casos a versão sozinha não diz se a correção está aplicada. A SBOM gerada no build deve por isso registar também os patches aplicados (o sistema de build sabe quais são), e o estado de cada vulnerabilidade no produto comunica-se em VEX: afetado, não afetado, corrigido ou em investigação. No kernel Linux, as retroportagens baralham também os intervalos de versões afetadas dos registos CVE, como mostra o artigo 10.

A lista de produtos possivelmente afetados que o NCSC-NL publicou para essas falhas é um exemplo público do formato: documentos SPDX em que o estado de cada entrada deriva de relações VEX. O artigo 09 trata o caso do ponto de vista de quem fabrica.

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. Geração no pipeline. A SBOM gera-se em cada build com tag, guarda-se ao lado do binário, e nenhum humano a escreve ou corrige à mão. Quando algo está mal na SBOM, corrige-se a receita ou a configuração do build, e o build seguinte já sai certo.
  2. Ligação à monitorização. Carregada numa ferramenta de acompanhamento de CVE (por exemplo Dependency-Track), a SBOM 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. Lacunas declaradas. Um blob que não conseguimos decompor entra na SBOM numa linha própria, assinalado como lacuna. Perante uma autoridade de fiscalização, é essa marcação que mostra o que o inventário cobre e o que fica de fora.

Fontes