A cibersegurança da CISA eleva o patamar básico de SBOMs, mas inventários melhores ainda deixam lacunas de segurança

A orientação de cibersegurança da CISA substituiu um patamar federal de cinco anos para listas de materiais de software, apesar de dúvidas persistentes sobre se as organizações conseguem utilizá-las de forma eficaz.

A Cybersecurity and Infrastructure Security Agency divulgou os Elementos Mínimos de 2026 para uma Lista de Materiais de Software com a National Security Agency, o Federal Bureau of Investigation e parceiros internacionais. A orientação atualiza a estrutura da National Telecommunications and Information Administration publicada em 2021.

Uma SBOM, ou lista de materiais de software, é um inventário legível por máquinas dos componentes e relacionamentos dentro de um produto de software. Ela pode indicar a uma organização se uma vulnerabilidade recém-divulgada aparece em algum lugar de suas aplicações ou infraestrutura.

A substituição é importante porque a estrutura de 2021 foi escrita quando as ferramentas de SBOM estavam, em sua maioria, voltadas à geração de inventários. Os sistemas atuais também trocam, combinam, validam e analisam esses inventários em pipelines de desenvolvimento e ambientes de clientes.

Essa transição cria a tensão central por trás da nova orientação. A CISA quer dados mais completos e consistentes que as máquinas possam processar, mas adicionar campos não garante que o inventário resultante seja completo ou acionável.

O patamar original da NTIA ajudou a estabelecer um vocabulário compartilhado. A nova estrutura de cibersegurança da CISA pede que produtores e consumidores de software tratem as SBOMs como dados operacionais de segurança, em vez de documentos estáticos de conformidade.

A cibersegurança da CISA substitui o patamar básico de SBOMs de 2021

A mudança mais importante é institucional e operacional: a CISA agora é responsável por um patamar mais amplo, projetado para a gestão rotineira de riscos de software.

A NTIA publicou os elementos mínimos originais em 12 de julho de 2021, após a Ordem Executiva 14028. Sua estrutura dividia uma SBOM aceitável em três categorias: campos de dados, suporte à automação e práticas e processos.

Os sete campos de dados originais abrangiam nome do fornecedor, nome do componente, versão, identificadores exclusivos, relações de dependência, autor da SBOM e um registro de data e hora. Os requisitos de automação incentivavam formatos legíveis por máquinas, enquanto as práticas operacionais tratavam de frequência de geração, distribuição, acesso, profundidade e lacunas conhecidas.

Esses elementos eram deliberadamente modestos. Eles definiam o menor inventário útil em uma época em que muitos fornecedores nunca haviam gerado uma SBOM.

A versão de 2026 atualiza e substitui essa estrutura. Ela sucede uma consulta pública que a CISA abriu em agosto de 2025 e encerrou em 3 de outubro de 2025.

O aviso de consulta pública afirmou que as ferramentas de SBOM foram além da geração, passando a incluir compartilhamento, análise e gestão. Também identificou uma participação crescente de comunidades de código aberto, governos e setores adicionais.

A CISA não criou uma regra federal obrigatória de compras por meio da orientação. Os elementos mínimos continuam sendo um patamar para gerar e solicitar SBOMs utilizáveis, não uma nova lei ou exigência universal.

Essa distinção é importante para os fornecedores. Um cliente pode adotar a estrutura em um contrato ou processo de aquisição, mas a publicação, por si só, não obriga todas as empresas de software a produzir uma SBOM.

O escopo pretendido é, ainda assim, amplo. A estrutura pode ser aplicada a softwares adquiridos ou desenvolvidos por órgãos governamentais, incluindo componentes de código aberto, software como serviço e software que envolve inteligência artificial.

A CISA também reconhece que serviços complexos podem exigir informações além do mínimo geral. Uma plataforma SaaS muda continuamente, enquanto um sistema de IA pode depender de modelos, conjuntos de dados, frameworks e serviços externos que não se parecem com pacotes convencionais.

Uma orientação separada focada em IA, divulgada em 2026, aborda algumas dessas diferenças. Os elementos mínimos gerais de SBOM continuam sendo o ponto de partida para esses inventários especializados.

Assim, as agências estão estabelecendo um piso comum, não descrevendo todas as possíveis cadeias de suprimentos de software. As organizações ainda precisam de políticas compatíveis com suas arquiteturas, riscos e obrigações regulatórias.

Essa é uma mudança mais consequente do que uma lista maior de campos. Ela desloca a conversa sobre SBOMs da definição de um documento para a manutenção de evidências compartilhadas sobre a composição de software.

Os novos elementos mínimos exigem mais contexto

O nome e a versão de um componente já não bastam quando equipes de segurança precisam distinguir pacotes, verificar artefatos e conectar descobertas entre ferramentas.

O patamar de 2026 preserva a estrutura de três partes estabelecida pela NTIA. Ele continua abrangendo campos de dados, formatos processáveis por máquinas e as práticas usadas para criar, atualizar e trocar uma SBOM.

No entanto, o modelo atualizado pede um contexto mais rico tanto sobre o software quanto sobre o próprio inventário. O processo de desenvolvimento destacou quatro adições: hashes de componentes, informações de licença, identificação da ferramenta e contexto de geração.

Um hash de componente é um valor criptográfico calculado a partir do conteúdo de software. Ele pode ajudar um consumidor a distinguir artefatos que compartilham nome e versão, mas contêm bytes diferentes.

Essa distinção importa quando fornecedores recompilam pacotes, aplicam correções privadas ou distribuem binários específicos para cada plataforma. Uma string de versão pode permanecer inalterada mesmo quando o artefato real é diferente.

No entanto, hashes não são um sistema universal de identidade. Os resultados dependem de qual objeto recebe o hash, se esse objeto é compactado e de como um processo de compilação empacota seus arquivos.

A Business Software Alliance levantou essa questão durante a consulta. Sua resposta do setor argumentou que o hashing pode fornecer validação útil, mas exige definições mais claras para arquivos compactados, arquivos extraídos, firmware e outras formas de software.

As informações de licença acrescentam outra dimensão. Elas ajudam as organizações a identificar os termos associados aos componentes, incluindo dependências de código aberto e proprietárias.

Os dados de licença dão suporte à revisão jurídica e à governança de componentes, mas também melhoram a identificação básica. Dois pacotes com nomes semelhantes podem ter diferentes condições de propriedade ou distribuição.

O nome da ferramenta registra qual sistema gerou a SBOM. Esse campo oferece aos consumidores uma forma de investigar resultados inconsistentes e entender por que dois scanners descrevem o mesmo artefato de maneiras diferentes.

O contexto de geração descreve como o inventário foi produzido. Uma SBOM criada a partir do código-fonte pode identificar componentes diferentes daqueles encontrados em uma imagem de contêiner, sistema instalado ou binário final.

Essa procedência afeta o que uma equipe de segurança deve inferir de dados ausentes. Uma varredura de código-fonte pode identificar dependências declaradas que nunca entram em uma compilação de produção. Uma varredura binária pode encontrar código incorporado que o manifesto do pacote omitiu.

A estrutura atualizada também torna mais precisos os campos já estabelecidos. Identificadores exclusivos são importantes porque sistemas automatizados de vulnerabilidades não conseguem correlacionar de forma confiável o nome de um pacote em texto livre com registros de segurança.

URLs de pacotes, identificadores Common Platform Enumeration e tags SWID oferecem maneiras estruturadas de identificar software. Nenhum esquema único abrange todos os componentes, portanto os produtores devem selecionar identificadores adequados ao ecossistema disponível.

As relações de dependência continuam centrais. Um inventário se torna mais útil quando mostra como um componente inclui ou depende de outro, em vez de apresentar cada item como uma linha sem relação com as demais.

Os elementos mínimos de 2021 já exigiam informações de dependência. A orientação atual dá mais peso operacional a esse requisito porque a triagem de vulnerabilidades depende cada vez mais de grafos de relacionamentos.

As práticas atualizadas também preservam o conceito de “desconhecidos conhecidos”. Os produtores devem identificar áreas em que as ferramentas disponíveis não conseguem determinar se existem dependências adicionais.

Essa linguagem evita uma suposição perigosa. Uma relação ausente pode significar que não existe dependência, ou pode significar que o gerador não conseguiu identificá-la.

A diferença é crítica durante a resposta a incidentes. As equipes de segurança precisam saber se um resultado negativo de busca representa evidência de ausência ou simplesmente visibilidade incompleta.

Na prática, a CISA está pedindo que os produtores associem confiança e contexto a seus inventários. Isso torna uma SBOM menos organizada, mas também torna os dados mais honestos.

Fornecedores de software enfrentam uma exigência maior de evidências

O novo patamar pressiona fornecedores a produzir evidências de segurança reproduzíveis, enquanto compradores precisam criar sistemas capazes de interpretá-las.

Para produtores de software, uma SBOM não pode mais ser tratada como um arquivo gerado uma única vez antes de uma revisão comercial. Ela precisa acompanhar o produto ao longo de lançamentos, recompilações, mudanças de dependências e divulgações de vulnerabilidades.

Isso exige integração com sistemas de desenvolvimento e entrega. Um produtor precisa gerar o inventário próximo o suficiente do processo de compilação para que ele descreva o artefato que os clientes realmente recebem.

As equipes também precisam de identificadores de componentes estáveis. Se a mesma dependência recebe identificadores diferentes em compilações sucessivas, a comparação automatizada e a troca de informações sobre vulnerabilidades tornam-se pouco confiáveis.

A divulgação da ferramenta e o contexto de geração criam uma expectativa relacionada. Os produtores precisam entender como seus scanners operam, quais fontes eles inspecionam e onde termina sua visibilidade.

Isso pode expor lacunas desconfortáveis. Uma empresa pode descobrir que seu scanner de compilação captura manifestos de pacotes, mas deixa de identificar plugins carregados dinamicamente, firmware incorporado, arquivos de código-fonte copiados ou binários proprietários.

As equipes de engenharia enfrentam então uma escolha prática. Elas podem melhorar o pipeline, documentar a área desconhecida ou obter melhores dados de composição de um fornecedor upstream.

Esse trabalho vai além dos especialistas em segurança. As equipes de compras precisam de cláusulas contratuais para receber SBOMs, as equipes jurídicas precisam de regras de distribuição, e as equipes de produto precisam de processos para atualizar os clientes.

Organizações que administram muitas aplicações também precisam de armazenamento pesquisável. Receber milhares de documentos JSON sem indexar seus componentes produz burocracia, não visibilidade operacional.

Portanto, a responsabilidade recai sobre compradores e vendedores. Os compradores precisam normalizar arquivos diferentes, proteger dados potencialmente sensíveis, monitorar novas vulnerabilidades e decidir quais descobertas merecem ação.

Uma correspondência bruta de componente não estabelece automaticamente a exposição. O código vulnerável pode estar excluído da compilação, desativado pela configuração ou inacessível durante a operação normal.

O Vulnerability Exploitability eXchange, ou VEX, pode fornecer declarações legíveis por máquinas sobre se um produto é afetado por uma vulnerabilidade. Essas declarações dependem de identificadores estáveis que conectem o registro VEX ao componente correto da SBOM.

Essa relação explica por que a qualidade dos identificadores se tornou mais importante. Um registro ambíguo de componente enfraquece toda tentativa posterior de descrever a explorabilidade ou a correção.

Ela também mostra por que os elementos mínimos da CISA não podem operar sozinhos. As organizações precisam de bancos de dados de vulnerabilidades, dados VEX, propriedade de ativos, contexto de execução e fluxos de resposta em torno do inventário.

Os contratados federais sentirão a pressão primeiro, porque as agências podem incorporar a linha de base aos requisitos de aquisição. É também provável que clientes corporativos adotem as mesmas perguntas em suas avaliações de fornecedores.

O alinhamento internacional amplifica esse efeito. Um fornecedor que atende diversos mercados se beneficia ao produzir um único inventário interoperável, em vez de manter versões nacionais separadas.

No entanto, a harmonização só reduz a carga quando os clientes interpretam a linha de base de forma consistente. Campos, formatos e regras de entrega adicionais e específicos de cada contrato podem recriar a fragmentação que os elementos mínimos pretendem evitar.

Portanto, as equipes de software devem tratar a orientação como um contrato de dados. Os produtores prometem um nível definido de visibilidade, e os consumidores prometem lidar com esses dados de forma responsável.

Uma base de conhecimento de engenharia pode ajudar as equipes a conectar decisões sobre SBOMs a registros de build, documentação de fornecedores e notas de correção. Ela não substitui uma plataforma de análise de componentes, mas pode preservar o raciocínio por trás de cada resposta.

A maior exigência de evidências não é inerentemente negativa. Inventários repetíveis podem encurtar a busca por produtos afetados quando uma dependência amplamente usada se torna vulnerável.

O benefício só aparece depois que as organizações conectam a geração à responsabilidade e à ação. Caso contrário, a SBOM aprimorada se torna mais um anexo que ninguém examina até o início de uma auditoria.

Dados Melhores de SBOM Ainda Não Podem Garantir Melhor Segurança

A linha de base mais abrangente da CISA melhora a entrada para a gestão de vulnerabilidades, mas grafos de dependências incompletos ainda podem produzir conclusões perigosamente confiantes.

Um preprint de julho de 2026 examinou 78.612 arquivos de SBOM de um conjunto de dados público, dos quais 77.092 puderam ser analisados. Os pesquisadores se concentraram nas arestas de dependência, em vez de apenas verificar se os campos de componentes existiam.

O estudo sobre grafos de dependência constatou que 52,9% das SBOMs analisáveis não declaravam nenhuma aresta de dependência. Cada componente nesses arquivos aparecia isolado.

Outros 8,8% continham um bloco de dependências, mas deixavam a maioria dos componentes desconectada. Entre os inventários maiores desse grupo, a mediana da proporção de componentes órfãos foi de 93%.

Apenas 38,3% da população total formava grafos bem conectados. O estudo também constatou que a qualidade dos grafos variava muito conforme o gerador, mesmo quando as ferramentas examinavam softwares comparáveis.

Essas conclusões vêm de um preprint e não devem ser tratadas como uma medição universal de inventários corporativos privados. Ainda assim, elas ilustram o problema de implementação por trás da ênfase da CISA nas relações de dependência e nos desconhecidos conhecidos.

Um inventário plano pode responder se o nome de um pacote aparece em algum lugar. Ele não consegue explicar de forma confiável qual aplicação o contém, o que depende dele ou se existe um caminho até o código vulnerável.

Essa limitação afeta a priorização. Alguns sistemas de segurança suprimem uma descoberta quando a SBOM não mostra nenhum caminho entre o produto e o componente afetado.

Se o grafo estiver incompleto, “sem caminho” não significa “não alcançável”. Significa que o inventário não tem evidências que conectem os nós.

O estudo testou uma abordagem que converteu resultados negativos suspeitos em um estado explícito de desconhecido. Em seu experimento controlado de reavaliação, a revocação em relação ao catálogo de Vulnerabilidades Conhecidamente Exploradas da CISA subiu de 0,600 para 0,950.

Esses números descrevem o sistema dos pesquisadores, não um resultado garantido para todas as organizações. A lição subjacente é mais ampla: a incerteza deve permanecer visível durante todo o processo de análise.

É nesse ponto que a conformidade mínima pode divergir da segurança operacional. Um arquivo pode conter todos os campos exigidos e ainda assim representar incorretamente o produto devido a uma descoberta superficial ou relações quebradas.

Os hashes de componentes também têm limites. Um hash pode verificar que dois objetos são idênticos, mas não explica se o objeto contém código vulnerável ou recebe entrada insegura.

Os campos de licença tampouco estabelecem segurança. Eles melhoram a governança de componentes, mas identificar corretamente uma licença não diz nada sobre a explorabilidade.

Os nomes das ferramentas e o contexto de geração ajudam os consumidores a avaliar a qualidade das evidências, mas somente se entenderem as ferramentas. Registrar “varredura de código-fonte” é útil quando o sistema receptor a trata de forma diferente de uma varredura de artefato pós-build.

As SBOMs também podem revelar informações sensíveis. Inventários detalhados de componentes podem expor escolhas arquiteturais, dependências antigas ou alvos que um atacante pode pesquisar.

As organizações precisam de políticas de distribuição que equilibrem acesso e risco. Um projeto público de código aberto, um dispositivo médico regulamentado e um sistema governamental restrito não exigem modelos de compartilhamento idênticos.

A atualização dos dados apresenta outro desafio. Um inventário preciso se torna enganoso após mudanças no software, a menos que os produtores o regenerem e os consumidores o associem à versão correta.

Os serviços em nuvem complicam essa associação porque seus componentes implantados podem mudar sem que o cliente baixe um novo pacote. Serviços contínuos precisam de práticas de atualização e notificação que inventários estáticos de produtos não oferecem.

Os sistemas de IA introduzem ambiguidade adicional. Modelos, conjuntos de dados, adaptadores, APIs remotas, frameworks de orquestração e bibliotecas convencionais podem influenciar o comportamento, mas nem todos os elementos se encaixam nos campos tradicionais de componentes.

A nova linha de base reconhece que sistemas especializados precisam de informações adicionais. Ela não resolve todas as questões sobre como inventariar um pipeline de modelos em mudança ou uma dependência hospedada externamente.

Essas limitações não tornam as SBOMs inúteis. Elas definem a fronteira entre visibilidade e garantia.

Uma lista de ingredientes pode ajudar a identificar um ingrediente recolhido, mas não pode provar que a cozinha seguiu procedimentos seguros. Desenvolvimento seguro, testes, aplicação de correções, monitoramento e resposta a incidentes continuam necessários.

A interpretação mais sólida da orientação, portanto, não é “mais campos equivalem a software seguro”. É “melhores evidências apoiam melhores decisões quando as organizações preservam seu contexto e sua incerteza”.

O Alinhamento Internacional Eleva a Importância

O apoio conjunto transforma a atualização da CISA em um ponto de referência que pode influenciar a compra de software muito além do governo federal dos EUA.

As cadeias de fornecimento de software cruzam fronteiras nacionais. Um produto projetado em um país pode conter pacotes de código aberto mantidos em vários outros e ser executado em infraestrutura operada em outro lugar.

Definições diferentes de SBOM criam atrito em toda essa cadeia. Os produtores precisam traduzir campos, regenerar arquivos ou explicar por que os dados exigidos por um cliente não existem em outro formato.

Parceiros internacionais vêm trabalhando para uma visão compartilhada do que as SBOMs devem alcançar. Sua participação na orientação de 2026 reforça o argumento em favor de dados mínimos comuns e intercâmbio legível por máquina.

Esse alinhamento não cria uma única lei global. Cada governo mantém suas próprias regras de aquisição, autoridade regulatória e cronograma de aplicação.

Ainda assim, ele pode moldar contratos e expectativas técnicas. Compradores frequentemente adotam linguagem de orientações governamentais porque ela fornece uma linha de base defensável durante avaliações de fornecedores.

A Lei de Resiliência Cibernética da União Europeia adiciona urgência para fabricantes que vendem produtos com elementos digitais. Seus requisitos criam um marco jurídico separado, mas o inventário de software e o tratamento de vulnerabilidades ocupam território operacional semelhante.

Fabricantes de dispositivos médicos enfrentam outro caso de uso já estabelecido. A lei dos EUA exige que fabricantes de determinados dispositivos cibernéticos forneçam uma SBOM e processos para tratar vulnerabilidades pós-comercialização.

Operadores de infraestrutura crítica também precisam de respostas rápidas quando uma biblioteca comum ou um componente incorporado se torna um alvo. Seu desafio frequentemente não é identificar uma dependência, mas localizá-la em sistemas de longa duração fornecidos por vários fornecedores.

Uma linha de base compartilhada ajuda apenas se os fornecedores upstream participarem. O produtor de uma aplicação finalizada nem sempre consegue identificar o conteúdo de um binário fechado recebido de outra empresa.

Requisitos contratuais podem levar essa solicitação mais profundamente pela cadeia de fornecimento. Eles também podem prejudicar fornecedores menores que não têm equipes dedicadas de conformidade e engenharia de segurança.

A ênfase da CISA na automação busca reduzir essa carga. Ferramentas modernas de desenvolvimento podem gerar inventários durante os builds, e formatos comuns permitem que sistemas downstream os processem sem transcrição manual.

A automação também pode ampliar erros. Se um scanner deixa sistematicamente de detectar dependências, cada SBOM gerada pode repetir o mesmo ponto cego com uma consistência impressionante.

Por isso, os testes de interoperabilidade importam tanto quanto a escolha do formato. Os produtores devem comparar resultados, validar grafos de relacionamento e confirmar que as ferramentas downstream preservam os identificadores corretamente.

Os consumidores precisam de disciplina recíproca. Devem definir como os dados de SBOM afetam compras, monitoramento, correção e comunicação com fornecedores antes de exigi-los em escala.

A Business Software Alliance apoiou expectativas harmonizadas durante a consulta de 2025. Também alertou contra requisitos de aquisição quando os destinatários não têm capacidade de ingerir e agir com base nas informações.

Essa posição resume a principal troca de política pública. Exigir evidências pode incentivar uma engenharia melhor, mas coletar evidências inutilizáveis desperdiça recursos e cria uma falsa sensação de controle.

O alinhamento internacional eleva a importância porque uma prática fraca pode se espalhar tão facilmente quanto uma boa. Uma linha de base reconhecida globalmente deve incentivar inventários consistentes e úteis, em vez de burocracia globalmente consistente.

Três Sinais Mostrarão se a Linha de Base de 2026 Funciona

A orientação só terá sucesso se a qualidade das dependências melhorar, os compradores operacionalizarem os dados e as práticas especializadas de SBOM permanecerem interoperáveis.

O primeiro sinal é uma melhoria mensurável nos grafos de dependência. Estudos futuros devem encontrar menos inventários planos, menos componentes desconectados e maior uso de indicadores explícitos de completude.

Esse resultado reforçaria a premissa da CISA de que elementos mínimos mais claros podem melhorar decisões de vulnerabilidade assistidas por máquina. Falhas contínuas nos grafos mostrariam que definições, por si só, não conseguem corrigir o comportamento dos geradores.

O segundo sinal é como as agências federais e os compradores corporativos mudam suas aquisições. Uma adoção útil conectará a entrega de SBOMs à validação, à propriedade de ativos, ao tratamento de VEX e às expectativas de resposta.

Solicitações que apenas adicionam um campo de upload a um questionário enfraquecerão o argumento. Elas aumentam o trabalho dos fornecedores sem melhorar a velocidade ou a qualidade das decisões de segurança.

O terceiro sinal é a interoperabilidade entre inventários convencionais, de nuvem e de IA. A orientação especializada deve estender a linha de base comum sem criar definições incompatíveis para identificadores, relacionamentos ou timestamps.

Um alinhamento bem-sucedido permitiria que uma organização rastreasse um pacote convencional vulnerável por meio de um serviço em nuvem ou aplicação de IA. Esquemas fragmentados recriariam as lacunas de visibilidade que a atualização de 2026 tenta fechar.

Os produtores de software não precisam esperar por esses resultados. Eles podem inspecionar os inventários atuais, identificar como cada um foi gerado e testar se os relacionamentos sobrevivem à ingestão em sistemas voltados ao cliente.

Os compradores podem realizar o mesmo exercício pelo outro lado. Pergunte se uma vulnerabilidade recém-divulgada pode ser rastreada de um registro de componente até um produto afetado, responsável, decisão e status de correção.

Esse fluxo de trabalho é o verdadeiro teste da orientação de cibersegurança da CISA. Se a sua organização recebesse hoje uma SBOM precisa, conseguiria transformar essa evidência em uma decisão de segurança oportuna?

Comece com um produto importante e acompanhe os dados desde a compilação até a resposta. Os elos ausentes revelarão se seu programa de SBOM é um controle operacional ou apenas um arquivo de inventário.