A 29 de julho de 2026, a CISA publicou os «Elementos Mínimos de 2026 para um Software Bill of Materials (SBOM), substituindo a base de referência da NTIA em vigor desde 2021, elaborada em colaboração com a NSA, o FBI e 15 agências internacionais de cibersegurança.
Os «Elementos Mínimos para uma SBOM de 2026» ( Software ,Bill of Materials (SBOM) ) constituem a especificação atualizada da CISA relativa aos dados que uma SBOM deve conter, sendo que a alteração mais significativa é de natureza estrutural e não numérica: os elementos de 2026 não proíbem as SBOMs geradas a partir de manifestos de código-fonte, mas exigem que os autores declarem como a SBOM foi gerada, calculem o hash do artefacto executável e identifiquem cada campo que não tenham conseguido preencher. Um SBOM baseado apenas num manifesto divulga agora as suas próprias lacunas num formato legível por máquina.
MetaDefender Software Supply Chain é a plataforma de segurança da cadeia de abastecimento de software d OPSWAT, concebida para analisar artefactos, ficheiros binários e camadas de imagens de contentores — precisamente a categoria de dados que os novos requisitos relativos a hash, contexto de geração e cobertura agora exigem.
Em resumo
- 17 campos de dados — 9 de metadados do SBOM, 8 de dados de componentes
- 6 práticas e processos
- 10 novos campos, 8 atualizações importantes, 1 eliminação (Controlo de Acesso, integrado em Distribuição e Entrega)
- Aplica-se a todo o software, «incluindo software de código aberto, software de IA e SaaS»
- Não se trata de novos requisitos — trata-se de um aperfeiçoamento da forma como as organizações geram e solicitam SBOMs
Alterações à SBOM de 2026 que são mais difíceis de cumprir para as SBOMs baseadas apenas no código-fonte
1. O valor hash do componente requer o artefacto executável
Os parâmetros «Valor de hash do componente» e «Algoritmo de hash do componente» especificam o que é submetido ao processo de hash: «o resultado gerado pela aplicação de um algoritmo de hash criptográfico a um artefacto de componente executável». Não se trata da entrada do manifesto, nem da cadeia de caracteres da versão declarada.
- Um analisador que lê os ficheiros package-lock.json, pom.xml ou requirements.txt não interfere com nenhum artefacto executável, pelo que ambos os campos de hash devolvem «desconhecido»
- Quando existir uma função hash, o algoritmo deve utilizar Nomes Textuais das Funções Hash da IANA e ser aprovado por uma autoridade como o NIST
- Os hash são o que permitem ao destinatário confirmar que o componente descrito é, de facto, o componente enviado
2. O contexto da geração da SBOM faz com que o método faça parte do registo
O «Contexto de Geração do SBOM» é a novidade mais discreta, mas a mais significativa do ponto de vista estrutural: «a fase relativa do ciclo de vida do software e os dados disponíveis no momento em que o autor do SBOM o gerou». A CISA define três valores — antes da compilação, durante a compilação e após a compilação — e associa cada um deles à forma como o SBOM foi produzido: um SBOM extraído do código-fonte corresponde à fase mais precoce, enquanto as ferramentas de análise binária o situam na fase mais tardia.
- As equipas de aquisição podem especificar qual a fase do ciclo de vida que aceitam, dando preferência às SBOMs extraídas do artefacto compilado em detrimento das que se baseiam no código-fonte
- As plataformas de gestão de vulnerabilidades podem ponderar os resultados de acordo com o contexto declarado
- Uma SBOM derivada do código-fonte continua a ser permitida, mas já não pode ser apresentada como equivalente a uma SBOM produzida a partir do ficheiro binário final
3. A abrangência substitui a profundidade, sem um mínimo exigido
O elemento «Profundidade» de 2021 exigia apenas dependências de nível superior — uma definição que a CISA afirma agora «refletia as capacidades das ferramentas SBOM na altura, em vez da profundidade de informação necessária para tomar decisões de segurança fundamentadas». A cobertura é mais exigente: «todos os componentes que constituem o software em questão, incluindo dependências transitivas. Não há profundidade mínima.»
O teste é funcional. Um destinatário «deverá poder concluir que uma vulnerabilidade recentemente comunicada não o afeta, caso a SBOM não inclua o componente associado à vulnerabilidade». A ausência torna-se prova, o que só se verifica quando a cobertura é suficientemente completa. É improvável que a análise do manifesto, por si só, atinja esse padrão para:
- Código ligado estaticamente e fornecido por terceiros — não deixa qualquer entrada no manifesto
- Projetos em C e C++ — nenhum gestor de pacotes universal controla as DLLs e os objetos partilhados incorporados durante a compilação
- Código-fonte copiado — que a CISA descreve como «efetivamente uma dependência que é mais bem acompanhada como um fork e uma relação de dependência»
- Container camadas de imagens — pacotes instalados através de comandos de camada, em vez de serem declarados num manifesto
As informações desconhecidas têm agora de ser declaradas
- Os autores devem distinguir as informações que lhes são desconhecidas das informações que foram deliberadamente ocultadas
- Recomenda-se aos autores que mantenham um processo que permita aos destinatários solicitar informações sobre conteúdos relacionados com a segurança que tenham sido censurados
- «As organizações podem considerar uma SBOM incompleta se o autor da SBOM ocultar dados essenciais sobre os componentes»
- A «Tolerância aos erros» foi substituída com base no facto de os destinatários «poderem esperar que os dados do SBOM sejam precisos» — os erros decorrentes da «seleção de ferramentas inadequadas» constituem agora um elemento legítimo na avaliação de risco do destinatário
Alterações adicionais introduzidas pela CISA nos elementos do SBOM de 2026
Alterar | O que é isto | Por que é importante |
Assinatura do autor do SBOM (novo) | Uma assinatura digital associada ao autor da SBOM | Permite que o destinatário confirme que a SBOM é autêntica e que não foi alterada após a assinatura |
Licença de Componente (nova) | A licença ao abrigo da qual cada componente é fornecido | Aborda os riscos relacionados com direitos de autor e conformidade; a CISA aponta para os identificadores de licença SPDX |
Dados processáveis por máquina (anteriormente «Apoio à automatização») | Apenas SPDX e CycloneDX | O SWID foi retirado por não ser amplamente utilizado; reduz os formatos aceites para dois |
Fabricante de componentes (anteriormente Nome do fornecedor) | Uma organização com nome por componente | Adiciona uma opção alternativa explícita de «proveniência desconhecida» quando a fonte não é clara |
Frequência (atualizada) | Uma nova SBOM para cada versão, atualização e compilação que inclua componentes alterados | É difícil manter esse ritmo manualmente, o que leva as equipas a optar pela geração automatizada |
Colmatar a lacuna pós-construção
A atualização de 2026 reflete a avaliação da CISA de que as ferramentas SBOM amadureceram o suficiente para exigir mais, e que a informação que agora espera obter se encontra para além da fase de compilação.
MetaDefender™ Software Supply Chain gera dados SBOM diretamente a partir do artefacto compilado:
- Analisa artefactos, ficheiros binários e camadas de imagens de contentores, em vez de se limitar apenas aos ficheiros de dependências
- Identifica ficheiros binários em C, C++ e C# através de metadados do Portable Executable e identificação baseada em assinaturas
- Gera SBOMs no CycloneDX e no SPDXe enriquece os relatórios existentes para identificar componentes e CVEs que não foram detetados em análises anteriores
- Faz referência cruzada às normas GHSA, CVE e EUVD e assinala as licenças não conformes
- Integra-se com pipelines de CI/CD e registos de artefactos, como o JFrog Artifactory, para que a geração da SBOM possa acompanhar cada compilação
Para saber como MetaDefender Software Supply Chain podem dar resposta aos requisitos de SBOM ao longo de todo o ciclo de vida do desenvolvimento:
FAQ
O que mudou nos elementos mínimos da SBOM previstos na CISA 2026?
A atualização adiciona dez novos campos de dados, introduz oito revisões significativas e remove um elemento. A alteração estrutural mais significativa substitui «Profundidade» por «Cobertura», e os novos campos, incluindo «Valor de hash do componente», «Contexto de geração da SBOM» e «Assinatura do autor da SBOM», elevam as expectativas quanto à forma como os dados da SBOM são produzidos e verificados.
Os elementos mínimos da SBOM previstos na CISA 2026 são obrigatórios?
Não. A CISA não estabelece qualquer prazo de conformidade nem mecanismo de aplicação e afirma que o documento «não constitui um parecer para efeitos de conformidade, regulamentares ou jurídicos». A força prática decorre dos requisitos de contratação pública e dos regulamentos que fazem referência a linhas de base de SBOM, como a Lei da Ciber-resiliência da UE.
Os elementos mínimos da SBOM da CISA 2026 exigem uma análise de ficheiros binários ou uma análise pós-compilação?
Não explicitamente. No entanto, o «Valor Hash do Componente» requer acesso ao artefacto executável, o «Contexto de Geração do SBOM» exige que os autores declarem a fase do ciclo de vida e os campos não preenchidos devem ser identificados como «desconhecidos». Um SBOM apenas com código-fonte cumpre, portanto, o formato, ao mesmo tempo que documenta as suas próprias lacunas.
Os elementos mínimos da CISA 2026 aplicam-se ao software de IA e ao SaaS?
Sim. O âmbito de aplicação abrange todo o software, incluindo o de código aberto, a IA e o SaaS. A CISA refere que estas categorias podem exigir elementos adicionais, mas não os define aqui, remetendo, em vez disso, para as orientações conjuntas do G7 sobre SBOM para a IA, publicadas em maio de 2026.
Que formatos de SBOM são aceites nos elementos mínimos da CISA 2026?
O SPDX e o CycloneDX, descritos como os dois formatos amplamente utilizados para gerar e utilizar SBOMs. As etiquetas SWID foram removidas por «não se tratar de um formato de dados SBOM amplamente utilizado para o qual existam várias ferramentas». As versões obsoletas de qualquer formato não devem ser utilizadas em software novo.
