← Voltar à tabela de classificação

Como realizamos os testes

A qualidade dos testes de desempenho depende inteiramente da sua configuração. Eis como avaliamos se um modelo consegue detetar vulnerabilidades reais e qual o custo envolvido.

1. 1

   Escolha vulnerabilidades reais

   Recolhemos CVEs conhecidos da base de dados de alertas do GitHub, abrangendo várias linguagens e tipos de projetos.

2. 2

   Marcar o commit vulnerável

   Cada repositório é recuperado a partir de um commit realizado imediatamente antes de ter sido corrigido.

3. 3

   Executar no ambiente de produção

   Os modelos são executados no mesmo ambiente de IA que fornecemos com o «Code Security Audit» e o « Aikido Attack».

4. 4

   Aponte para o trecho vulnerável

   Como sabemos onde cada vulnerabilidade se encontra, os agentes de investigação concentram-se no código vulnerável. Um erro reflete o raciocínio — não um desperdício de orçamento por se ter explorado a parte errada do repositório. As instruções são sucintas e independentes do modelo.

5. 5

   Execute três vezes e, em seguida, agrupe os resultados

   Os modelos são não determinísticos. Executamos cada um deles três vezes e consideramos que um CVE foi detetado se este surgir em qualquer uma das execuções. A agregação permite detetar erros que uma única execução não conseguiria detetar e constitui um reflexo mais realista da forma como estes agentes seriam implementados.

6. 6

   Análise conjunta da cobertura e do custo

   Registamos quantas CVEs cada modelo volta a detetar e qual o custo envolvido nesse processo, porque o modelo mais potente raramente é o que apresenta a melhor relação custo-benefício. Comparamos também os níveis de raciocínio, sempre que o fornecedor os divulga.

---

Sobre a configuração do arnês

Um «harness» é o que transforma um modelo de linguagem num auditor. Um assistente de programação de uso geral é concebido para uma função diferente, que consiste em receber uma tarefa e produzir código funcional. Se o direcionarmos para um repositório e perguntarmos se este é seguro, ele comporta-se como um programador que procura rapidamente algo que esteja obviamente errado, parando assim que encontrar algo plausível. A Auditoria de Segurança de Código do Aikido foi concebida de forma diferente. Ela analisa a base de código à procura de pontos de entrada potenciais, investiga cada fluxo suspeito em profundidade e, em seguida, faz uma triagem dos resultados para que apenas obtenhamos vulnerabilidades reais.

Como sabíamos onde cada vulnerabilidade residia, direcionamos cada agente investigador diretamente para o trecho de código vulnerável. Dessa forma, uma falha reflete o raciocínio, e não o orçamento desperdiçado vagando pelo canto errado da base de código. O modelo ainda precisa entender o fluxo, julgar a explorabilidade e reportá-la corretamente. Os prompts foram mantidos curtos e agnósticos ao modelo para que nenhum fornecedor seja beneficiado pela formulação.

---