Por dentro do fluxo de trabalho de AI SAST da Fluid Attacks para encontrar candidatos a CVE

Como o scanner passa do código aos candidatos

Em termos gerais, o scanner não pede a um modelo que leia um repositório inteiro e adivinhe onde estão as vulnerabilidades. Primeiro, ele reduz a base de código a unidades menores que possam ser analisadas com maior precisão. A primeira etapa decompõe o repositório e divide o código em funções, que são as unidades nas quais se observam muitos comportamentos relevantes para a segurança: entradas são recebidas, valores são transformados, consultas são construídas, templates são renderizados e verificações de autorização são aplicadas.

Essas funções são então avaliadas por um modelo proprietário de machine learning, treinado com conhecimento acumulado sobre vulnerabilidades por meio da pesquisa de segurança e dos testes de penetração da Fluid Attacks. O modelo atua como um gerador de candidatos. Em vez de declarar uma vulnerabilidade por conta própria, ele produz declarações como: "Esta função pode conter esta fraqueza, com esta pontuação". Essa primeira passagem reduz o espaço de busca para uma análise mais profunda.

A terceira etapa é mais contextual. A lista de candidatos é repassada para agentes de IA especializados, ou seja, fluxos de trabalho de modelos focados em tarefas projetados para raciocinar sobre categorias de fraqueza específicas. Esses agentes utilizam chamadas de ferramentas, que são formas controladas para o modelo inspecionar código relacionado, seguir chamadas de função e navegar pelo repositório. Isso importa porque muitas vulnerabilidades não são visíveis em uma única linha. Um problema de XSS armazenado (cross-site scripting), por exemplo, pode envolver a entrada do usuário em um arquivo, persistência em outro e renderização insegura em um template ou no sink do navegador em outro lugar.

Essa arquitetura ajuda a explicar a diferença entre a detecção de candidatos e a confirmação de vulnerabilidades. A etapa de machine learning pode marcar uma função como suspeita porque ela se assemelha a padrões vulneráveis conhecidos. Em seguida, a etapa do agente pode inspecionar o contexto ao redor para formular perguntas melhores: o valor é controlado pelo atacante? Ele é sanitizado ou escapado antes de chegar a um sink? Essa operação é realmente alcançável? Existe uma verificação de permissões? A rota depende da configuração padrão ou de uma personalização privilegiada?

Para os pesquisadores, o resultado do AI SAST não é um advisory final. É um ponto de partida para a triagem. O scanner pode produzir um arquivo SARIF (um formato padrão para resultados de análises estáticas), de modo que os achados possam ser revisados em uma IDE e vinculados de volta aos arquivos e linhas. A partir daí, um pesquisador clona o repositório, estuda a rota reportada, verifica o código ao redor e decide se o candidato é uma vulnerabilidade real, um falso positivo, uma duplicata ou um achado real, mas inadequado para um ID de CVE.

Como os repositórios são selecionados

Quando o objetivo é identificar candidatos a CVE, nem todo repositório de código aberto é igualmente útil para revisão. Os analistas de segurança da Fluid Attacks priorizam projetos onde uma vulnerabilidade confirmada teria um impacto real de segurança no ecossistema de software mais amplo.

O primeiro filtro é a maturidade: um alvo não deveria ser um exercício acadêmico, uma prova de conceito ou um repositório abandonado com pouco uso prático. O projeto deve ser uma aplicação, um framework ou um componente real que os usuários possam instalar, implementar e do qual possam depender. Sinais como estrelas no GitHub, contagem de instalações, distribuição de pacotes, atividade de releases e adoção pela comunidade ajudam a avaliar se o software tem uso suficiente para justificar uma revisão mais profunda.

O escopo também importa: os pesquisadores evitam projetos que já estejam cobertos por um programa específico de bug bounty ou que estejam claramente sob o escopo de outra CNA. Uma CNA (Autoridade de Numeração de CVE) é uma organização autorizada a atribuir IDs de CVE a vulnerabilidades dentro de um escopo definido. Se um produto pertence a outra CNA, o problema pode continuar sendo válido, mas a atribuição deve seguir o canal dessa CNA em vez do canal da Fluid Attacks.

Isso é especialmente importante para a descoberta assistida por IA, já que o scanner pode gerar muitos candidatos, enquanto o tempo dos profissionais é limitado. Executar o fluxo de trabalho contra projetos com baixa adoção produziria atividade sem necessariamente gerar valor para os usuários, os mantenedores ou o ecossistema. Por outro lado, concentrar-se em aplicações e frameworks de código aberto maduros aumenta a possibilidade de que uma vulnerabilidade confirmada ajude várias equipes a reduzir sua exposição ao risco.

A Fluid Attacks também está trabalhando em um modelo interno para classificar a popularidade do software antes de iniciar a pesquisa de vulnerabilidades. O objetivo não é substituir o critério do pesquisador, mas tornar a priorização mais sistemática. No momento em que esta publicação foi escrita, esse modelo não está integrado ao pipeline de AI SAST, mas aponta para o mesmo princípio: a descoberta deve ser guiada pelo impacto potencial.

De achado candidato a candidato a CVE

Depois que nosso scanner AI SAST produz um achado candidato, a questão deixa de ser "o scanner encontrou um padrão suspeito?" e passa a ser "esse comportamento representa uma vulnerabilidade que deveria ser divulgada publicamente?"

Os pesquisadores começam revisando o fluxo de origem ao coletor (source-to-sink) identificado pelo scanner. Uma origem é um local onde os dados entram na aplicação, como um parâmetro de requisição, uma entrada de usuário armazenada ou conteúdo importado. Um coletor é um local onde esses dados podem causar danos, como um renderizador de HTML, um construtor de consultas SQL ou uma operação sensível à autorização. O pesquisador verifica se os dados são controlados pelo atacante, se chegam ao sink em um contexto perigoso e se a sanitização, o escape, a validação ou as verificações de permissões evitam a exploração.

Se o problema ainda parecer válido, o pesquisador o reproduz localmente com configurações padrão. Um candidato a CVE normalmente deveria refletir uma vulnerabilidade no produto ou componente tal como ele é distribuído, não uma personalização arriscada que só aparece após mudanças privilegiadas. A reprodução também ajuda a separar uma rota de código plausível de um impacto de segurança demonstrável.

Só então o achado avança para a avaliação de CVE: a Fluid Attacks segue as regras operacionais das CNAs e as orientações de aplicação do programa CVE para CNAs. Na prática, isso significa que os analistas confirmam que o problema afeta um produto publicado e suportado, tem um impacto demonstrável na confidencialidade, integridade ou disponibilidade, aplica-se a versões afetadas identificáveis e pode ser explicado com evidências técnicas suficientes para o fornecedor e para a atribuição do ID de CVE.

Alguns achados válidos não se tornam candidatos a CVE porque um fornecedor pode considerar que o comportamento está fora do seu modelo de ameaças, o impacto pode não ser suficientemente demonstrável ou o problema pode depender de uma configuração privilegiada, condições de implantação não suportadas ou código que não faz parte do lançamento normal do produto. Em outros casos, o produto se enquadra no escopo de outra CNA, portanto, a Fluid Attacks não deveria ser a organização a atribuir o ID.

Para os achados que de fato se qualificam, nossos pesquisadores reúnem o material necessário para o escalonamento: detalhes de instalação, contexto afetado, uma explicação técnica da causa raiz, etapas de prova de conceito, imagens que demonstrem a exploração e evidências em vídeo quando isso for útil.

Por que a triagem humana continua sendo essencial

O scanner AI SAST da Fluid Attacks é utilizado intencionalmente como ferramenta de descoberta, não como um sistema autônomo de divulgação. Vale a pena destacar essa diferenciação na pesquisa de software de código aberto, onde os mantenedores frequentemente recebem relatórios automatizados de baixa qualidade e podem rejeitar explicitamente submissões que parecem ter sido geradas totalmente por IA. No nosso caso, portanto, um relatório que chega a um fornecedor deve representar o critério de segurança da Fluid Attacks, não apenas a previsão de um modelo.

A priorização, ou triagem humana, começa determinando se o candidato é explorável. Os analistas de segurança revisam o fluxo reportado, inspecionam os arquivos relacionados e verificam se a aparente vulnerabilidade persiste após os controles reais da aplicação. Muitos candidatos são descartados porque os dados já são sanitizados, escapados, validados ou parametrizados antes de chegar à operação arriscada. Outros são rejeitados porque a suposta entrada controlada pelo atacante é, na verdade, interna, constante, privilegiada ou inalcançável em um fluxo realista.

Há também casos em que o coletor não é perigoso no contexto. Por exemplo, um valor pode ser armazenado, mas nunca renderizado como HTML executável, ou um caminho de autorização suspeito pode ser protegido por verificações no backend que não são óbvias a partir da primeira função relatada. O scanner ajuda os pesquisadores a decidir para onde olhar, enquanto eles decidem o que as evidências provam.

A remoção de duplicatas é, com frequência, outra tarefa humana. O mesmo problema subjacente pode aparecer em vários arquivos, coletores, rotas de chamadas ou variantes de um componente. Sem consolidação, a avaliação exageraria o número de vulnerabilidades e geraria ruído desnecessário para os mantenedores. Os analistas agrupam os achados repetidos, identificam a causa raiz mais clara e decidem qual relatório melhor representa o problema real.

O papel humano torna-se ainda mais importante quando um achado é válido. Os pesquisadores ainda devem determinar o impacto, as versões afetadas, a severidade, a reprodutibilidade e se o comportamento se ajusta ao modelo de ameaças do fornecedor. Também preparam a prova de conceito, documentam o fluxo vulnerável e coordenam a divulgação de modo a permitir que os mantenedores atuem.

O que mostram os resultados atuais

O conjunto de dados atual da pesquisa oferece uma visão útil do funil que vai dos achados gerados por IA aos advisories públicos. Os números a seguir se baseiam nos registros de execução disponíveis no momento em que este blog post foi escrito e devem ser entendidos como um retrato do momento, não como um benchmark final.

Nossos analistas revisaram 1.006 achados gerados pelo scanner AI SAST. Após a triagem manual, 163 foram marcados como verdadeiros positivos, o que significa que os pesquisadores consideraram os comportamentos reportados como candidatos reais a vulnerabilidades que, após consolidação, tornaram-se 118 verdadeiros positivos únicos.

Desses achados, 28 tornaram-se candidatos a CVE. Isso significa que cerca de uma em cada quatro vulnerabilidades exclusivas confirmadas atendeu aos critérios adicionais para avaliação de CVE (ou cerca de 28 candidatos a CVE por 1.000 achados revisados neste conjunto de dados). O restante ainda pode ser problemas de segurança reais, mas não necessariamente problemas que pertencem ao fluxo de trabalho de CVE. Alguns podem não ter impacto demonstrável suficiente, depender de condições fora do modelo de ameaça padrão do produto, estar dentro do escopo de outra CNA ou exigir tratamento por meio de um canal diferente.

Essa proporção também precisa de contexto. Os projetos de código aberto revisados nesse esforço são altamente curados e geralmente cumprem um alto padrão de qualidade de software. Nesse ambiente, muitos achados que parecem suspeitos no início acabam não sendo vulnerabilidades exploráveis. O sinal é intencionalmente mais difícil de extrair do que seria em muitas bases de código empresariais, onde os padrões vulneráveis podem ser mais frequentes ou menos examinados. Como resultado, um agente de IA tem maior probabilidade de cometer erros ao buscar candidatos a CVE em projetos maduros de código aberto do que ao ajudar a identificar vulnerabilidades em software de clientes.

Nossos resultados públicos, que começaram no final de abril de 2026, incluem até o momento 12 avisos exclusivos associados a AI SAST: nove problemas de XSS, dois de injeção de SQL e um de autorização. O XSS ocorre quando o conteúdo controlado pelo atacante chega a um contexto de execução do navegador sem escape ou sanitização suficientes. A injeção SQL ocorre quando uma entrada controlada pelo atacante altera a estrutura ou o comportamento de uma consulta ao banco de dados. Os problemas de autorização aparecem quando a aplicação não consegue impor quem está autorizado a realizar uma operação ou acessar um objeto.

A distribuição reflete as categorias de fraquezas que estão sendo exploradas atualmente. Nosso scanner ainda não foi pensado para encontrar todos os tipos de vulnerabilidades. Nesse fluxo de trabalho de pesquisa, ele está sendo aplicado a um conjunto limitado de tipologias nas quais o contexto é fundamental: se os dados são controlados por um atacante, se atravessam limites de arquivos ou funções, se são armazenados e depois renderizados, se uma abstração de banco de dados constrói SQL inseguro ou se falta uma verificação de autorização na rota real do backend.

A Fluid Attacks dá codinomes aos avisos de segurança. Um exemplo do fluxo de trabalho do SAST de IA é o "Motley", o advisory para uma injeção de SQL no backend MSSQL do Corteza. Esse relatório é útil porque o comportamento vulnerável envolvia parsing de metadados JSON, falta de validação de chaves, escape incorreto de T-SQL e SQL gerado. Outros avisos de SAST de IA, como o "Billie" para autorização inadequada no Camaleon CMS, e os "Pink", "Weeknd" e "Bizkit" para XSS armazenado, mostram o mesmo padrão em diferentes classes de fraqueza: o problema é confirmado ao seguir o contexto, e não ao confiar em uma única linha suspeita.

Por que o AI SAST e o SAST tradicional são complementares

O SAST tradicional continua sendo valioso porque muitas fraquezas têm padrões estáveis. Se um parâmetro de requisição é refletido em uma resposta sem validação, ou se uma função perigosa conhecida recebe dados não confiáveis, um scanner baseado em regras ou guiado pelo fluxo de dados muitas vezes consegue marcar o risco de forma eficiente. O objetivo do AI SAST não é substituir essa capacidade, mas cobrir os casos em que o padrão é menos estável e o contexto ao redor fornece uma parte maior do significado de segurança.

Um contraste útil, por exemplo, é o "Skims-8", um aviso da Fluid Attacks detectado por nosso scanner SAST tradicional. O relatório descreve um problema de XSS refletido no Ad Inserter, em que o conteúdo da web era gerado dinamicamente sem validar um valor potencialmente não confiável. A linha vulnerável mostrada no aviso é clara o suficiente para um scanner convencional identificar: um valor POST é refletido de volta na página.

O Motley, embora represente um tipo diferente de fraqueza, mostra que o problema do Corteza não foi apenas "a entrada chega ao SQL". A rota relevante envolvia um parâmetro meta HTTP, parsing de objetos JSON, omissão de validação de chaves, comportamento de escape específico do MSSQL, SQL gerado para rotas JSON e as permissões necessárias para chegar ao endpoint afetado. Detectar esse tipo de problema exige acompanhar como os dados mudam por meio de funções e arquivos e, então, perguntar se os controles nessa rota são realmente eficazes.

Cada abordagem se adapta melhor a um cenário: o SAST tradicional é forte para padrões estáveis com pouca carga contextual, enquanto o SAST de IA é promissor para fraquezas cuja explorabilidade depende de um contexto de código mais amplo.

Para os clientes e as equipes de pesquisa, a melhor opção não é escolher um scanner em vez de outro. É combiná-los com revisão humana para que padrões simples sejam detectados de forma eficiente, rotas complexas recebam uma análise mais profunda e os relatórios finais sejam respaldados por evidências reproduzíveis.

O que este trabalho está nos ensinando

O trabalho de CVE de código aberto descrito aqui é um esforço ativo de pesquisa e experimentação. Estamos usando repositórios públicos para avaliar até onde o AI SAST pode chegar na descoberta de vulnerabilidades, onde ele funciona bem e onde a validação de especialistas continua sendo necessária. O propósito não é apresentar a IA como uma substituição definitiva para a pesquisa de segurança, mas aprender onde ela pode acelerar, ampliar e tornar essa pesquisa mais precisa.

Ao mesmo tempo, o SAST de IA não é apenas uma ideia de pesquisa. A Fluid Attacks oferece testes estáticos de segurança de aplicações baseados em IA como parte de sua abordagem de segurança mais ampla, na qual técnicas automatizadas, análises assistidas por IA e o suporte de especialistas trabalham em conjunto. Os achados de código aberto nos dão uma maneira transparente de mostrar parte dessa capacidade em ação: geração de candidatos, análise contextual de código, triagem manual, avaliação de CVE e divulgação responsável.

Os advisories públicos de AI SAST publicados até agora demonstram que essa técnica pode ajudar a identificar vulnerabilidades em projetos de software reais, incluindo casos que exigem mais contexto do que um padrão de uma única linha. Também deixam claro por que o processo deve continuar sendo cuidadoso: os achados devem ser reproduzidos, deduplicados, delimitados, documentados e divulgados pelos canais adequados.

Esse é o padrão que continuamos buscando. Na pesquisa de código aberto, isso significa uma melhor priorização de alvos, uma revisão mais sistemática de candidatos e divulgações respaldadas por mais evidências. Para as organizações que criam e mantêm software, trata-se de uma forma prática de expandir a análise estática para além dos padrões óbvios. Se a sua equipe quer ver como o AI SAST gera valor para mantenedores e usuários — não apenas mais alertas — e pode fortalecer seu AppSec, entre em contato conosco.