<p>Os mandatos de Software Bill of Materials estão redefinindo a forma como os fornecedores são selecionados.</p>

O ataque à Ernst & Young esta semana, reivindicado pelo grupo de extorsão ShinyHunters, seguiu um padrão que virou o modo de falha padrão de 2026: os atacantes não furaram as defesas da própria EY — eles comprometeram credenciais por meio de um fornecedor da cadeia de suprimentos e entraram pela porta da frente. Esse padrão é exatamente o que as exigências de software bill of materials (SBOM) foram criadas para capturar antes que aconteça — e a maioria das empresas ainda não consegue agir com base nos SBOMs que já são obrigadas a coletar.

Um SBOM é um inventário estruturado de cada componente dentro de um software: toda biblioteca, toda dependência, toda versão, até o menor módulo, incluindo firmware. A ideia é direta — se você sabe exatamente o que tem dentro do produto de um fornecedor, pode verificar contra vulnerabilidades conhecidas no momento em que um novo CVE aparece, em vez de descobrir durante uma ligação de resposta a incidentes.

A Onda Regulatória que Chega em 2026

O Cyber Resilience Act (CRA) da União Europeia, em vigor desde dezembro de 2024, entra na fase de enforcement este ano. Os requisitos de notificação de vulnerabilidades e incidentes entram em vigor em setembro de 2026, com a exigência completa de produção de SBOM em dezembro de 2027 — dando prazo aos fornecedores, mas não indefinido. O CRA exige um inventário completo de componentes de qualquer fornecedor que venda produtos digitais no mercado da UE, o que na prática significa a maioria dos fornecedores globais de software.

O setor financeiro enfrenta um requisito paralelo. Pela Digital Operational Resilience Act (DORA) da UE, os Artigos 28 a 30 exigem que entidades financeiras reguladas entendam e gerenciem toda a cadeia de provedores por trás de qualquer função crítica — não apenas o fornecedor direto, mas os fornecedores desse fornecedor. Um banco não pode mais tratar seu provedor de nuvem como uma caixa-preta; precisa conseguir responder o que está realmente rodando por baixo.

Nos EUA, a Ordem Executiva 14028 já exige SBOMs no padrão NIST para compras federais de software, traduzida pela CISA em requisitos contratuais concretos. Essa única alavanca de política fez mais para normalizar a produção de SBOM entre fornecedores comerciais do que qualquer padrão voluntário — empresas que querem contratos federais precisam produzir um, independentemente de seus outros clientes pedirem ou não.

Por que Ter um SBOM Não é o Mesmo que Usá-lo

O modo de falha que aparece nas implantações de 2026 é consistente: as organizações tratam a coleta de SBOM como uma caixa de compliance, não como um insumo operacional. Elas solicitam SBOMs dos fornecedores, arquivam e param por aí. Poucas constroem o pipeline que realmente converte uma lista estática de componentes em uma decisão ao vivo — sinalizar automaticamente quando um novo CVE atinge uma biblioteca que três fornecedores implantaram e disparar esse alerta para quem gerencia o relacionamento com o fornecedor.

Essa lacuna é exatamente onde mora o padrão de ataque no estilo EY. Um comprometimento na cadeia de suprimentos não se anuncia como uma vulnerabilidade na sua própria stack; ele aparece como credenciais comprometidas em um fornecedor cuja composição interna de software você talvez nunca tenha inventariado de verdade, muito menos monitorado contra novas divulgações.

O Que um Pipeline de SBOM Operacional Realmente Exige

• Ingestão legível por máquina, não PDFs. SBOMs precisam chegar em formatos padrão (SPDX ou CycloneDX) que possam ser analisados automaticamente, não como um documento que o time de compliance arquiva.
• Correspondência contínua com CVEs. O inventário só é útil se for verificado contra novas divulgações de vulnerabilidades de forma contínua, não apenas uma vez no onboarding do fornecedor.
• Mapeamento de ownership. Cada componente sinalizado precisa de um dono interno nomeado, responsável por acompanhar com o fornecedor — sem isso, os alertas se acumulam sem ação.
• Profundidade além do nível um. Requisitos no estilo DORA existem justamente porque a avaliação de risco de fornecedores de primeiro nível ignora o comprometimento que acontece dois ou três níveis abaixo na cadeia, que é onde os breaches de alto perfil recentes realmente se originaram.

Conclusões Acionáveis

Se sua organização está coletando SBOMs puramente para satisfazer uma cláusula contratual ou um auditor, você está arcando com o custo de compliance sem o benefício de segurança — e o cronograma de enforcement da UE (setembro de 2026 para notificação de incidentes, dezembro de 2027 para produção completa de SBOM) significa que a exigência só vai apertar daqui para frente. Comece escolhendo uma categoria de fornecedor de alto risco — daquelas com acesso profundo a sistemas internos, como as plataformas de gerenciamento de serviços de TI envolvidas no ataque à EY desta semana — e construa o pipeline de ingestão até alerta para essa categoria primeiro, em vez de tentar operacionalizar todos os relacionamentos com fornecedores de uma vez. Um pipeline parcial que realmente gatilha alertas vale mais do que um arquivo completo de SBOM que ninguém consulta.