IA na segurança: velocidade sem precisão não resolve o problema
Times de segurança já estão usando IA de forma ativa no dia a dia — triagem de vulnerabilidades, testes de penetração, modelagem de ameaças, resposta a incidentes e revisão de código. A promessa central é velocidade. O problema é que uma ferramenta que trabalha rápido, mas dispara alertas em excesso, não economiza tempo de ninguém. Engenheiros perdem horas investigando falsos positivos, o plantão fica mais ruidoso, e a equipe começa a desconfiar dos alertas que realmente importam.
Foi exatamente para atacar esse problema que a AWS lançou o Deception Benchmark: o primeiro benchmark criado especificamente para medir a capacidade de um modelo de IA em distinguir vulnerabilidades reais de código que parece arriscado, mas é, na prática, seguro. O dataset e o whitepaper foram disponibilizados publicamente para a comunidade.
O que os benchmarks existentes não mediam
A comunidade de segurança já avançou bastante em avaliações de IA. O CyberGym testa agentes em mais de 1.500 tarefas realistas. O CyberSecEval da Meta e o CyberSecEval 2 medem geração de exploits. O CYBENCH avalia desafios do tipo Capture the Flag (CTF). O SEC-Bench e o VulnBench buscam aproximar os testes de fluxos reais de segurança.
Trabalhos mais recentes reforçam tanto o progresso quanto a lacuna existente. O ExploitGym mede se a IA consegue escalar de uma falha até um exploit funcional. O Project Perception, da Microsoft, implanta equipes multi-agente de red/blue/green team para defesa contínua. O GPT-Red, da OpenAI, demonstra que red-teaming com auto-aprendizado descobre ataques novos que os modelos de fronteira ainda não conseguem defender.
Além disso, a OpenAI revelou que seu modelo GPT-6 Astra cruzou o limiar crítico de capacidade em cibersegurança. Tanto a OpenAI quanto a Anthropic reportaram incidentes em que modelos obtiveram acesso não autorizado a sistemas em produção durante avaliações.
O lado ofensivo está evoluindo rapidamente. Mas nenhum desses trabalhos respondia à pergunta defensiva essencial: quando um sistema de IA sinaliza um trecho de código como vulnerável, com que frequência ele está certo?
Apresentando o Deception Benchmark
O benchmark recebeu o nome “Deception” (engano, em português) porque as amostras seguras são deliberadamente construídas para enganar os modelos. Elas contêm padrões reais de vulnerabilidade, frameworks reais e idiomas reais de código — mas com mitigações que fecham silenciosamente o caminho de exploração.
O conjunto total conta com 14.822 amostras, distribuídas em 16 linguagens de programação e mais de 70 categorias de Enumeração de Fraquezas Comuns (CWE). A tarefa do modelo é simples de enunciar, mas difícil de executar: classificar o código como vulnerável ou seguro, sem nenhuma dica adicional.
Um exemplo clássico: considere um endpoint Flask que aceita entrada do usuário e consulta um banco de dados. Um modelo vai reconhecer o padrão de injeção de SQL — mas a query usa declarações parametrizadas, então o caminho de exploração está fechado. Um classificador de turno único identifica o padrão e para por aí, sem verificar se o exploit pode de fato funcionar. Ferramentas de produção costumam usar loops de múltiplos passos e fluxos agênticos para compensar essa limitação, mas essa estrutura esconde se o modelo realmente entende o código. O Deception Benchmark remove esse suporte e exige que o modelo tome a decisão em uma única passagem — medindo compreensão, não quantas tentativas um sistema externo precisa para acertar.
Dois tipos de desafios
O benchmark gera dois tipos de desafio:
- Desafios em nível de código (6.988 amostras): apresentam variantes vulneráveis e seguras que diferem por uma correção sutil. Ambas parecem suspeitas; apenas uma é explorável.
- Desafios condicionados ao ambiente (2.707 amostras): vão além — o mesmo código, em contextos de implantação diferentes. Uma Política de Rede do Kubernetes bloqueia o caminho de Falsificação de Requisição do Lado do Servidor (SSRF). Um limite de Gerenciamento de Identidade e Acesso (IAM) impede escalonamento de privilégios. O padrão é visível no código-fonte; a infraestrutura é que torna o exploit inviável. O modelo precisa identificar qual cenário se aplica.
Todas as amostras foram criadas exclusivamente para este benchmark, baseadas em padrões do mundo real, sem preocupações com propriedade intelectual ou contaminação dos dados de treinamento. A geração e o processo de endurecimento das amostras consumiram dezenas de bilhões de tokens. O resultado foi disponibilizado para que a comunidade não precise repetir esse custo.
Como a qualidade das amostras foi garantida
Gerar rótulos confiáveis nessa escala é um desafio por si só: uma única passagem — seja por humanos ou por modelos — deixa erros que distorcem os resultados. Por isso, o processo trata a rotulagem como um ciclo de auditoria convergente, não como uma etapa única.
Cada rótulo é revisado por múltiplos avaliadores independentes, sem acesso ao raciocínio original. Divergências escalam para adjudicação direta. Casos não resolvidos vão para revisão humana. O ciclo se repete até que o conjunto avaliado convirja abaixo de um limite de disputa: menos de 3% das amostras ainda contestadas por revisão independente, com meta de menos de 1% sobrevivendo à adjudicação humana.
Uma decisão torna o processo defensável: amostras disputadas nunca são reclassificadas. Quando revisores discordam, a amostra vai para o conjunto não pontuado em vez de receber um rótulo corrigido. Assim, um desafio ruim pode remover uma amostra, mas nunca pode introduzir um rótulo errado no conjunto pontuado. Uma revisão humana de 100 amostras aleatórias do conjunto pontuado não encontrou nenhum erro de rótulo. O processo completo está descrito no whitepaper.
Os resultados: nenhum modelo passou no teste
O benchmark é aproximadamente balanceado — metade vulnerável, metade segura — então um classificador aleatório acerta 50% das vezes. A AWS reporta duas taxas de erro separadamente, porque elas falham em direções opostas:
- Taxa de Falsos Positivos (FPR): com que frequência o modelo sinaliza código seguro como vulnerável. São os alarmes falsos que desperdiçam o tempo do engenheiro.
- Taxa de Falsos Negativos (FNR): com que frequência o modelo deixa passar uma vulnerabilidade real, classificando-a como segura.
A acurácia isolada esconde esse problema: um modelo que classifica tudo como vulnerável captura 100% dos bugs reais (FNR de 0%), mas sinaliza todo código seguro (FPR de 100%) e ainda assim marca cerca de 50% de acurácia. O critério mínimo adotado para uso em produção foi FPR abaixo de 10% e FNR abaixo de 10% simultaneamente.
Os 12 modelos avaliados — de cinco provedores, incluindo versões dos modelos GPT, Claude, Llama, Amazon Nova e Mistral Large — foram testados com duas estratégias de prompt: prompting direto e prompting com prova de exploit (PoE). Os resultados foram consistentemente frustrantes:
- Com prompting direto, os modelos capturam até 95% das vulnerabilidades reais, mas também sinalizam entre 41% e 99% do código seguro. A precisão ficou entre 52% e 71%, concentrada na faixa dos 50% — tão provável de errar quanto de acertar.
- O prompting com prova de exploit reduziu os falsos positivos em 17 a 74 pontos percentuais, mas passou a deixar escapar entre 7% e 44% das vulnerabilidades reais.
- Os desafios condicionados ao ambiente foram ainda piores: os modelos sinalizavam o código e ignoravam a Política de Rede do Kubernetes ao lado.
Nenhuma configuração testada manteve simultaneamente falsos positivos e falsos negativos abaixo de 10%.
O padrão de falha é o mesmo em todos os modelos: eles reconhecem um padrão de vulnerabilidade e param de raciocinar. Não verificam se a mitigação presente no código realmente fecha o caminho de exploração.
O que isso significa para sistemas agênticos
Esses resultados refletem modelos de uso geral em prompting de turno único. Sistemas construídos especificamente para segurança, com validação em múltiplos passos e uso de ferramentas, operam em um patamar diferente — e o Deception Benchmark é o lugar certo para demonstrar se conseguem fechar essa lacuna.
Mas há dois pontos de atenção importantes antes de assumir que sistemas agênticos já resolvem o problema. Primeiro, a verificação agêntica foi comprovada principalmente em tarefas ofensivas, onde o sucesso é confirmável: o exploit funciona ou não. Julgar que um código é seguro não tem esse oráculo. Iterações extras reamostram o mesmo julgamento em vez de confirmar um negativo. Segundo, um sistema de orquestração ainda herda a compreensão do modelo base. Se o modelo não consegue separar uma mitigação eficaz de uma ineficaz em uma única passagem, mais passagens não vão adicionar o conhecimento que falta.
O que times de segurança devem fazer agora
Para equipes de segurança que avaliam ferramentas de IA hoje, a recomendação é direta: pergunte aos seus fornecedores como o sistema deles se comporta em tarefas como essas — não apenas se ele encontra vulnerabilidades, mas com que frequência ele erra. Combine qualquer revisão assistida por IA com verificação humana nos caminhos de código de alto risco, e use o Deception Benchmark para cobrar accountability das suas ferramentas.
Disponibilidade
O Deception Benchmark está disponível no GitHub, junto com o whitepaper e as instruções de submissão para pontuação verificada. Das 14.822 amostras totais, 9.695 são pontuadas; as 5.127 restantes ficam retidas e misturadas ao conjunto, dificultando a otimização do benchmark em vez de melhorar o sistema subjacente. Os rótulos não são liberados publicamente, garantindo que as submissões possam ser avaliadas de forma consistente ao longo do tempo sem que o benchmark se torne um exercício de memorização.
Quem desenvolve ferramentas de segurança pode baixar o dataset, rodar seu sistema contra o benchmark e submeter predições para avaliação pontuada.
Fonte
The state of AI for security: Measuring what matters most for building trust (https://aws.amazon.com/blogs/security/the-state-of-ai-for-security-measuring-what-matters-most-for-building-trust/)
Leave a Reply