Summary

  • No GAO-26-107530, dirigentes de 17 entre 24 órgãos federais relataram choque entre orientações de OMB e NIST para coletar e guardar listas de componentes de software (SBOM). Trata-se de dificuldades informadas na aquisição, não de 17 invasões nem de um ranking de produtos inseguros.
  • O GAO descreveu a antiga OMB M-22-18 como coleta facultativa de um artefato estático, em contraste com a orientação NIST para dados por versão aproveitáveis na análise de vulnerabilidades. Em janeiro de 2026, OMB revogou M-22-18 e passou a permitir em M-26-05 que cada órgão exija por contrato uma lista atualizada quando a solicitar.
  • O GAO pediu à Cybersecurity and Infrastructure Security Agency (CISA) instruções práticas para gerar, receber, analisar e usar esses dados em compras, desenvolvimento e gestão de risco. O teste real começa quando a lista chega a alguém responsável por agir sobre um componente vulnerável.

A lista comprada e a lista usada

SBOM é a relação das peças que compõem uma versão de software. No processo de compra, ela pode provar que o produtor entregou um documento. Na operação de segurança, seus dados podem responder se uma biblioteca recém-identificada como vulnerável está dentro de um serviço que continua rodando. A primeira tarefa termina no protocolo. A segunda precisa de versão, formato processável, atualização e uma pessoa encarregada de decidir o que fazer.

O relatório do GAO sobre desafios nas compras federais de serviços em nuvem, publicado em 23 de junho de 2026, ouviu dirigentes de TI e aquisição em 24 órgãos. Em 17 deles, as orientações de OMB e NIST foram descritas como conflitantes para a coleta e a guarda de SBOMs. É um número de respostas institucionais sobre atrito de compra. O mesmo relatório encontrou 17 órgãos com dificuldades para controlar custos de nuvem; essa coincidência aritmética pertence a outra pergunta. Nenhuma das duas contagens mede incidentes de segurança.

No texto integral do GAO, a fricção antiga aparece em três pontos. A OMB M-22-18 tratava a coleta como opcional, enquanto o NIST incentivava produtores a acompanhar e compartilhar componentes a cada versão. OMB mandava os órgãos montar procedimentos para receber os dados; o NIST apontava dados fornecidos pelo produtor em formatos padronizados. Para OMB, a lista aparecia como prova de conformidade; para o NIST, podia alimentar a busca de vulnerabilidades e a gestão do risco. Redigir um contrato com essas duas ideias sem definir a passagem entre elas gera trabalho e pouca clareza.

Cinco órgãos disseram ao GAO que formulários e rotinas diferentes em cada órgão criariam dificuldades para produtores que atendem vários compradores federais. Outros cinco relataram obstáculos para obter SBOMs, inclusive quando um revendedor se coloca entre comprador e fabricante. Esses grupos podem se sobrepor. O ponto comum é a transferência da evidência: quem cria a lista, a que versão ela se refere, qual formato aceita o comprador e quem consegue recebê-la quando o software já está instalado?

Janeiro revogou o memorando antigo

A OMB M-26-05 de 23 de janeiro de 2026 revogou M-22-18 e sua orientação companheira M-23-16. A velha regra explica o que o GAO investigou, mas deixou de ser a ordem em vigor. A nova política atribui ao dirigente de cada órgão a responsabilidade pela segurança de software e equipamentos, mantém a exigência de inventários completos e permite cláusulas contratuais para pedir um SBOM atual. Se o objeto é uma plataforma de nuvem, a cláusula deve abranger o ambiente de produção em execução.

Essa escolha descentraliza o pedido, mas concentra a responsabilidade por decidir. O órgão pode adequar sua exigência ao risco. Se decidir usar SBOM, terá de estabelecer quando pode exigir a informação, a rapidez da entrega, a versão coberta e quem a analisa. Segundo o GAO, a política de janeiro esclareceu competências, mas não resolveu as dificuldades práticas. Um arquivo facultativo sem prazo de entrega ou sem caminho até a equipe que investiga vulnerabilidades é uma vitória para o arquivo morto.

A orientação do NIST para a cadeia de software coloca o componente dentro do trabalho de segurança. A visão conjunta publicada pela CISA em setembro de 2025 defende gerar, consumir e analisar listas junto às práticas de desenvolvimento e risco. O GAO avaliou que faltava explicar concretamente como os órgãos integrariam os dados a seus processos e ferramentas. Dizer que a lista é útil não instala a conexão entre compras e operação.

A ponte ficou a cargo da CISA

O GAO recomendou ao Department of Homeland Security encarregar a CISA de instruções adicionais para geração, recebimento e análise de SBOMs em compras, desenvolvimento e gestão do risco. O departamento concordou. Em sua resposta, estimou 30 de setembro de 2026 para concluir o trabalho. A data é previsão; ao verificar esta pauta, a página pública do GAO ainda marcava a recomendação como aberta. Uma orientação emitida e aplicada precisará de evidência própria.

A ponte operacional exige cinco peças. O produtor identifica a versão entregue ou o ambiente ativo; o contrato dá acesso tempestivo aos dados mesmo quando há revendedor; o formato permite comparação com avisos de vulnerabilidade; atualizações acompanham novas versões; e um operador nomeado decide e registra a resposta. OMB define a escolha de política, NIST orienta a prática técnica e CISA recebeu o encargo de transformar essa divisão em instrução executável.

Uma orientação oficial da CISA que detalhe essas passagens, seguida de contratos e processos mostrando dados atuais recebidos e usados, mudaria a avaliação. O GAO já demonstrou a fricção em 17 órgãos. Uma lista de peças vale mais do que uma folha arquivada quando permite localizar a peça que está em produção e tomar uma decisão antes que a próxima falha a torne notícia.

Sources