Uma SBOM gerada por IA é uma suposição sobre o seu build. Os reguladores pedem um registo.

Porque é que as equipas experimentam

O atrativo é real. Cola um repositório ou um lockfile num assistente de programação, pede CycloneDX e, em segundos, recebe um documento bem formado. Pode até preencher campos que os scanners costumam deixar vazios. O campo do fornecedor é o exemplo habitual: a maioria dos geradores não tem fonte para ele, pelo que sai em branco. Um modelo a quem se pede um documento completo consegue escrever algo em todos os campos.

Este último ponto é o problema em miniatura. Um scanner que não conhece o fornecedor deixa o campo em branco. Um modelo que não o conhece pode ainda assim produzir uma resposta plausível. O documento parece mais completo e é menos fiável.

O que o modelo realmente vê

Um modelo que gera uma SBOM trabalha a partir do texto que tem à frente: manifestos, lockfiles, talvez um Dockerfile. Não observa o build. Por isso, não consegue ver:

• que versões o gestor de pacotes resolveu quando um repositório não inclui um lockfile,
• pacotes restaurados de uma cache de CI,
• ferramentas, pacotes do sistema operativo e binários que um passo de build descarrega diretamente,
• o que entrou num binário compilado distribuído ao lado de um manifesto quase vazio.

Dois repositórios mostram como os ficheiros podem ser escassos. O expressjs/express 5.2.1 não inclui lockfile, pelo que o package.json lista as dependências como intervalos de versões e as versões reais são decididas durante a instalação. O repositório anthropics/claude-code na v2.1.259 não tem qualquer manifesto de dependências nem lockfile, e o pacote npm publicado declara zero dependências de runtime, embora envolva um binário nativo pré-compilado. Um scanner determinístico apontado a esse repositório não tem nada para ler que descreva o binário. Um modelo com os mesmos ficheiros tem a mesma falta de informação, e mais liberdade para preencher a lacuna.

A alucinação é um modo de falha documentado

Os modelos de linguagem indicam pacotes que não existem. O caso mais bem medido é a geração de código e não a escrita de SBOM, mas a falha que revela aplica-se igualmente a uma lista de componentes. Um estudo da USENIX Security 2025 gerou 576.000 amostras de código com 16 modelos e encontrou uma percentagem média de pacotes alucinados de pelo menos 5,2% nos modelos comerciais e de 21,7% nos modelos open source, com 205.474 nomes únicos de pacotes alucinados. A própria documentação do GitHub para o Copilot Autofix avisa que este "may suggest fabricated dependencies published under statistically probable names."

Os modelos também não dão duas vezes a mesma resposta. A documentação da Anthropic afirma que "even with temperature set to 0, the results will not be fully deterministic and identical inputs may produce different outputs across API calls." Duas SBOM geradas a partir do mesmo commit podem diferir, e nenhuma diz qual está certa.

Numa SBOM, uma entrada alucinada não é uma gralha inofensiva. Um pacote que não existe, ou a versão errada de um que existe, envia a pesquisa de vulnerabilidades para o sítio errado, e o resultado regressa confiante e errado.

O que as normas esperam que uma SBOM contenha

Elementos mínimos da NTIA (2021)

A base de referência da NTIA definiu sete campos de dados: nome do fornecedor, nome do componente, versão do componente, outros identificadores únicos, relação de dependência, autor dos dados da SBOM e carimbo temporal. Associou-os a suporte de automatização e a um conjunto de práticas e processos. Cada campo descreve um facto sobre o software, não uma opinião sobre ele.

Elementos mínimos da CISA de 2026

A 29 de julho de 2026, a CISA, a NSA, o FBI e parceiros internacionais publicaram elementos mínimos atualizados que substituem a base de referência de 2021. Vários acréscimos são difíceis de cumprir sem observar o build:

• SBOM Generation Context: "the relative software lifecycle phase and data available at the time the SBOM author generated the SBOM," com "before build," "build," e "after build" como exemplos. Um modelo que lê um repositório está, na melhor das hipóteses, em "before build".
• Component Hash Value: "the output generated from applying a cryptographic hash algorithm to an executable component artifact." Se o autor não tiver o artefacto, "the SBOM author should indicate the value is unknown." Um modelo que nunca tocou no artefacto não consegue produzir um hash, apenas texto com o aspeto de um.
• SBOM Tool Name and Version: a ferramenta usada para gerar a SBOM tem de ser identificada.
• Coverage: "An SBOM should include information for all components that make up the target software, including transitive dependencies. There is no minimum depth."
• Explicitly identifying unknown information: o autor "should explicitly state whether the information is unknown." Um valor inventado é o oposto disso.

O Cyber Resilience Act da UE

O CRA torna a SBOM uma obrigação legal para os fabricantes de produtos com elementos digitais. O Anexo I, parte II, exige-lhes que identifiquem e documentem as vulnerabilidades e os componentes contidos nos produtos com elementos digitais, nomeadamente através de uma lista de materiais de software num formato de uso comum e legível por máquina, que abranja, no mínimo, as dependências de nível superior dos produtos. O Anexo VII coloca a SBOM na documentação técnica, e uma autoridade de fiscalização do mercado pode solicitá-la para verificar a conformidade com os requisitos essenciais.

Nenhum destes textos proíbe as ferramentas de IA. O que pedem são dados que descrevam o produto real e declarações honestas sobre o que é desconhecido. Uma SBOM escrita por inferência tem dificuldade com ambos.

Como o CRACI produz a SBOM

O CRACI executa os seus jobs de GitHub Actions nos runners do CRACI. Muda runs-on para craci, e as execuções continuam a aparecer no GitHub. Durante a execução do job, um proxy que reconhece pacotes observa o tráfego para as origens de pacotes, pelo que a SBOM regista o que o build realmente obteve, incluindo as dependências transitivas. As evidências das dependências acompanham as caches de CI, pelo que um pacote restaurado de uma cache se mantém no registo.

• Ecossistemas: origens npm, PyPI, RubyGems, Cargo, Go, Nix, OCI, apt, apk e Git, além de predefinições de descarga.
• Completude: cada job e cache é marcado como Complete, Complete with connections, Incomplete, Unavailable ou Not recorded, pelo que os dados desconhecidos são indicados em vez de preenchidos.
• Formatos: CycloneDX e SPDX, com os metadados de licenças declaradas incluídos na exportação.
• Proveniência: a API devolve SBOM, traços de rede e proveniência.

O CRACI automatiza uma parte significativa da visibilidade da cadeia de abastecimento e das evidências de que um processo mais amplo de conformidade com o CRA necessita. Não torna, por si só, um produto conforme. Geração de SBOM durante o build trata dos pormenores, e a nossa visão geral do CRA trata do calendário.

Onde a IA ajuda realmente com as SBOM

Depois de ter uma SBOM registada, um modelo é bom a trabalhar com ela: resumir que componentes têm risco, explicar um aviso de segurança em linguagem simples ou redigir a documentação à sua volta para revisão humana. A regra é simples. Deixe o build produzir o registo e deixe o modelo lê-lo.