Suporte Técnico
Documentação
Entrar
Entre em contato conosco
Vá direto para um resumo gerado por IA desta postagem do blog 
Principais conclusões
- Os elementos mínimos da CISA para 2026 substituíram a linha de base de 2021 da Administração Nacional de Telecomunicações e Informação (NTIA) em 29 de julho de 2026 e estabeleceram 17 campos de dados.
- O Escritório de Gestão e Orçamento (OMB) revogou os memorandos federais sobre atestado de segurança de software em janeiro de 2026, deixando as solicitações de SBOM a critério de cada órgão.
- Os requisitos da CRA relativos à SBOM entram em vigor em 11 de dezembro de 2027 e estabelecem as dependências de nível superior como a cobertura mínima.
- Um componente pode estar corretamente listado em uma SBOM e, mesmo assim, ser malicioso, ter sido adulterado ou ter sido abandonado sem uma correção.
Os requisitos relativos à SBOM estão em constante evolução. O Escritório de Gestão e Orçamento (OMB) revogou seus memorandos de atestado federal em janeiro de 2026; a FDA reeditou suas diretrizes de segurança cibernética para dispositivos médicos em fevereiro; a CISA substituiu a linha de base de 2021 para dados de SBOM em julho, e a Lei de Resiliência Cibernética (CRA) da UE passará a exigir SBOMs dos fabricantes a partir de dezembro de 2027. Sempre que um SBOM for exigido, o que você deve entregar é uma lista do que está contido no seu software.
Essa lista é útil. A lista de ingredientes na embalagem de um alimento indica que o produto contém amendoim, o que é importante se você for alérgico. Verificar se a fábrica estava limpa ou se o fornecedor é quem afirma ser requer uma inspeção, o que é uma tarefa à parte.
Uma SBOM funciona da mesma maneira. Elaborar uma lista não altera sua exposição, pois qualquer componente vulnerável, adulterado ou abandonado permanece em seu software após a criação da lista. E nenhuma dessas quatro regras se limita à lista. A exigência federal inseriu a SBOM em um conjunto mais amplo de práticas de desenvolvimento seguro. O próprio documento da CISA afirma que a SBOM é um conjunto de dados que ainda precisa de análise, e a FDA e a CRA vão além, associando-a à obrigação de avaliar os componentes listados e aplicar correções neles.
O que os requisitos de SBOM exigem a partir de outubro de 2026
Quatro conjuntos de regras são os mais importantes neste momento. A tabela apresenta uma versão resumida, e as seções a seguir trazem os detalhes.
| Fonte | O que é solicitado | Situação em 7 de outubro de 2026 |
|---|---|---|
| Compras públicas federais (Decreto Presidencial 14028 e OMB M-26-05) | Entrega da SBOM aos compradores, a critério da agência de compras | A Ordem Executiva 14028 continua em vigor. As notas de atestado do OMB foram revogadas em 23 de janeiro de 2026. |
| Elementos mínimos da CISA 2026 | Um conjunto básico de campos de dados do SBOM | Publicado em 29 de julho de 2026. Substitui a linha de base da NTIA de 2021. |
| Seção 524B da FDA | Uma SBOM nos pedidos de autorização pré-comercialização para dispositivos cibernéticos | Em vigor para pedidos apresentados a partir de 29 de março de 2023. Orientação reeditada em 3 de fevereiro de 2026. |
| Lei de Resiliência Cibernética da UE | Uma SBOM que abranja, no mínimo, as dependências de nível superior | A obrigação relativa à SBOM entra em vigor a partir de 11 de dezembro de 2027. As obrigações de prestação de informações começaram em 11 de setembro de 2026. |
O que restou da exigência federal relativa à SBOM
A Ordem Executiva 14028, assinada em maio de 2021, marcou o início da exigência federal relativa à SBOM. A Seção 4(e)(vii) previa orientações do NIST sobre o fornecimento de uma SBOM aos compradores para cada produto, seja diretamente, seja por meio de um site público. A ordem não foi revogada, mas a maior parte da estrutura regulatória em torno dela foi desativada. Um decreto de junho de 2025 (EO 14306) removeu as disposições de atestado que o EO 14144, assinado em janeiro de 2025, havia acrescentado, incluindo a validação centralizada pela CISA dos atestados dos fornecedores. Em seguida, em 23 de janeiro de 2026, o memorando M-26-05 do OMB revogou os memorandos M-22-18 e M-23-16, que serviam de base ao Formulário de Atestado de Desenvolvimento Seguro de Software.
As agências ainda podem utilizar o formulário e incluir a entrega da SBOM nos termos contratuais, mas a política geral do governo não exige mais nenhuma dessas duas coisas. Se você vender software a um comprador federal, a obrigação de apresentar uma SBOM depende, atualmente, da política específica daquela agência e do contrato em questão.
A Linha de Base da CISA de 2026 para Dados de SBOM
Em 29 de julho de 2026, a CISA, a NSA, o FBI e 15 organizações parceiras internacionais publicaram os “Elementos Mínimos para uma Lista de Componentes de Software (SBOM) de 2026”. Esse documento substitui o de 2021 da Administração Nacional de Telecomunicações e Informação (NTIA), elaborado em resposta à Ordem Executiva 14028, e aumenta o número mínimo de campos de dados de 7 para 17. Os novos campos incluem a assinatura do autor da SBOM, um valor de hash e um algoritmo de hash para cada componente, as licenças dos componentes, o nome e a versão da ferramenta de geração, além de um contexto de geração indicando em qual fase do ciclo de vida a SBOM foi gerada, como antes ou depois da compilação.
Outras duas mudanças são relevantes na prática. A cobertura deve agora incluir dependências transitivas sem profundidade mínima, enquanto a versão de 2021 exigia apenas dependências de nível superior. Além disso, cada componente precisa ter pelo menos um identificador processável por máquina, como um Package-URL.
O documento afirma que seus elementos não criam novos requisitos, mas apenas aprimoram a forma como as organizações geram e solicitam SBOMs. Além disso, ele exclui a confirmação da precisão, cobertura e integridade de um SBOM dos elementos mínimos, uma vez que esses aspectos exigem medidas de qualidade diferentes daquelas fornecidas por uma assinatura.
Observação: A própria conclusão da CISA é que uma SBOM, por si só, consiste em dados sobre componentes de software, e que é a análise que transforma esses dados em insights.
Requisitos da FDA relativos ao SBOM nos termos da Seção 524B
O Congresso acrescentou a seção 524B à Lei FD&C por meio da Lei de Reforma Abrangente de Alimentos e Medicamentos, em dezembro de 2022. Ela se aplica a pedidos de aprovação pré-comercialização apresentados a partir de 29 de março de 2023 para um “dispositivo cibernético”, ou seja, um dispositivo que inclua software, possa se conectar à internet e possua características que o tornem vulnerável a ameaças cibernéticas. A FDA interpreta essa definição de forma ampla, tratando o firmware como software e considerando conectores como USB e portas seriais como meios de conexão. Os tipos de pedidos abrangidos são 510(k), PMA, PDP, De Novo e HDE. De acordo com a seção 524B(b)(3), o fabricante deve fornecer uma SBOM (lista de materiais de software) que abranja componentes comerciais, de código aberto e prontos para uso.
A orientação da FDA, reeditada em 3 de fevereiro de 2026, exige mais do que apenas os campos básicos. Ela recomenda que cada entrada de componente inclua seu status de suporte (como “em manutenção ativa”, “não mais mantido” ou “abandonado”) e sua data de fim de suporte, e que os fabricantes planejem como atualizar ou substituir componentes de terceiros quando o suporte terminar. Essa orientação não é vinculativa, é anterior à atualização da CISA de 2026 e ainda cita o trabalho da NTIA de 2021 sobre atributos básicos. A própria lei acrescenta uma obrigação de aplicação de patches. A Seção 524B(b)(2) exige que os fabricantes de dispositivos cibernéticos disponibilizem atualizações e patches em um ciclo regular para vulnerabilidades conhecidas e inaceitáveis e fora do ciclo para aquelas críticas que possam causar risco descontrolado.
Requisitos da CRA relativos à SBOM e o que eles deixam em aberto
O Anexo I, Parte II, ponto 1 da Lei de Resiliência Cibernética exige que os fabricantes identifiquem e documentem vulnerabilidades e componentes, inclusive por meio da elaboração de uma SBOM em um formato comumente utilizado e legível por máquina que abranja, no mínimo, as dependências de nível superior. O regulamento entrou em vigor em 10 de dezembro de 2024, e as principais obrigações, incluindo a exigência da SBOM, passam a vigorar a partir de 11 de dezembro de 2027. A SBOM faz parte da documentação técnica, e uma autoridade de fiscalização de mercado pode solicitá-la, devidamente justificada, quando necessário para verificar a conformidade. O compartilhamento com os usuários é opcional.
A Parte II do mesmo anexo também exige que os fabricantes tratem e corrijam vulnerabilidades sem demora, inclusive por meio do fornecimento de atualizações de segurança. O Artigo 13 impõe um dever de diligência ao integrar componentes de terceiros, incluindo os de código aberto, e exige que os fabricantes que descobrirem uma vulnerabilidade em um componente a comuniquem ao seu mantenedor e, em seguida, a corrijam em seu próprio produto. A obrigação relativa à SBOM, portanto, vem acompanhada de deveres que a própria SBOM não cumpre. A lista mostra o que há no produto, mas a verificação desses componentes e sua correção são tarefas que ainda cabem ao fabricante. O limite do nível superior também prejudica o cumprimento dessas obrigações na prática: quando um aviso é divulgado, o componente afetado costuma ser uma dependência transitiva, e uma SBOM que se limita às dependências de nível superior não indicará se você a possui. Cumprir a obrigação de correção é mais fácil com uma SBOM criada além do mínimo exigido.
O papel do NIST
Se você está procurando os requisitos do NIST para SBOM, a primeira coisa a saber é que o NIST não publica seus próprios elementos de dados de SBOM. A NTIA estabeleceu a linha de base em 2021, e a CISA definiu a atual. O papel do NIST é fornecer orientações sobre o processo. A Estrutura de Desenvolvimento Seguro de Software (SSDF, SP 800-218, versão 1.1) lista uma SBOM como um exemplo dos dados de proveniência que os produtores devem manter para cada componente de uma versão. O SSDF era importante para os fornecedores federais porque o formulário de atestado que o OMB revogou em janeiro exigia que eles confirmassem a conformidade com o SSDF. Desde essa revogação, uma agência ainda pode solicitar o atestado, mas a política governamental já não o exige.
Se um contrato exigir o cumprimento das normas do NIST, alinhe suas práticas de desenvolvimento ao SSDF, elabore uma SBOM que atenda aos elementos da norma CISA 2026 e gere-a novamente a cada lançamento. Nenhum órgão regulador exige os elementos da norma 2026 até o momento, mas eles constituem a linha de base publicada mais rigorosa, e uma SBOM elaborada de acordo com eles também atende aos requisitos mínimos da FDA e da CRA. Leia primeiro o texto do contrato, pois é ele que determina quais desses requisitos são importantes para o comprador.
Essas regras definem quem deve elaborar uma SBOM e o que ela deve incluir. A FDA e a CRA também mencionam as obrigações subsequentes, como a aplicação de correções e a devida diligência, mas pouco falam sobre como executá-las. É aí que a SBOM deixa de ser suficiente.
O que uma SBOM em conformidade não consegue fazer sozinha
Atenda a todos os requisitos de SBOM acima e você terá um documento que registra o que está presente no seu software. Ele pode registrar mais do que apenas nomes e versões, como um hash e uma assinatura do autor para cada componente. Outros documentos também podem ser anexados a ele. Uma declaração VEX (Vulnerability Exploitability eXchange) indica se uma vulnerabilidade listada afeta o produto, e um atestado de proveniência vincula um artefato à compilação que o produziu. Mesmo com tudo isso em mãos, ainda são realizadas três verificações adicionais.
O artefato corresponde à sua fonte?
A linha de base de 2026 exige um valor de hash para o artefato executável de cada componente e uma assinatura do autor da SBOM. O hash identifica o artefato descrito, e a assinatura garante que o autor declarado assinou a SBOM e que ela não foi alterada posteriormente. Nenhuma das duas verifica se o artefato corresponde ao repositório de código-fonte ao qual o projeto aponta. Se uma conta de mantenedor comprometida publicar uma versão adulterada, ou se um pacote do registro contiver código que não esteja no repositório do projeto, a SBOM registrará isso como qualquer outra entrada, com um hash que corresponda ao arquivo baixado.
A verificação de um artefato em relação ao seu código-fonte pode ser feita de diferentes maneiras. Um atestado de proveniência, por exemplo, vincula o artefato à compilação que o produziu. Uma recompilação a partir do código-fonte substitui o artefato do registro por um que você mesmo compilou, de modo que o que você distribui contém apenas o que está no repositório. Ambas as opções têm a mesma limitação: elas determinam se o artefato corresponde ao código-fonte, não se o código-fonte está intacto. Uma conta invadida ou um commit malicioso passa por qualquer uma dessas verificações.
Será que esse componente deveria ter sido admitido?
Typosquats, falsificação de namespace e pacotes com comportamento de instalação hostil são todos listados como qualquer outro pacote. A função do SBOM é registrar o que foi resolvido, e ele cumpriu essa função. A decisão de resolver ou não o pacote foi tomada anteriormente, e o CRA enquadra essa decisão como um exercício de devida diligência ao integrar componentes de terceiros.
Alguns ecossistemas executam código de pacotes durante a instalação ou a compilação. Um script de ciclo de vida do npm é executado durante a instalação, um script `build.rs` do Rust é executado durante a compilação e um gancho de inicialização `.pth` do Python pode executar código sempre que o interpretador é iniciado. Muitos pipelines geram a SBOM no momento da compilação ou posteriormente, de modo que o pacote é documentado depois de ter tido a oportunidade de ser executado.
Existe uma correção, e quem vai criá-la?
Uma SBOM, juntamente com dados de orientação, informa que um componente possui uma vulnerabilidade conhecida. Um documento VEX pode indicar se uma vulnerabilidade afeta seu produto, e o status de suporte — cujo registro é recomendado pelas orientações da FDA — indica se o fornecedor original ainda está ativo para corrigi-la. Tudo isso descreve o problema, mas nada disso gera um patch.
Imagine um componente em sua árvore de dependências com uma vulnerabilidade conhecida em uma linha de versão que não é mais mantida pelo desenvolvedor original. Às vezes, o projeto ainda está ativo em uma versão principal mais recente; outras vezes, foi totalmente abandonado. De qualquer forma, você pode atualizar, substituir ou aplicar um patch na versão que está executando. A atualização não está disponível quando não existe uma versão estável, e nem sempre é segura, mesmo quando existe. Substituir significa reescrever o código em todas as partes que utilizavam o componente, o que é mais difícil quando ele chegou como uma dependência transitiva que você nunca escolheu. Isso deixa a opção de aplicar um patch na versão que você está executando. Alguém precisa escrever a correção ou fazer o backport a partir da linha principal mais recente — se o projeto ainda estiver ativo lá — e, em seguida, verificar se o comportamento do componente permanece compatível. Esse é um trabalho específico, e é o tipo de trabalho que o upstream não vai realizar para um componente que não mantém mais.
Lado a lado, os três cheques ficam assim.
| Verificar | Quando tiver que acontecer | O que uma SBOM pode registrar | O que ele não consegue fazer |
|---|---|---|---|
| O artefato corresponde à sua fonte | Antes que o pacote entre na sua compilação | Um hash e uma assinatura do autor | Compare o artefato com sua fonte |
| É seguro admitir que o componente é seguro | Antes que o pacote entre na sua compilação | Nome, versão e relações | Avalie se é seguro executar o pacote |
| Existe uma correção, que é aplicada | Quando uma vulnerabilidade é identificada | Status do suporte e dados VEX, quando fornecidos | Criar ou aplicar um patch |
Como é o restante do trabalho
Cada uma das três verificações é uma tarefa que alguém deve realizar. A triagem determina se um pacote deve ser aceito antes de chegar à máquina de um desenvolvedor ou a um agente de compilação. A recompilação a partir do código-fonte gera um artefato que corresponde ao código no repositório do projeto. A aplicação contínua de patches mantém os componentes atualizados mesmo quando o desenvolvimento upstream fica mais lento ou é interrompido.
Segundo o SSDF: a estrutura do NIST cita, como exemplos para componentes de terceiros, a necessidade de revisá-los antes do uso, verificar se cada um ainda recebe manutenção, planejar medidas para aqueles que não recebem e compilar a partir do código-fonte quando a proveniência de um binário não puder ser confirmada.
Você ainda precisa da SBOM para responder à pergunta “fomos afetados?” quando um alerta é divulgado. Ela só responde bem a essa pergunta quando abrange as dependências transitivas e reflete o que realmente foi lançado, o que é um dos motivos para elaborá-la de acordo com a linha de base de 2026 da CISA, em vez do nível mínimo exigido pela CRA.
Ao avaliar qualquer uma das ferramentas de segurança da cadeia de suprimentos disponíveis no mercado, pergunte-se em que ponto da sequência cada uma delas atua: antes que o pacote chegue até você, durante a instalação ou depois que o artefato já estiver instalado. Muitas ferramentas dessa categoria geram relatórios sobre o que já está presente, e um ataque que ocorra durante a instalação, a compilação ou a inicialização do interpretador já terá sido executado quando o relatório chegar.
O SecureChain da TuxCare entra em ação antes que o pacote chegue até você. Ele verifica os pacotes em busca de malware oculto e códigos suspeitos, bloqueando aqueles que não passam na verificação. Em seguida, ele recompila os pacotes a partir do código-fonte em ambientes de compilação isolados. Para componentes ativos, ele corrige vulnerabilidades de acordo com o SLA à medida que surgem CVEs e, quando o desenvolvedor original deixa de manter um pacote, o Endless Lifecycle Support (ELS) garante que as correções continuem sendo fornecidas. A cobertura abrange pacotes em JavaScript, Python, Java, Go, Rust e PHP.
O que fazer depois que a SBOM estiver pronta
Os requisitos de SBOM passaram por várias mudanças desde 2021; portanto, trate o documento como algo que você deve regenerar a cada lançamento e priorize os controles que reduzem o risco antes mesmo de gerá-lo. Se você ainda não tiver um, elabore-o de acordo com os elementos da CISA 2026, incluindo dependências transitivas. Se já tiver um, verifique se ele vai além das dependências de nível superior e reflete o que realmente foi lançado. Caso contrário, gere um novo a partir da árvore de dependências resolvida ou do artefato compilado, sem limite de profundidade, antes de fazer qualquer outra coisa com ele. Em seguida, compare-o com os dados dos alertas de segurança, classifique os componentes vulneráveis de acordo com a existência ou não de uma correção no fornecedor original e decida o que fazer com aqueles que não têm correção. Você pode substituir o componente, solicitar que alguém aplique um patch na versão que você utiliza ou registrar uma aceitação explícita do risco.
Se a sua SBOM continuar sinalizando pacotes que ninguém mantém, veja como o SecureChain for Open Source bloqueia pacotes de risco antes que eles cheguem ao seu ambiente e continua aplicando correções neles mesmo após o término do suporte do desenvolvedor original.
Perguntas frequentes
O que são os requisitos de SBOM?
Os requisitos de SBOM são normas que obrigam os fabricantes de software a fornecer uma lista de materiais de software, ou seja, uma lista dos componentes de um produto. Os principais são a seção 524B da FDA para dispositivos médicos, em vigor desde 2023; a Lei de Resiliência Cibernética da UE, que entrará em vigor em 11 de dezembro de 2027; e os termos de compras federais que as agências dos EUA agora estabelecem caso a caso, por contrato. Os Elementos Mínimos de 2026 da CISA definem os campos de dados básicos.
Ainda existe uma exigência federal relativa à SBOM?
A Ordem Executiva 14028, que estabelecia orientações sobre o fornecimento de uma SBOM aos compradores, continua em vigor. O Escritório de Gestão e Orçamento (OMB) revogou os memorandos que exigiam atestados de segurança de software (M-22-18 e M-23-16) em 23 de janeiro de 2026. As agências dos EUA ainda podem solicitar uma SBOM nos termos do contrato; portanto, a obrigação de fornecê-la depende do comprador.
Quais são os requisitos da FDA relativos à SBOM para dispositivos médicos?
A Seção 524B da Lei FD&C exige que uma SBOM abranja softwares comerciais, de código aberto e prontos para uso em submissões pré-comercialização de dispositivos cibernéticos, ou seja, dispositivos com software capaz de se conectar à internet e que possam estar vulneráveis a ameaças cibernéticas. A orientação da FDA de fevereiro de 2026 também recomenda listar o status de suporte e a data de fim de suporte de cada componente.
Quais são os requisitos da CRA relativos à SBOM?
A Lei de Resiliência Cibernética da UE (CRA) exige que os fabricantes de produtos com elementos digitais elaborem uma SBOM em um formato comumente utilizado e legível por máquina, abrangendo, no mínimo, as dependências de nível superior. A obrigação entra em vigor a partir de 11 de dezembro de 2027, e as autoridades de fiscalização de mercado podem solicitar a SBOM, mediante justificativa, para verificar a conformidade. A CRA também exige que os fabricantes corrijam, sem demora, as vulnerabilidades em seus produtos e componentes.
Como vocês cumprem os requisitos do SBOM do NIST?
O NIST não define os elementos de dados da SBOM. Esses elementos provêm dos “Elementos Mínimos de 2026” da CISA, que substituíram a linha de base de 2021 da Administração Nacional de Telecomunicações e Informação (NTIA), uma agência do Departamento de Comércio dos EUA. O papel do NIST é fornecer orientações sobre o processo na Estrutura de Desenvolvimento Seguro de Software (SP 800-218); portanto, a conformidade geralmente significa alinhar suas práticas de desenvolvimento a essa estrutura, produzir uma SBOM que atenda aos elementos da CISA e atualizá-la a cada lançamento.
Uma SBOM torna o software mais seguro?
Não por si só. Uma SBOM registra quais componentes estão presentes no software, o que ajuda você a agir quando uma vulnerabilidade é divulgada. Ela não verifica se um pacote corresponde à sua fonte, não avalia se ele deveria ter sido instalado nem fornece um patch.
O que você pode fazer em relação a um componente que apresenta uma vulnerabilidade, mas para o qual ainda não há uma correção do desenvolvedor original?
Você pode substituir o componente ou aplicar um patch na versão que está executando. Substituir pode significar reescrever o código, e aplicar um patch significa que alguém precisa escrever e testar a correção, já que nenhuma versão do desenvolvedor original a oferece. Um fornecedor que ofereça suporte estendido para pacotes de código aberto em fim de vida útil pode fornecer esse patch. Listar o componente em uma SBOM documenta a exposição sem alterá-la.
