As ferramentas de segurança com IA leem o seu código. Algo continua a ter de registar o seu build.

A sua equipa provavelmente já está a acrescentar IA à segurança

A maioria das equipas de engenharia tem hoje pelo menos uma ferramenta de IA no ciclo de segurança. Um modelo revê pull requests. Outro sugere correções para alertas de análise estática. Um terceiro separa as conclusões dos scanners entre "veja isto" e "provavelmente ruído". Estas ferramentas poupam tempo real, e nada nesta página argumenta contra elas.

A pergunta útil é que tarefas devem assumir e que tarefas precisam de um registo que dê sempre o mesmo resultado. A pergunta complementar é o que as suas ferramentas de IA estão a ler quando tomam uma decisão sobre as suas dependências.

O que as ferramentas de segurança com IA fazem bem

• Revisão de código com IA. O GitHub Copilot code review deixa comentários em linguagem natural e sugestões de código nos pull requests, e pode seguir instruções específicas do repositório. É bom no trabalho de leitura que um revisor ocupado salta.
• Correções com IA. O GitHub Copilot Autofix "gera automaticamente sugestões de alteração de código para alertas do CodeQL encontrados em pull requests e no branch predefinido". O programador recebe uma proposta de patch junto ao alerta em vez de uma ligação para uma página de CWE.
• Triagem com IA. As funcionalidades de IA do Semgrep fazem a triagem automática das conclusões do Semgrep Code e sugerem correções. O Semgrep documenta a sua filtragem de ruído como tendo "mais de 95% de exatidão na classificação de conclusões do Semgrep Code como falsos positivos".

Repare no padrão dos dois últimos. O Copilot Autofix trabalha sobre alertas do CodeQL. A triagem do Semgrep trabalha sobre conclusões do motor baseado em regras do Semgrep. A IA acrescenta discernimento sobre um resultado determinístico. Não produz ela própria as conclusões subjacentes.

O que os fornecedores dizem sobre os limites

As afirmações mais claras sobre onde param as ferramentas de IA vêm dos próprios fornecedores, o que é de louvar.

• Sobre a revisão de código, o GitHub escreve que "o Copilot pode não identificar todos os problemas presentes no código" e que "tem risco de alucinação", assinalando problemas que não existem.
• Sobre o Autofix, o GitHub escreve que "utiliza um modelo generativo que é não determinístico. 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".
• Também sobre o Autofix: "O sistema não sabe que versões de dependências são suportadas ou seguras, e pode sugerir dependências fabricadas, publicadas sob nomes estatisticamente prováveis".

Nada disto torna as ferramentas menos úteis. Define a sua função: produzem sugestões para uma pessoa verificar. É uma função diferente de produzir o registo com que essa pessoa as verifica.

Duas camadas, duas funções

O CRACI situa-se na camada de registo. Substitui o runner do GitHub Actions (altera runs-on para craci) e um proxy que reconhece pacotes observa o tráfego do build para as fontes de pacotes durante a execução do job. O resultado é uma SBOM do que o job efetivamente descarregou, 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.

Onde é necessária visibilidade determinística

"Somos afetados?"

Quando surge um novo aviso de segurança, a primeira pergunta é se algum dos seus builds incluiu a versão afetada. Os elementos mínimos de SBOM de 2026 da CISA formulam o requisito com clareza: o destinatário de uma SBOM "deve poder concluir que uma vulnerabilidade recém-reportada não o afeta se a SBOM não listar o componente". Essa conclusão só é válida se a lista estiver completa. Um modelo pode ajudar a ler a resposta. Não deve ser ele a decidir o que estava no build.

O CRACI agrega vulnerabilidades de todos os builds e repositórios e reavalia as SBOM monitorizadas à medida que são publicadas novas vulnerabilidades, pelo que a pergunta é respondida a partir do que foi registado.

Dependências que uma IA acrescentou

Os assistentes de programação com IA acrescentam dependências, e a investigação mostra que por vezes indicam pacotes que não existem. Um estudo apresentado na USENIX Security 2025 gerou 576.000 amostras de código com 16 modelos e concluiu que a percentagem média de pacotes alucinados era de pelo menos 5,2% nos modelos comerciais e de 21,7% nos modelos open source. Um nome que não existe hoje pode ser registado amanhã. Quem ou o que quer que tenha acrescentado uma dependência, o CRACI regista o pacote que o build efetivamente descarregou, e as políticas de egress de rede podem limitar um job às fontes de pacotes que a sua empresa aprova.

Auditorias e perguntas de clientes

Um auditor ou a equipa de segurança de um cliente perguntará como sabe o que foi lançado. "Foi o que o modelo disse" é uma resposta fraca. "Aqui está a SBOM registada durante o build de lançamento, o seu estado de completude e o traço de rede desse job" é uma resposta forte. As SBOM são exportadas em CycloneDX ou SPDX, incluindo vulnerabilidades, e a API devolve SBOM, traços de rede e proveniência.

Respostas repetíveis

Algumas perguntas precisam da mesma resposta, independentemente de quem pergunta ou de quando. Que pacotes descarregou o lançamento da última terça-feira? Um modelo generativo pode formular bem essa resposta, mas, segundo os próprios fornecedores, pode formulá-la de forma diferente de cada vez. Um build registado dá uma única resposta.

Como as duas se complementam

O padrão que funciona é o que o Copilot Autofix e o Semgrep já usam: dados determinísticos por baixo, discernimento da IA por cima.

1. Deixe a revisão de código e as correções com IA trabalhar nos pull requests, com uma pessoa a aprovar cada alteração.
2. Deixe o CRACI registar o que cada build descarregou e indicar se esse registo está completo.
3. Quando quiser ajuda da IA com o risco das dependências, dê ao modelo a SBOM registada. A REST API pública do CRACI devolve a SBOM em CycloneDX, o traço de rede do job e a proveniência do artefacto.
4. Guarde como evidência a SBOM registada, não o resumo que o modelo fez dela.

Se a sua equipa escreve grande parte do código com assistentes de IA, a nossa página sobre segurança no desenvolvimento com IA aborda essa situação, e geração de SBOM durante o build explica como o registo é feito.