Onde as ferramentas de segurança com IA ficam aquém, e o que as evidências determinísticas do build cobrem

O argumento, formulado de forma restrita

Isto não é um argumento contra a IA na segurança. Os modelos são bons a ler código, a explicar uma conclusão e a sugerir uma correção, e as equipas que os usam bem avançam mais depressa. O argumento é mais restrito: para registos que têm de resistir mais tarde, um modelo probabilístico é a fonte primária errada. Isso abrange a SBOM que entrega a um regulador, a proveniência do artefacto que lançou e a resposta a "fomos afetados?"

Três propriedades decidem se um registo resiste. Cada secção abaixo trata de uma, com exemplos e fontes.

1. Reprodutibilidade: pergunte duas vezes, obtenha a mesma resposta

Um registo de segurança só é útil se outra pessoa conseguir obter a mesma resposta a partir da mesma entrada. Os modelos de linguagem não o garantem, e os fornecedores dizem-no.

• A documentação da Anthropic: "Mesmo com a temperatura definida como 0, os resultados não serão totalmente determinísticos e entradas idênticas podem produzir resultados diferentes entre chamadas à API".
• O GitHub sobre o Copilot Autofix: "Mesmo com o mesmo alerta e o mesmo código, pode não conseguir produzir uma sugestão viável, ou a sugestão pode variar entre tentativas".
• Os investigadores que criaram a framework SecLLMHolmes testaram oito LLM em 228 cenários de código para o IEEE S&P 2024. Reportam que os modelos "dão respostas não determinísticas" e que, "apenas alterando nomes de funções ou variáveis, ou acrescentando funções de biblioteca ao código-fonte", o PaLM2 e o GPT-4 deram respostas incorretas em 26% e 17% dos casos.

Exemplo. Dois engenheiros perguntam ao mesmo assistente se um serviço está exposto a um novo aviso de segurança. Um recebe "não", o outro recebe "possivelmente, verifique a árvore transitiva". Nenhuma das respostas é um registo, e nenhuma pode ser reproduzida para um auditor seis meses depois.

Um build registado não tem este problema, porque nada está a ser inferido. O CRACI observa os pacotes que um job obtém das fontes de pacotes durante a execução, e a SBOM é um registo dessa observação.

2. Auditabilidade: mostre como sabe

As auditorias giram em torno da pergunta "como sabe?" Um modelo pode dar uma resposta fluente, mas a sua explicação não é uma evidência. A avaliação SecLLMHolmes concluiu que os LLM apresentam "raciocínio incorreto e infiel" sobre as vulnerabilidades que avaliam, pelo que um veredicto correto pode vir acompanhado de uma explicação que não se sustenta.

As normas estão a evoluir para registos que explicam a sua própria origem. Os elementos mínimos de SBOM de 2026, publicados pela CISA com a NSA, o FBI e parceiros internacionais, acrescentam um SBOM Tool Name, um SBOM Tool Version e um SBOM Generation Context que indica se a SBOM foi produzida "antes do build", durante o "build" ou "depois do build". O mesmo documento adverte que "as organizações podem ter em conta os erros, quer resultem das práticas do autor da SBOM quer da escolha de ferramentas inadequadas, nas decisões de gestão do risco organizacional".

Exemplo. Um questionário de um cliente pergunta como foi produzida a sua SBOM. "Um assistente leu o repositório e escreveu-a" dá um contexto de geração, mas não um que um revisor possa verificar. "Foi registada dentro do runner de CI durante o build de lançamento, e o estado de completude do job é Complete" é algo que o revisor pode verificar face ao build.

3. Completude: não pode reportar o que nunca viu

Um modelo raciocina sobre o que lhe é mostrado. Se os ficheiros que lê não descrevem o software, a resposta também não o fará, e nada no resultado o indica. As orientações de 2026 da CISA fixam a fasquia na decisão do destinatário: este "deve poder concluir que uma vulnerabilidade recém-reportada não o afeta se a SBOM não listar o componente". Isso só funciona se a ausência da lista significar ausência do build.

Exemplo. O repositório anthropics/claude-code na v2.1.259 não tem qualquer manifesto de dependências nem lockfile. O pacote npm publicado declara zero dependências de runtime e envolve um binário nativo pré-compilado. Qualquer ferramenta que leia o repositório, com IA ou não, quase nada tem para listar, enquanto o programa que é executado é um binário compilado.

Exemplo. As ferramentas de programação com IA também podem criar elas próprias a lacuna. O GitHub adverte que o Copilot Autofix "pode sugerir dependências fabricadas, publicadas sob nomes estatisticamente prováveis". Um estudo da USENIX Security 2025 sobre 576.000 amostras de código geradas por 16 modelos encontrou uma taxa 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.

Determinístico é necessário, não suficiente

Uma versão honesta deste argumento tem de incluir o ponto seguinte. Os geradores de SBOM são determinísticos e, mesmo assim, discordam entre si. Apontados ao mesmo commit de expressjs/express, podem devolver listas diferentes, porque cada um decide por si o que conta como componente e em que ficheiros confiar. O repositório não inclui lockfile, pelo que uma ferramenta que resolve as dependências a partir de um não tem nenhuma das dependências do package.json para reportar.

Um scanner determinístico reproduz sempre a mesma resposta incompleta. A repetibilidade é necessária, mas o que fecha a lacuna é a observação: registar o que o build efetivamente descarregou e indicar quando o registo está incompleto. O CRACI marca cada job e cada cache como Complete, Complete with connections, Incomplete, Unavailable ou Not recorded.

Um exemplo prático: delimitar um novo aviso de segurança

Um cenário hipotético: é publicado um aviso para uma versão de um pacote npm amplamente usado. Nos termos do Cyber Resilience Act, os fabricantes têm 24 horas para reportar à ENISA uma vulnerabilidade ativamente explorada, pelo que a delimitação tem de ser rápida e correta.

O caminho que começa pela IA

Pede a um assistente que verifique os seus repositórios. Ele lê manifestos e lockfiles, e talvez um Dockerfile. Não vê pacotes restaurados de uma cache de CI, ferramentas descarregadas por um passo do build nem versões resolvidas no momento da instalação num repositório sem lockfile. Se perguntar duas vezes, pode responder de forma diferente. O resumo é útil, mas não pode assinar o seu relatório com base nele.

O caminho que começa pelo registo

O CRACI agrega vulnerabilidades de todos os builds e repositórios, delimitadas ao branch predefinido ao nível da organização, e reavalia as SBOM monitorizadas à medida que surgem novas vulnerabilidades. A API devolve a SBOM CycloneDX de cada build, o seu traço de rede e a proveniência. Se o registo de um job estiver incompleto, o seu estado de completude indica onde procurar manualmente. Pode continuar a pedir a um modelo que resuma o resultado. Ele está a resumir um registo, não a gerá-lo.

Com o registo, a pergunta "que lançamentos distribuíram este pacote?" é uma consulta, não uma investigação.

Lado a lado

Coloque cada ferramenta onde é forte

Use a IA onde o discernimento ajuda e uma pessoa verifica o resultado: revisão de código, explicação de uma conclusão, redação de uma correção. Use registos de build determinísticos onde o resultado tem de ser reproduzido, auditado ou considerado completo: SBOM, proveniência e delimitação de incidentes. O CRACI automatiza uma parte significativa dessas evidências da cadeia de abastecimento para um processo de CRA mais amplo. Não torna, por si só, a sua empresa conforme.

Veja como o registo é feito em geração de SBOM durante o build, ou comece por o que o CRA exige.