SBOM de fornecedores: como avaliar e cobrar correções

Quando um fornecedor entrega uma versão nova de software acompanhada do inventário de componentes, alguém na área de TI precisa decidir se aquele arquivo sustenta o aceite ou se a entrega volta com pendências. O Software Bill of Materials, o SBOM, é esse inventário, uma lista dos componentes e subcomponentes que formam o produto, do código próprio às dependências de terceiros. 

A dificuldade está em que um arquivo válido no formato pode estar cheio de lacunas, e a validação sintática das ferramentas não diz se o inventário descreve o software que foi implantado. O poder de cobrança do comprador mudou de patamar com a publicação do 2026 Minimum Elements for a Software Bill of Materials (SBOM), orientação conjunta da CISA com a NSA, o FBI e 16 agências de cibersegurança de outros países. O documento substitui os elementos mínimos publicados pela NTIA em 2021. 

A mudança de maior consequência prática troca o elemento de profundidade, que pedia apenas as dependências diretas, pelo de cobertura, que passa a pedir todos os componentes, com as dependências transitivas e sem profundidade mínima. A orientação define o que pedir, não como julgar o que chegou, e essa parte permanece com o comprador. 

SBOM de fornecedores: o que o arquivo precisa cobrir para sustentar uma decisão 

O elemento de cobertura pede todos os componentes que formam o software, inclusive as dependências transitivas. Quando existem várias instâncias de um mesmo componente com metadados diferentes, cada instância precisa aparecer separadamente, com a relação de dependência correspondente. Arquivos que não são código podem ficar de fora, com espaço para os que têm efeito sobre segurança, como os de configuração. 

O critério de aceitação que a própria orientação oferece é o da inferência negativa. O destinatário de um SBOM deve conseguir concluir que uma vulnerabilidade recém-divulgada não o afeta pelo fato de o componente associado a ela não constar da lista. Esse teste vale mais que qualquer contagem de itens, e se a ausência de um componente não permite concluir nada, o inventário não sustenta decisão nenhuma. 

A diferença entre lacuna aceitável e entrega incompleta está no elemento de identificação explícita de informação desconhecida. Quando um campo não vem preenchido, o autor do SBOM precisa declarar se a informação é desconhecida para ele ou se está sendo retida, e manter um processo pelo qual o destinatário pergunte sobre o que foi suprimido. A orientação diz que organizações podem considerar incompleto um inventário no qual o autor retém dados essenciais de componente. 

Correspondência entre o SBOM e o software que foi implantado 

O elemento de contexto de geração registra a fase do ciclo de vida do software no momento em que o inventário foi gerado, com referências como antes da construção e depois da construção. Um SBOM gerado do código-fonte descreve o que os desenvolvedores declararam como dependência, e um produzido por análise de binário descreve o que acabou dentro do artefato distribuído. As duas listas divergem, porque a construção agrega bibliotecas do ambiente e deixa de fora código que não entrou no pacote. 

A verificação de correspondência se faz cruzando alguns campos do inventário com o artefato que está em produção. A versão do componente identifica a entrega de código, e o registro de data e hora informa a última alteração dos dados, no formato definido pelo RFC 9557. O valor de hash, com o algoritmo declarado em campo próprio, permite comparar o artefato recebido com o descrito. Campos distintos separam ainda quem gerou o arquivo de quem fez o software, já que o antigo nome do fornecedor deu lugar ao produtor do componente. 

A assinatura digital do autor do SBOM entrou como elemento novo e resolve uma pergunta estreita, porque garante que o signatário declarado assinou aquela informação e que ela não foi modificada depois. A seção de validação do documento é explícita sobre o resto, ao tratar precisão, cobertura e completude como propriedades de processo, fora do escopo dos elementos mínimos. Para essas, a orientação aponta ferramentas de análise de binário como caminho para detectar componentes ausentes da lista. 

Vale acompanhar um exemplo hipotético para ver como essa verificação muda a resposta ao fornecedor. Suponha uma entrega cujo SBOM indica geração a partir do código-fonte, com data anterior à construção do pacote instalado, e com valores de hash que não correspondem aos binários recebidos. O arquivo pode estar assinado e válido no formato, e ainda assim ser a documentação de um software que o comprador não está operando. 

Identificação dos componentes e o teste de importar, consultar e relacionar 

O elemento de identificadores passou a exigir ao menos um identificador comum de software, com o Common Platform Enumeration e o Package-URL como referências, e aceita também identificadores próprios da organização e hashes de commit. Havendo mais de um disponível, a orientação pede que o autor inclua todos, porque cada base de consulta reconhece um conjunto diferente. 

A proveniência aparece no campo de produtor do componente, e a regra escrita para software de código aberto é a que mais interessa ao comprador. Quando não existe indicação clara de quem produziu o componente, o autor do SBOM deve declarar que ele é de proveniência desconhecida, reconhecendo a falta de rastreabilidade. Uma lista com campos de produtor vazios, sem essa declaração, transfere ao comprador a tarefa de descobrir a origem de cada item, e é aí que a avaliação de um SBOM de fornecedores costuma travar. 

Os dois formatos em uso amplo são o SPDX e o CycloneDX, cuja especificação está registrada na Ecma International como ECMA-424, e a do Package-URL corresponde à ECMA-427. Nomes estáveis servem para citar em contrato, mas o critério que decide se a identificação serve é operacional. O teste é importar o inventário na ferramenta que a empresa já usa, consultar os componentes por identificador e relacionar cada item ao produto entregue e aos ativos internos. 

Atualização do SBOM por release e quem responde pelo recebimento 

O elemento de frequência determina que cada versão ou atualização do software tenha um inventário associado, incluindo as construções que apenas incorporam componentes atualizados. A mesma regra vale quando o produtor descobre detalhes novos sobre os componentes já listados ou corrige um erro nos dados existentes, situação na qual o inventário revisado precisa ser emitido sem esperar a próxima versão do produto. 

A tolerância a erro deixou de ser incondicional na atualização mais recente da orientação. O elemento que tratava da acomodação de equívocos deu lugar a um de acomodação de atualizações nos dados, que pede correção rápida por parte do autor. O mesmo elemento admite que as organizações considerem os erros, vindos das práticas do autor ou de ferramentas inadequadas, nas suas decisões de gestão de risco. Para o comprador, isso converte o histórico de erros de um fornecedor em insumo de avaliação. 

A distinção que organiza a rotina de recebimento separa inventário atualizado de inteligência de vulnerabilidade atualizada. O inventário muda quando o software muda, e é o fornecedor quem gera a versão nova, o que faz da entrega uma obrigação com gatilho claro. O quadro de risco muda sem que o software mude, porque vulnerabilidades novas são divulgadas sobre componentes que já estavam ali, e aí é o comprador quem reavalia o inventário que tem. São duas rotinas com responsáveis distintos, e a falta de alguém nomeado pelo recebimento faz o arquivo terminar anexado a uma troca de mensagens que ninguém mais abre. 

Do componente listado ao risco efetivo no ambiente do comprador 

A avaliação de risco a partir de um SBOM erra quando trata como equivalentes coisas que não são. A presença de um componente na lista é um fato sobre o inventário, e a associação dele a uma vulnerabilidade divulgada é um fato sobre a base de consulta. Nenhum dos dois diz se a vulnerabilidade se aplica ao produto, questão que depende de como o fornecedor montou aquele componente, nem se há possibilidade de exploração, que depende de o código vulnerável estar alcançável. O impacto depende da exposição do sistema, da configuração e da importância dele para a operação. 

Aceitar ou recusar um software pela quantidade de vulnerabilidades listadas, ou pela severidade máxima entre elas, produz decisão ruim nas duas direções. Um produto com muitas vulnerabilidades em componentes que não são alcançáveis pode ser menos perigoso que outro com uma única falha em biblioteca exposta na borda da rede. A contagem também penaliza o fornecedor que declara mais, o que cria incentivo para entregar inventário raso. 

A priorização por risco que essa separação exige é a mesma que estrutura um programa de gestão de vulnerabilidades, e a diferença está na origem do dado. Em vez de partir de uma varredura que a própria empresa executou, a análise parte de um inventário declarado pelo fornecedor, cuja qualidade o comprador não controla. Isso também separa o trabalho da verificação automatizada de dependências que roda na esteira de desenvolvimento, tema do conteúdo sobre DevSecOps, na qual o código é da própria equipe. 

VEX e o que uma declaração de componente não afetado precisa sustentar 

O instrumento que o fornecedor usa para dizer que uma vulnerabilidade listada não afeta o produto é o VEX, sigla de Vulnerability Exploitability eXchange, cuja função é comunicar a explorabilidade de componentes vulneráveis no contexto do produto em que estão usados. O documento de elementos mínimos trata o VEX como aviso de segurança que acompanha o inventário, com o papel de estreitar o escopo dos componentes em risco, e estreitar escopo é diferente de encerrar item. 

A especificação OpenVEX, referenciada pelo próprio documento de elementos mínimos, define o que faz uma declaração ser válida. São necessários os produtos e versões cobertos, o estado, a vulnerabilidade e o registro de data e hora, além da identificação do autor. Os estados previstos são não afetado, afetado, corrigido e em investigação, e cada declaração nova substitui a anterior quando traz informação atualizada, o que faz do VEX um fluxo e não um atestado. 

Uma declaração de não afetado precisa vir acompanhada de uma justificativa entre as cinco previstas ou de um texto livre explicando por que a vulnerabilidade não pode ser explorada. As justificativas cobrem o componente não estar incluído, o código vulnerável não estar presente, não estar no caminho de execução, não poder ser controlado por um adversário e mitigações internas ao produto já existirem. Sem uma delas, ou sem a explicação em texto, a declaração está incompleta pela própria especificação, e cabe devolvê-la em vez de suprimir o alerta. 

Duas dessas justificativas merecem tratamento diferente das outras, e a própria especificação avisa por quê, ao descrever como difíceis de provar de forma conclusiva tanto a alegação de que o código vulnerável não pode ser controlado por um adversário quanto a que invoca mitigações internas. A alegação sobre mitigações vem com a observação de que o histórico está repleto de contornos obtidos com modificações pequenas em código de exploração existente. Recebida uma das duas, cabe perguntar que evidência sustenta a alegação e em que condições ela deixaria de valer. 

Uma inconsistência frequente na prática mostra o tipo de pedido que essa leitura gera. Suponha um VEX que marca como não afetado um conjunto de versões que não inclui a versão implantada no ambiente do comprador, e que não traz justificativa nem texto explicativo. Não existe aqui resposta a aceitar ou recusar, porque a declaração não cobre o produto em questão e não atende ao requisito mínimo da especificação. Uma declaração em investigação com data antiga pertence à mesma categoria, por ser item aberto. 

Rotina de esclarecimento e cobrança de correções junto ao fornecedor 

A rotina começa pela definição de quem responde, dos dois lados, e por qual canal. A orientação já estabelece que o autor do SBOM mantenha um processo pelo qual o destinatário pergunte sobre informação de segurança suprimida, o que dá apoio para exigir interlocutor nomeado em vez de caixa de entrada genérica. Do lado de dentro, o recebimento precisa de um responsável que registre a entrada do arquivo, faça a verificação de correspondência e abra as pendências. 

Os prazos de correção não vêm de nenhuma regra geral e precisam ser negociados por faixa de risco no contrato, com a faixa definida pela combinação de explorabilidade, exposição do sistema e importância dele para a operação. O que sustenta essa negociação é o inventário confiável, porque sem ele a discussão sobre prazo ocorre sem acordo prévio sobre o que está em jogo. Vale registrar no mesmo instrumento as exceções, com a medida temporária aceita enquanto a correção não sai e o caminho de escalonamento. 

Receber o patch encerra a pendência do fornecedor, e não a do comprador, porque a comprovação da correção pede verificação no ambiente. Isso significa nova varredura sobre o sistema atualizado, conferência de que a versão do componente mudou no inventário revisado e registro da evidência para a auditoria que vier depois. Um patch disponibilizado e não implantado, ou implantado e não verificado, deixa a exposição de pé com a pendência fechada. 

Parte da cobrança encontra apoio na regulação a que o fornecedor já está sujeito. O documento de elementos mínimos registra que o Cyber Resilience Act da União Europeia, o Regulamento (UE) 2024/2847, obriga fabricantes de produtos com elementos digitais a fornecer um SBOM na documentação técnica. Uma empresa no Brasil que compra software de fabricante europeu pode, por isso, pedir um inventário que já existe por obrigação do lado do vendedor. 

Como a gestão de vulnerabilidades sustenta a avaliação de SBOM de fornecedores 

O trabalho que transforma um inventário recebido em decisão é o mesmo ciclo de identificar, priorizar, corrigir e monitorar que estrutura a gestão de vulnerabilidades da Faiston, aplicado a um dado de origem externa. A varredura automatizada e manual cobre servidores, estações, dispositivos de rede, nuvem e aplicações web, e permite confrontar o que o fornecedor declarou com o que está instalado. A avaliação avançada, com validação manual e simulação de exploração, responde ao que o inventário não responde, a de se a vulnerabilidade associada a um componente listado é explorável naquele produto. 

A priorização por criticidade, abrangência e impacto organiza a fila de cobrança, e os painéis, planos de ação e evidências para auditoria dão ao gestor o registro do que foi pedido, entregue e verificado. A integração com SIEM, ITSM e as esteiras de desenvolvimento mantém a pendência aberta a partir de um SBOM no mesmo fluxo das demais. 

A assimetria entre comprador e fornecedor de software começa a se desfazer no momento em que o comprador consegue processar o que recebe, e não no momento em que passa a exigir o arquivo em contrato. O critério que separa as duas situações é simples de enunciar e trabalhoso de sustentar, porque exige importar o inventário, amarrá-lo ao artefato implantado, relacioná-lo aos ativos internos e devolver ao fornecedor pendências com fundamento técnico. Enquanto essa capacidade não existe, exigir SBOM produz arquivo arquivado, e o fornecedor que entrega pouco não se distingue daquele que entrega bem. 

Para avaliar o software que já está no ambiente e estruturar a cobrança de correções junto aos fornecedores, fale com a Faiston.