A partir de dezembro de 2027, todo produto com elementos digitais colocado no mercado da União Europeia terá de carregar uma lista formal dos componentes de software que o compõem: o SBOM. Fabricantes, importadores e desenvolvedores que entregam software na Europa têm pouco mais de um ano para transformar esse inventário em rotina de engenharia. Para quem consome software de terceiros, a mudança é oportunidade: a mesma exigência dá visibilidade sobre dependências que nenhum checklist de fornecedor revela. A ação prioritária é mover a geração do SBOM para dentro do pipeline de build, antes que o prazo regulatório passe a ditar o cronograma da equipe. O Cyber Resilience Act, regulação que sustenta a mudança, torna-se plenamente aplicável em dezembro de 2027 e converte a antiga boa prática em obrigação legal.
O que muda com o CRA
O Cyber Resilience Act — Regulamento (UE) 2024/2847, aprovado em 23 de outubro de 2024 — estabelece requisitos horizontais de cibersegurança para produtos com elementos digitais comercializados na União Europeia. Pela primeira vez, uma norma europeia exige que fabricantes criem e mantenham um SBOM para cada produto colocado no mercado. O documento precisa usar um formato de leitura automática de uso comum, cobrir ao menos as dependências de nível superior, ser mantido atualizado ao longo do ciclo de vida e integrar a documentação técnica entregue às autoridades de fiscalização quando solicitado. A publicação ao público em geral não é obrigatória.
A exigência não nasceu no vácuo. O SBOM é definido como o registro formal dos componentes de um software e das relações de cadeia de suprimentos entre eles: bibliotecas, dependências e requisitos de licença. Sob a nova regra, ele deixa de ser prática recomendada de segurança da cadeia de suprimentos e passa a ser mecanismo de conformidade, rastreabilidade e gestão de vulnerabilidades. É essa virada que muda o cálculo de investimento das equipes de engenharia e de segurança — inclusive no Brasil, de onde muitos fabricantes exportam software para o mercado europeu.
Para medir onde o mercado está, a ENISA aplicou no fim de 2025 um inquérito sobre adoção de SBOM. A pesquisa recebeu 334 respostas de organizações de vários setores e portes; cerca de 65% operam principalmente dentro da União Europeia e mais de 80% são empresas diretamente afetadas pela norma. O recorte importa para quem planeja capacidade: o grupo que respondeu é o mesmo que já negocia contratos e prazos de conformidade com clientes europeus.
O retrato da adoção em 2026
78% das organizações ouvidas pela ENISA já iniciaram a jornada de adoção de SBOM, e 44% se encontram em fase de piloto ou adoção limitada. A maturidade, porém, ainda é rara: apenas 9% relataram implementação madura com automação completa, e 25% declararam adoção ampla nos próprios produtos. Com base nas estimativas dos próprios respondentes, 79% devem alcançar o nível de maturidade necessário a tempo da aplicação plena. Ou seja, a maioria está entre o piloto e o meio do caminho — exatamente a fase em que projetos de transparência de software morrem por falta de dono interno.
No formato, o mercado converge para o que a norma pede: 44% usam CycloneDX e 29% usam SPDX, os dois padrões de leitura automática mais difundidos. Ainda assim, 11% não usam formato padronizado e 17% seguem com formato proprietário — dívida técnica que precisa entrar na correção antes do prazo final. O relatório também registra que os SBOMs passam a ser gerados e consumidos na etapa de build, sinal de integração com o ciclo de desenvolvimento, e não como documentação produzida depois do release.
O uso principal confirma a leitura defensiva: 29% das organizações apontam identificação e correção de vulnerabilidades como aplicação dominante, seguidas pela verificação de licenças de código aberto (22%), atendimento a exigências regulatórias (19%), avaliação de risco de software de terceiros (14%) e manutenção de inventário atualizado (13%). Quando perguntadas sobre o valor obtido, 37% citam redução de risco e custo evitado, 29% citam eficiência operacional e 26% citam requisitos contratuais e vantagem em licitações. O documento vale dinheiro porque reduz tempo de resposta — não porque preenche pasta de auditoria.
Onde as empresas travam
As barreiras identificadas pelo inquérito são operacionais, não conceituais, e é nelas que o plano até 2027 deve concentrar esforço:
| Barreira apontada | Percentual |
|---|---|
| Completude do SBOM (profundidade de dependências) | 62% |
| Qualidade dos dados do SBOM | 37% |
| Correspondência entre SBOM e vulnerabilidades (muita dificuldade) | 35% |
| Falta de habilidades internas ou equipe dedicada | 28% |
Completude é o gargalo dominante: gerar um SBOM apenas com componentes de nível superior cumpre a letra mínima da norma, mas deixa de fora as dependências transitivas — justamente o caminho pelo qual ataques de cadeia de suprimentos alcançam vítimas. O relatório é explícito ao dizer que visibilidade mais profunda é essencial para gestão de vulnerabilidades e de risco. A segunda lição é organizacional: falta consenso da indústria sobre boas práticas de integração entre produção e consumo de SBOM, e a demanda número um dos respondentes é uma implementação de referência, com pipelines publicados em repositório aberto, seguida de guias de seleção de ferramentas e testes de conformidade.
Decisões práticas para a defesa
Para uma equipe defensiva, o SBOM só tem valor se responder rápido a duas perguntas: em quais sistemas este componente está instalado e qual versão roda neles. Isso transforma o documento em insumo de resposta a incidentes, e não em anexo de auditoria. A lógica é a mesma de segredos no CI/CD, em que o controle precisa existir antes do deploy, e de evidência e recuperação, em que o inventário íntegro decide a velocidade da investigação depois que o incidente acontece.
Ações P1, para os próximos 90 dias:
- Gerar SBOM em CycloneDX ou SPDX automaticamente a cada build, versionado junto ao artefato de release.
- Medir a profundidade real: mapear dependências transitivas das bibliotecas críticas, não apenas o nível superior.
- Conectar o SBOM ao processo de gestão de vulnerabilidades, correlacionando com feeds de CVE e registrando o tempo entre divulgação e resposta.
- Nomear um dono interno do programa — falta de equipe dedicada aparece como barreira para 28% dos respondentes.
Ações P2, para o horizonte de 12 meses:
- Exigir SBOM de fornecedores em contrato, com formato de leitura automática e obrigação de atualização durante o suporte.
- Definir internamente o perfil de um SBOM bom o suficiente, em vez de perseguir completude perfeita no primeiro dia.
- Automatizar a correspondência entre componente e vulnerabilidade, hoje difícil para boa parte do mercado.
- Treinar engenharia e segurança no mesmo fluxo, evitando que o documento vire artefato de compliance isolado.
Sinais de que o programa está saudável: cobertura de SBOM por release próxima de 100%, tempo de correspondência de vulnerabilidades medido em horas, dependências transitivas mapeadas nos sistemas expostos à internet e documento consultável durante um incidente sem depender de e-mail para o fornecedor. Se esses indicadores não existem, o programa ainda é papel — e o prazo de 2027 vai cobrar a conta.