AI SAST

O que é AI SAST?

AI SAST aplica um modelo de linguagem grande (LLM) ao código-fonte para encontrar vulnerabilidades. Nosso próprio arcabouço de comparação de fornecedores o define como uma solução que oferece capacidades de detecção de vulnerabilidades impulsionadas por inteligência artificial por meio de SAST. O LLM recebe o código com o contexto ao redor, raciocina sobre o fluxo de dados e devolve um julgamento com sua explicação, em vez do identificador de uma regra.

A diferença em relação ao teste estático de segurança de aplicações (Static Application Security Testing) convencional está em onde mora a decisão. Um scanner baseado em regras codifica de antemão como uma vulnerabilidade se parece. Quem escreve a regra descreve um sink perigoso, uma função insegura, um caminho contaminado. Tudo o que essa pessoa não antecipou fica invisível. AI SAST inverte isso: ao modelo não se diz como o erro se parece, pergunta-se a ele se este código, neste contexto, pode ser abusado.

Que os modelos encontram falhas reais não é teórico. Em 2024, Google Project Zero e Google DeepMind relataram que seu agente Big Sleep achou um stack buffer underflow explorável no SQLite, a primeira vulnerabilidade do mundo real descoberta pelo agente, e os mantenedores do SQLite a corrigiram no mesmo dia. Big Sleep é pesquisa agêntica, não AI SAST: ele persegue um alvo em profundidade, enquanto AI SAST roda de forma contínua sobre um repositório que muda. O que importa aqui é o terreno comum: um modelo raciocinando sobre código encontrou o que as regras não encontraram.

AI SAST, SAST tradicional e agentes de codificação não são alternativas

Três coisas se misturam em uma só conversa, e quem compra paga a confusão. Um conjunto de regras faz corresponder padrões. AI SAST julga o contexto. Um assistente de codificação escreve software e, de quebra, pode ser instruído a procurar erros. Eles têm modos de falha distintos e nenhum substitui os outros dois.

As regras seguem ganhando onde o padrão é estável e a carga de contexto é baixa. Uma credencial escrita no código, uma cifra obsoleta, uma verificação de certificado desabilitada: uma expressão regular resolve isso mais rápido do que qualquer modelo. AI SAST ganha seu custo em fraquezas cuja explorabilidade depende de código que precisa ser montado entre vários arquivos.

Por isso AI SAST fica ao lado da varredura baseada em regras e não acima dela: as verificações determinísticas baratas continuam baratas, e o orçamento de tokens vai para as classes que precisam do julgamento de um modelo. Uma organização que troca seu conjunto de regras por AI-powered SAST paga preços de modelo por achados que uma expressão regular já pegava. AI-powered SAST é uma adição a um programa de segurança de aplicações, não uma substituição dentro dele.

AI SAST na Fluid Attacks

Nosso scanner de AI SAST roda dentro do mesmo programa que nossos outros scanners e nossos pentesters, disponível em nossos planos. O que segue é o que ele realmente faz, incluídas as partes de nossos resultados que não nos favorecem.

O que analisamos e sob quais regras

Seu código-fonte é analisado sob contrato e sob os controles de nossas páginas de conformidade: TLS 1.3 em trânsito, AES-256 para o armazenamento de objetos e o banco de dados da plataforma, e TLS mútuo até nossa origem. A evidência de auditoria de SOC 2, PCI DSS e ISO está em nosso Trust Center. Os achados ficam em nossa plataforma, onde sua equipe controla o acesso, e nosso acordo de nível de serviço nos compromete a detectar 90 % da severidade das vulnerabilidades, medido por trimestre-calendário sobre todos os seus grupos.

Como os candidatos são priorizados

AI SAST não tenta ler todos os arquivos, porque ler todos eles é o objetivo errado quando cada leitura custa tokens. Nossa documentação é explícita: as técnicas manuais e o AI SAST usam priorização estatística de risco, e não cobertura de arquivos, como objetivo operacional, e o modelo de priorização do AI SAST usa a probabilidade de um trecho conter uma vulnerabilidade específica.

Essa é a decisão arquitetural que torna a técnica viável. Os trechos chegam ao modelo em ordem de risco estimado, de modo que o orçamento aterrissa no código com maior probabilidade de ser vulnerável em vez de se espalhar por igual sobre código que não é.

Como isso se parece na prática

De achados de IA a advisories publicados

Apontamos o scanner para projetos de código aberto para testá-lo contra código que ninguém escreveu para nós. O funil de nosso fluxo de trabalho publicado é a imagem mais clara do que essa técnica rende.

CVE-2026-6093 mostra por que o contexto é tudo. No Corteza 2024.9.x, a função jsonPath escapava aspas simples com uma barra invertida em vez de duplicar a aspa como o T-SQL exige, e um segundo defeito permitia que payload.ParseMeta pulasse a validação do formato das chaves quando meta chegava como um objeto JSON. Nenhum dos dois é uma vulnerabilidade sozinho. Juntos, eles permitem que um usuário autenticado injete SQL em uma expressão gerada. Nosso scanner marcou o candidato; Oscar Uribe, do nosso Offensive Team, confirmou a cadeia e publicou nosso advisory.

Nosso advisory de CVE-2026-6093, com o scanner que a detectou e o pesquisador que a divulgou.

Onde nossos próprios números incomodam

Em nosso benchmark contra agentes de codificação, a configuração de AI SAST que mais encontrou vulnerabilidades reais as encontrou com 52 % de precisão. Pegou 72 de 100 falhas semeadas e levantou 66 apontamentos equivocados no processo. Mais recall se paga com trabalho de triagem, e qualquer fornecedor que informe um número sem o outro esconde metade do acordo.

O segundo resultado nos surpreendeu mais. Rodar o mesmo sistema sobre modelos maiores piorou tudo: 0,19 de recall com GPT-5.5 e 0,47 com Opus 4.8, contra 0,72 com a configuração mais barata. A extração, a análise de fluxo e a validação em torno do modelo pesaram mais do que o próprio modelo. Compre a arquitetura, não o nome do modelo.

O que esta técnica não cobre

Nosso scanner ainda não busca todos os tipos de fraqueza. A pesquisa se concentra nas classes em que o contexto decide a explorabilidade: fluxos entre arquivos, persistência de dados, SQL e controles de autorização. Ele também não substitui a análise de composição de software, que olha dependências de terceiros e não seu próprio código, nem os testes dinâmicos nem a revisão de configuração em nuvem. Um CVE em uma biblioteca que você importou não é um problema que o AI SAST esteja procurando.

Como o AI SAST funciona

Um pipeline de AI SAST tem quatro movimentos. O repositório é dividido em funções. Um modelo pontua cada função conforme a probabilidade de uma fraqueza específica. Os trechos mais bem classificados passam a agentes especializados que trazem o código ao redor com chamadas a ferramentas: chamadores, chamados, templates relacionados, a camada de armazenamento. Cada candidato é então confirmado ou descartado com seu raciocínio anexado.

O modelo atua como gerador de candidatos, não como veredito. Esse enquadramento é o que mantém o AI SAST utilizável. Um modelo ao qual se pede uma resposta final sobre explorabilidade vai produzi-la, sustente ou não a evidência, e é assim que vulnerabilidades alucinadas chegam à fila de um desenvolvedor. Cada passo depois da pontuação existe para obrigar o modelo a provar sua afirmação contra código recuperado.

O não determinismo é tratado do mesmo jeito: por projeto e não por esperança. O mesmo trecho pode receber respostas diferentes entre execuções, então o pipeline limita o que se pergunta ao modelo, o ancora em código que ele de fato leu e trata cada positivo como um candidato a verificar. Um achado que sobrevive a isso merece a atenção de um desenvolvedor.

É aqui que o AI SAST se separa de apontar um modelo de chat para um repositório. O modelo é a menor parte do sistema: a extração decide o que ele enxerga, a pontuação decide o que ele lê primeiro, a validação decide o que chega a uma pessoa. Em nossos testes, essas três etapas explicaram mais do resultado do que o modelo.

AI SAST em comparação com o SAST tradicional

Os scanners baseados em regras e o AI SAST falham em direções opostas, e a comparação só faz sentido por classe de fraqueza, não no agregado.

Compreensão do contexto

Muitas vulnerabilidades não são visíveis em uma única linha. O cross-site scripting armazenado é o exemplo clássico: a entrada do usuário chega em um arquivo, é persistida em outro e é renderizada sem escape em um template em outro lugar. Cada arquivo parece correto por si só. Nosso catálogo de fraquezas descreve o XSS armazenado como a possibilidade de injetar JavaScript de forma persistente nos campos da aplicação, o pontua em CVSS 4.0 e o mapeia para correções em sete linguagens, mas encontrá-lo em um repositório real significa montar três arquivos em uma única história.

A entrada 010 do nosso catálogo de fraquezas, com sua pontuação CVSS 4.0 e as correções por linguagem.

Essa montagem é o que o AI SAST faz e o que um scanner de um único arquivo estruturalmente não consegue fazer.

Precisão, recall e o que cada um custa

A pesquisa independente aponta na mesma direção. No ICLR 2025, os autores do IRIS combinaram um modelo de linguagem com análise estática e o avaliaram sobre 120 vulnerabilidades validadas manualmente: o CodeQL detectou 27 e o IRIS com GPT-4 detectou 55, e quatro de seus achados eram desconhecidos das ferramentas existentes.

Nossos próprios dados apontam para a mesma lacuna. Em nosso benchmark de 36 ferramentas de AppSec de terceiros contra uma aplicação web semeada com 1.201 vulnerabilidades em 105 categorias CWE, um pentester alcançou 89,6 % de recall com 100 % de precisão, bem acima do que qualquer ferramenta automatizada conseguiu sobre o mesmo alvo. Fechar parte dessa distância sem colocar uma pessoa em cada arquivo é o trabalho para o qual o AI SAST foi construído.

Suporte a linguagens e execução

As regras são escritas por linguagem, então a cobertura cresce uma gramática por vez e os frameworks novos ficam para trás. Um modelo generaliza entre sintaxes, o que torna o AI SAST útil em linguagens que um conjunto de regras ainda não alcançou, embora uma classe de fraqueza que o pipeline não persegue continue sendo omitida, qualquer que seja a linguagem.

AI SAST em comparação com os agentes de codificação

Pedir a um agente de codificação que audite um repositório não é o mesmo que rodar um scanner construído para auditar repositórios. Medimos a lacuna sobre 52 bases de código, 68 versões e cerca de 98 milhões de linhas de código, e então avaliamos cada configuração com 200 trechos: 100 vulnerabilidades reais de injeção e de scripting, e 100 iscas escritas para parecer vulneráveis sem serem exploráveis.

Os custos marcados com asterisco são projetados a partir de uma execução focalizada, não medidos de ponta a ponta.

Leia a última linha com cuidado, porque é a que um painel vai reportar errado. O Claude Code produziu zero falsos positivos e 100 % de precisão, o que parece o melhor resultado da tabela. Ele também deixou passar 92 das 100 vulnerabilidades reais. Uma ferramenta que nunca grita lobo e nunca encontra o lobo não é um controle de segurança. Esta é uma medição de duas classes de vulnerabilidade sobre um conjunto de dados, não um ranking geral desses produtos, mas basta para mostrar que a precisão sozinha não diz nada sobre a cobertura.

AI SAST para remediação, verificação e conformidade

AI SAST que para em um ticket não reduz o risco. Para que a remediação de vulnerabilidades aconteça de fato, três coisas precisam seguir um achado: uma correção sobre a qual o desenvolvedor possa agir, prova de que a correção funcionou e uma linha de volta até a norma contra a qual a organização é auditada.

A orientação de correção com IA generativa é a primeira. Um patch aplicado em um clique é conveniente, mas um guia que explica a alternativa segura no contexto da sua base de código muda como a próxima função é escrita. Os desenvolvedores que recebem orientação contextual param de reintroduzir a mesma classe, que é o retorno composto que o AI SAST tem sobre um scanner que apenas rotula.

A verificação é a segunda. Uma correção não está terminada porque um modelo diz que está; nossa plataforma permite que sua equipe solicite um reataque, e a vulnerabilidade segue aberta até que os testes confirmem que foi fechada. Nosso CI Gate quebra a compilação quando um achado viola sua política, o que impede que código não verificado seja implantado.

A conformidade é a terceira, e é onde o AI SAST economiza mais tempo sem que se perceba. Nosso catálogo de regras de segurança reúne 2.206 regras sobre 47 alvos, mapeadas para 173 padrões, de modo que um achado chega já conectado ao requisito de OWASP, PCI DSS ou NIST que ele viola. Os auditores não aceitam uma lista de erros; aceitam um controle mapeado com evidência de fechamento, e esse mapeamento é o que transforma a saída do AI SAST em evidência de auditoria e não em um acúmulo.

Como avaliar uma solução de AI SAST

O projeto OWASP Benchmark existe para verificar a velocidade e a exatidão das ferramentas de detecção de vulnerabilidades, e sua lógica é o ponto de partida correto para avaliar o AI SAST: uma afirmação sem um conjunto de dados por trás é marketing. A maioria das propostas de AI SAST abre com a precisão, porque a precisão é o número que melhora quando uma ferramenta reporta menos. Estas são as perguntas que vale fazer no lugar.

Um achado em nossa plataforma, com a explicação de onde a entrada do atacante chega à consulta.

Conclusões

AI SAST move a decisão sobre se um código é explorável de uma regra escrita de antemão para um modelo que raciocina sobre o contexto, e essa mudança é o que lhe permite pegar fraquezas espalhadas por vários arquivos. Não é grátis nem é limpo: nossa configuração de maior recall rodou com 52 % de precisão, os modelos maiores renderam abaixo do mais barato, e cada candidato ainda passa por uma pessoa antes de virar um relatório de vulnerabilidade. Esses limites são a razão pela qual publicamos os números em vez de um único valor de precisão, e a razão pela qual o AI SAST fica dentro de um programa de segurança de aplicações com scanners e pentesters em vez de ocupar o lugar deles. Agents build, you lead, we secure, e a parte de proteger ainda termina com uma pessoa lendo a evidência.

Perguntas frequentes

Quão exato é o AI SAST?

 Depende inteiramente da configuração e do conjunto de dados, e por isso um único número não é uma resposta. Em nosso benchmark de 200 trechos sobre falhas de injeção e de scripting, nossa configuração de maior recall encontrou 72 de 100 vulnerabilidades reais com 52 % de precisão, enquanto as configurações construídas sobre modelos maiores alcançaram 0,47 e 0,19 de recall.

O AI SAST encontra vulnerabilidades que os scanners baseados em regras deixam passar? 

Sim, especificamente aquelas cuja explorabilidade depende de código em outros arquivos. As falhas de scripting armazenado e as cadeias de injeção que cruzam um manipulador de entrada, uma camada de armazenamento e um template são os casos mais claros. A pesquisa independente aponta na mesma direção: no ICLR 2025, o IRIS detectou 55 de 120 vulnerabilidades validadas onde o CodeQL detectou 27.

Qual é a diferença entre AI SAST e um agente de codificação com IA? 

Um agente de codificação é construído para escrever software e pode ser instruído a procurar erros; o AI SAST é um pipeline construído para encontrá-los, com extração de código, análise de fluxo, priorização e validação em torno do modelo. Em nosso benchmark, dois agentes de codificação encontraram 9 e 8 de 100 vulnerabilidades reais.

O AI SAST ainda precisa de revisão humana? 

Sim. Um achado do modelo é um candidato, não uma vulnerabilidade confirmada. Nossos analistas determinam se dados controlados por um atacante chegam a uma operação perigosa e se a sanitização, o escape, a validação ou a autorização bloqueiam isso, e então cuidam da deduplicação e da severidade.

A Fluid Attacks usa AI SAST para encontrar CVEs novos? 

Sim. De 1.006 achados do scanner que nossos analistas revisaram em projetos de código aberto, 118 eram verdadeiros positivos únicos e 28 viraram candidatos a CVE. Doze são advisories publicados, entre eles CVE-2026-6093, uma injeção SQL no Corteza confirmada e divulgada pelo nosso Offensive Team.

Coloque os achados do modelo diante de um pentester

Nosso scanner de AI SAST e nossos pentesters revisam seu código juntos, de modo que um candidato vira vulnerabilidade confirmada antes de chegar à fila dos seus desenvolvedores. Teste gratuito · Entre em contato conosco