Segurança com IA vs evidências determinísticas

Cada comparação indica o que o outro produto faz bem, em que o CRACI é diferente e quando faria sentido usar ambos. Para todas as categorias, consulte todas as comparações.

Duas camadas, dois trabalhos

A maioria das equipas de segurança já está a acrescentar IA: para rever código, fazer a triagem de conclusões e escrever correções. É uma boa utilização. A questão é saber em que se baseia a IA. Um programa de segurança precisa de duas camadas:

Uma camada de IA que lê, explica e age: revisão de código, triagem e pull requests de correção.
Uma camada de registo que diz o que realmente aconteceu: que dependências cada build obteve, registadas sempre da mesma forma e com indicação de onde o registo está incompleto.

A IA funciona melhor sobre o registo. O resto desta página e os guias abaixo mostram onde cada camada é forte.

Três testes para dados de segurança

Os dados de segurança que saem da equipa de engenharia, numa auditoria, num questionário de um cliente ou num relatório do CRA, têm de passar três testes.

Reprodutibilidade. Faça a mesma pergunta duas vezes e obtenha a mesma resposta. O resultado de um modelo pode variar entre execuções; um registo do build não varia.
Auditabilidade. Mostre como o sabe. Um registo aponta para o build de que veio; uma resposta deduzida não consegue mostrar o seu raciocínio da mesma forma.
Completude. Não pode reportar o que nunca viu. Nem uma ferramenta de IA nem um scanner conseguem listar uma dependência que nunca lhes passou pela frente.

Ser determinístico é necessário, mas não suficiente. Os geradores de SBOM são determinísticos e, ainda assim, discordam entre si, pelo que o que colmata a lacuna é a observação: registar o que o build obteve e dizer quando o registo está incompleto. O CRACI marca cada job e cache como Complete, Complete with connections, Incomplete, Unavailable ou Not recorded. IA vs segurança determinística, com um exemplo prático

Onde a IA se sai bem

Revisão de código: o trabalho de leitura que um revisor ocupado salta, sob a forma de comentários e sugestões nos pull requests.
Triagem: explicar um aviso de segurança em linguagem simples e ordenar o que ver primeiro.
Correções: escrever a alteração, adaptar o código a uma atualização incompatível e abrir o pull request. A utilidade dessas correções depende daquilo que a IA é instruída a corrigir. Remediação de vulnerabilidades com IA
Trabalhar com uma SBOM registada: resumir que componentes têm risco e redigir a documentação à sua volta para revisão humana.

Onde precisa de um registo

"Somos afetados?" Quando surge um novo aviso de segurança, a resposta tem de cobrir todos os builds que obtiveram o pacote, e não apenas aqueles que um modelo ou uma análise por acaso viram.
Dependências acrescentadas por IA. Os assistentes de programação com IA acrescentam dependências e, por vezes, indicam pacotes que não existem. Um registo do build mostra o que foi realmente descarregado.
Auditorias e perguntas de clientes. Um auditor ou um cliente quer evidências que possa verificar, não uma descrição.
SBOM ao abrigo do CRA. Uma SBOM gerada por IA é uma suposição sobre o seu build; o Cyber Resilience Act e os elementos mínimos da CISA de 2026 esperam um registo. Porque é que uma SBOM gerada por IA não é uma evidência

A regra é simples: deixe o build produzir o registo e deixe a IA lê-lo. Como as ferramentas de segurança com IA e o CRACI se complementam

O CRACI comparado com cada ferramenta

IA e segurança: respostas

Uma ferramenta de IA pode escrever a minha SBOM?

Pode escrever rapidamente algo que se parece com uma. Mas um modelo trabalha a partir do código e dos ficheiros que lhe são mostrados, não do que o build obteve, e a alucinação é um modo de falha documentado. Os reguladores e os clientes pedem um registo daquilo que o produto contém. Deixe o build produzir a SBOM e deixe o modelo lê-la.

As ferramentas de segurança com IA substituem a SCA ou as evidências do build?

Não. A revisão de código, a triagem e os pull requests de correção com IA são acréscimos úteis a um programa de segurança, mas funcionam melhor sobre dados completos e repetíveis. As duas camadas fazem trabalhos diferentes, e a maioria das equipas precisa de ambas.

Um scanner determinístico é suficiente?

Ser determinístico é necessário, mas não suficiente. Os geradores de SBOM são determinísticos e, ainda assim, discordam entre si, porque cada um decide por si o que conta como componente. Um scanner determinístico pode reproduzir sempre a mesma resposta incompleta. O que colmata a lacuna é registar o que o build realmente obteve e dizer quando o registo está incompleto.

Onde se situa o CRACI?

Na camada de registo. O CRACI substitui o runner de GitHub Actions, e um proxy que reconhece pacotes regista o que cada job obteve durante a execução. O resultado é uma SBOM do que o job obteve, um estado de completude para cada job e cache, e um traço de rede. A API devolve SBOM, traços de rede e proveniência. As ferramentas de IA podem trabalhar sobre esse registo.

IA e segurança