A CISA publicou em julho de 2026, em conjunto com a NSA, o FBI e agências internacionais, a versão atualizada dos elementos mínimos do SBOM, a referência mundial para transparência de componentes de software. O novo documento substitui os elementos mínimos publicados pelo NTIA em 2021 e chega em paralelo a um movimento europeu: relatório da ENISA de junho de 2026 registra organizações acelerando investimentos em geração e automação de inventários de software por causa da Cyber Resilience Act. Quem compra software, desenvolve produtos ou opera SaaS tem duas tarefas imediatas: revisar contratos para exigir os campos novos e ajustar o pipeline interno para gerar, versionar e assinar SBOMs de forma automatizada.
O que muda na referência global
O SBOM funciona como a lista de ingredientes de um software: um inventário aninhado dos componentes que compõem um produto, com nome, versão, produtor e relações de dependência. Desde 2021, os elementos mínimos definidos pelo NTIA serviam como piso comum para que compradores e fornecedores falassem a mesma língua. A atualização da CISA preserva os princípios centrais da versão anterior, mantém a automação como condição para segurança em escala e incorpora o retorno de uma consulta pública realizada em 2025. A revisão vale para todo tipo de software, incluindo código aberto, componentes de inteligência artificial e ofertas de SaaS — uma expansão explícita de escopo que atinge fornecedores que antes tratavam o SBOM como exigência de nicho.
Alguns campos foram renomeados para reduzir ambiguidade: Author of SBOM Data virou SBOM Author, Supplier Name virou Component Producer e Version of the Component passou a ser Component Version. A mudança parece cosmética, mas quebra parsers e cláusulas contratuais que referenciam os nomes antigos. Ferramentas de ingestão e modelos de aquisição precisam de revisão técnica, não apenas de comunicação interna.
Novos campos que mudam a prática
A atualização acrescenta elementos novos como assinatura digital atribuível ao autor, algoritmo de hash do componente, licença, nome da ferramenta e contexto de geração. Cada campo resolve um problema concreto de confiança que frustrava compradores na versão anterior:
- SBOM Author Signature: assinatura digital do autor do documento, com garantia de que o conteúdo não foi alterado depois de gerado;
- SBOM Generation Context: fase do ciclo de vida em que o SBOM foi produzido — before build, build ou after build — o que muda o nível de confiança nos dados;
- SBOM Tool Name e Tool Version: identificação da ferramenta empregada, permitindo auditar qualidade e vieses de geração;
- Data Format Name e Version: formato e versão declarados, evitando interpretação errada por ferramentas de análise;
- Component Hash Algorithm e Component License: algoritmo de hash para validar a integridade do componente e licença para expor risco jurídico;
- SBOM Version e Timestamp: versionamento do próprio documento, com registro de data e hora conforme a RFC 9557.
Como exigir SBOM de fornecedores
A parte mais sensível da atualização não são os campos técnicos, e sim os elementos de processo: frequência de atualização, profundidade, cobertura, mecanismo de acesso e tratamento de correções. A orientação da CISA é que esses pontos apareçam explicitamente em política, contrato ou acordo — deixá-los implícitos transfere o custo do erro para quem compra. Uma matriz prática de exigência:
| Exigência contratual | O que verificar |
|---|---|
| Formato e versão declarados | SPDX ou CycloneDX com data format name e version preenchidos |
| Assinatura do autor | Validação criptográfica antes de ingerir o documento no repositório |
| Contexto de geração | SBOM gerado no build, não reconstruído depois por análise binária |
| Frequência | SBOM novo a cada release e a cada correção de segurança |
| Cobertura e profundidade | Todos os componentes, incluindo dependências transitivas conhecidas |
| Correção de erros | Prazo definido para o fornecedor corrigir dados errados |
| Acesso | Entrega por API ou repositório, não por e-mail avulso |
Para software de IA e SaaS, a CISA alerta que os elementos mínimos são o ponto de partida, não o teto: essas categorias podem exigir campos adicionais. Compradores devem prever no contrato a evolução das exigências, em vez de congelar o escopo na versão atual do documento.
Geração interna: integrar e assinar
Do lado de quem produz software, o trabalho se concentra no pipeline. A geração precisa ocorrer dentro do build, com ferramenta e versão declaradas, e o documento resultante deve ser assinado com a infraestrutura de assinatura já existente na organização — a orientação é reaproveitar chaves, ferramentas e processos de gestão de chaves em uso, não criar um sistema paralelo. Cada nova versão de componente ganha um SBOM com versão e timestamp próprios, o que permite comparar inventários entre releases e detectar mudanças inesperadas de dependência.
O SBOM também alimenta a resposta a incidentes. Quando surge uma vulnerabilidade em biblioteca, a pergunta operacional é onde o componente está instalado — sem inventário assinado e atualizado, a resposta depende de varredura manual e o prazo de contenção estoura. A mesma lógica vale para ataques que se propagam por repositórios e ferramentas de desenvolvimento, como o worm que se espalhou por repositórios a partir de uma sessão de IA sequestrada: conhecer a árvore de dependências antes do incidente é o que separa horas de dias.
Complementar o inventário com documentos VEX — atestados que declaram se um produto é afetado por uma vulnerabilidade conhecida — reduz o ruído de priorização, mas exige disciplina: VEX defasado é pior que VEX ausente, porque cria falsa sensação de cobertura.
O cronograma europeu da CRA
Na Europa, o motor da adoção é regulatório. A ENISA ouviu organizações de vários setores e tamanhos no fim de 2025 e concluiu que a CRA atua como acelerador da adoção de SBOM, com investimento amplo em geração e automação integradas ao ciclo de desenvolvimento e prazos de implantação encurtados. O relatório SBOM Adoption State of Play – 2026 confirma o que equipes de aquisição já sentem na prática: fornecedores que vendem no mercado europeu estão investindo para atingir os níveis de maturidade esperados pela nova lei.
Para fabricantes de produtos digitais vendidos na União Europeia, a CRA já impõe obrigações de notificação de vulnerabilidades e incidentes — um relógio que já detalhamos ao cobrir o prazo de 24 horas da lei. O SBOM é a base material dessas obrigações: sem inventário confiável, não há como afirmar quais produtos e versões são afetados por uma falha dentro do prazo legal.
Prioridades P1 e P2
P1 — nesta semana: atualizar modelos de contrato para citar a versão de 2026 dos elementos mínimos, com os novos nomes de campo; validar a assinatura dos SBOMs já recebidos; mapear quais fornecedores entregam SBOM hoje e em que contexto de geração.
P1 — em 30 dias: mover a geração de SBOM para dentro do pipeline de build, com ferramenta e versão declaradas, e armazenar os documentos em repositório consultável por API pela equipe de resposta a incidentes.
P2 — em 90 dias: automatizar o diff de dependências entre releases, integrar documentos VEX ao fluxo de priorização e treinar equipes de compras para ler um SBOM antes de renovar licenças.
A barreira não é tecnológica: SPDX e CycloneDX, os formatos predominantes, já comportam os campos novos. A barreira é processual — contratos, pipelines e responsabilidades que tratavam o SBOM como entregável eventual. Quem ajustar isso agora compra folga antes que a exigência chegue por via regulatória ou por cláusula de cliente grande.