Um Engenheiro e Dez Mãos: Como Investigamos LLMs em AppSec

Um Engenheiro e Dez Mãos: Como Investigamos LLMs em AppSec

Olá a todos, aqui é a Solar appScreener! Neste artigo, compartilharemos nossa experiência com o uso de IA em nosso próprio produto. Agentes de IA já se tornaram parte integrante do processo de desenvolvimento, não é mais uma moda passageira, mas uma nova realidade. De acordo com uma pesquisa da Sonar (State of Code Developer Survey 2026, https://www.sonarsource.com/state-of-code-developer-survey-report.pdf), 72% dos desenvolvedores que tentaram usar IA começaram a usá-la diariamente. E 42% de todo o código escrito já foi gerado por IA ou significativamente aprimorado por ela. Números incríveis. Deve-se admitir que vivemos em uma nova realidade, na qual o 'vaibcoding' é um novo estilo de programação.

Mas a questão permanece em aberto – o que está acontecendo com a segurança desse código?! E aqui os dados são decepcionantes. A IA continua a gerar código com vulnerabilidades. 45% das amostras de código geradas por IA se mostraram inseguras (Veracode. GenAI Code Security Report, https://www.veracode.com/blog/genai-code-security-report/). É como jogar uma moeda, se o código foi gerado com segurança ou não. Não é o que você quer ver no contexto da segurança. Aqui estão algumas das principais razões pelas quais isso acontece:

1. Os modelos foram treinados em vastas quantidades de código público, adotando padrões e estilos de escrita. E havia muitas vulnerabilidades e modelos de código inseguros.
2. A IA não “entende” o que é segurança como um conceito na escrita de código, mas continua uma sequência estatisticamente provável de tokens.
3. A IA ainda não consegue manter “em mente” todo o projeto, onde e como as informações confidenciais circulam nele, por exemplo, a definição do usuário, e, portanto, comete erros.

Mas isso não significa que a IA não possa resolver problemas de segurança. Pode, e muito!

Atualmente, cada vez mais fornecedores estão se movendo na direção da implementação inteligente de IA em seus produtos. Os casos de uso mais bem-sucedidos de acordo com pesquisas atuais (Veracode. GenAI Code Security Report, https://www.veracode.com/blog/genai-code-security-report/, Checkmarx 2025 Trends on AI Security, https://checkmarx.com/learn/ai-security/2025-trends-on-ai-security-how-appsec-must-evolve-with-the-ai-shifted-sdlc/) é o uso de IA para triagem de vulnerabilidades encontradas e geração de correções para elas. Um fato interessante – ninguém prevê a substituição de analisadores SAST/DAST clássicos pela IA; pelo contrário, eles recebem um impulso adicional para o desenvolvimento devido à IA.

Como é um SAST clássico:

Por que não há tempo suficiente para a triagem clássica?

Portanto, surge a questão: como automatizar toda essa rotina e obter amostras de código seguro? Talvez IA?

Mas aqui vale a pena fazer a si mesmo mais algumas perguntas:

• Quais dados devem ser transmitidos para a IA?
• Onde obter IA?
• Estamos realmente automatizando a triagem com IA?
• Estamos realmente automatizando a correção de código com IA?
• O que acontecerá com a confidencialidade do meu código e dados?

Conhecendo todas essas “dores”, nós da “Solar” alguns anos antes de o 'vaibcoding' se tornar uma rotina diária, começamos a desenvolver um plug-in de IA para nosso produto Solar appScreener. Ele é chamado DerAI e inclui duas tecnologias: DerTriage (triagem de vulnerabilidades encontradas pelo analisador SAST) e DerCodeFix (geração de código corrigido para tais acionamentos). E tudo isso mesmo no local, e não apenas na “nuvem”!

Como funciona

O appScreener tem um mecanismo para filtrar falsos acionamentos há muito tempo – o Fuzzy Logic Engine. Esta tecnologia patenteada usa o aparato matemático da lógica difusa para determinar a veracidade do acionamento. Por 7 anos, analisamos e rotulamos vários projetos de código aberto, tanto propositadamente vulneráveis quanto projetos comuns, estudamos a documentação de bibliotecas e frameworks, escrevemos os casos de teste correspondentes para aprimorar esse mecanismo. E todo esse volume acumulado de dados rotulados foi a base para treinar nosso próprio modelo.

Testamos vários LLMs de código aberto, identificamos o modelo ideal e começamos a retreiná-lo com as informações que acumulamos. Como toda a rotulagem dos dados originais ocorreu inicialmente usando o appScreener, o modelo final também é adaptado para ele, e eles funcionam perfeitamente em conjunto; os números específicos serão fornecidos abaixo.

E aqui está a aparência de DerTriage e DerCodeFix na interface.

Na entrada para processamento, não apenas um código de amostra é fornecido, mas todas as informações disponíveis para o analisador. São descrições de regras, recomendações e exemplos de correção, todo o rastreamento de vulnerabilidade com contexto adicional para cada nó e outros metadados. Instruções adicionais sobre como trabalhar corretamente com a base de código existente para manter sua capacidade de trabalho. Isso é importante ao gerar correções.

Tudo isso permitiu obter um modelo compacto e otimizado com excelentes indicadores de precisão e eficiência. Tudo de acordo com os ensinamentos de Bruce Lee.

Por que isso é melhor do que apenas perguntar a um modelo de IA:

O LLM de amplo perfil está “entulhado” com informações desnecessárias. Voltamos à tese de que ele gera código mal, e a segurança é 50/50. Além disso, é um alto consumo de recursos na versão local: quanto maior o modelo, mais ele consome. Além disso, os riscos de perda de confidencialidade da base de código ao enviá-la para digitalização na “nuvem” para empresas estrangeiras.

Observe também a dificuldade de pesquisa. Tente enviar um arquivo de código grande para ele e peça para encontrar vulnerabilidades nele. E então digitalize-o com diferentes analisadores SAST. Os resultados não coincidirão. E quanto à análise entre procedimentos? E entre arquivos? E com análise durante a compilação? Um LLM comum não pode fazer isso, mas SAST+LLM pode.

Então, agora a parte mais interessante. Vamos para a batalha dos LLMs em nuvem e locais em AppSec

Dos grandes LLMs em nuvem, consideramos:

1. ChatGPT 5.2
2. DeepSeek 3.2
3. Gigachat

Dos modelos locais comparáveis em tamanho, selecionamos:

1. ChatGPT OSS openai/gpt-oss-20b 05/08/2025
2. Mistral 14b-2512 02/12/2025
3. LocalChat

Primeiro, analisamos 20 aplicativos escritos em Java e Python. Por que exatamente essas linguagens? Em primeiro lugar, elas pertencem à categoria das linguagens mais fáceis e difíceis para IA no contexto da segurança (Veracode. GenAI Code Security Report, https://www.veracode.com/blog/genai-code-security-report/), em segundo lugar, elas são muito comuns:

sua participação é de 45,4% e 61,8% entre as principais linguagens de programação na Rússia.

Todos os aplicativos são bastante grandes – a partir de 100.000 linhas de código, então coletamos um grande conjunto de dados. Identificamos cerca de 12.000 acionamentos exclusivos do analisador, enquanto um quinto das vulnerabilidades pertencia à categoria crítica.

Em seguida, formamos um único prompt. Ele incluía dados do sistema: o nome da vulnerabilidade, descrição, segmento de código, rastreamento de acessibilidade (o caminho de dados para a função insegura), identificadores de vulnerabilidade adicionais (CWE). Também adicionamos um padrão de usuário “Imagine que você é um AppSec experiente”. Assim, todos os modelos receberam o mesmo conjunto de informações e prompt, tudo é cristalino.

Então, triagem: o que estamos avaliando?

Avaliaremos 4 métricas – precisão geral, precisão, exaustividade e porcentagem de erros:

• Precisão geral – quão corretamente o LLM determina a veracidade e a falsidade do acionamento. É calculado como (TP+TN)/ALL
• Precisão – quantas vulnerabilidades reais estão entre aquelas que o LLM marcou como verdadeiras. É calculado como TP/(TP+FP).
• Exaustividade – quantas das vulnerabilidades reais do projeto foram identificadas pelo LLM. É calculado como TP/(TP+FN).
• Porcentagem de erros – com que frequência o LLM comete erros no processo de rotulagem. É calculado como (FP+FN)/ALL.

Para o caso, vamos lembrar o que essas abreviações significam:

• TP – LLM confirmou corretamente o acionamento verdadeiro
• TN – LLM rejeitou corretamente o acionamento falso
• FP – LLM confirmou erroneamente o acionamento falso
• FN – LLM rejeitou erroneamente o acionamento verdadeiro

Projetos Java

Por exemplo, ao processar os resultados da verificação do projeto vulnado, os modelos mostraram os seguintes resultados:

Ao analisar em toda a seleção de projetos Java e resumir os resultados, obtemos as seguintes métricas:

Observação sobre a exaustividade de 100% do ChatGPT. Isso é alcançado por meio de uma deterioração perceptível em outras avaliações. Se todos os acionamentos do analisador forem confirmados, então FN será = 0, o que significa que a exaustividade = 100%. Mas isso não significa que o LLM fez um ótimo trabalho, pelo contrário, ele não conseguiu filtrar os falsos acionamentos, o que levou a uma diminuição nas outras métricas.

Projetos Python

Por exemplo, ao processar os resultados da verificação do projeto vulpy, os modelos mostraram os seguintes resultados:

Ao analisar em toda a seleção de projetos Python e resumir os resultados, obtemos as seguintes métricas:

O ChatGPT se comporta diametralmente oposto e se esforça não para FN=0, mas para FP=0, rejeitando uma massa de acionamentos verdadeiros, o que se reflete em outras métricas.

Tabela de resultados

Dos testes, pode-se ver que tanto no Java, que é mais difícil para a organização da segurança para IA, quanto no Python, que é mais simples, o modelo DerAI especializado para AppSec se mostra significativamente melhor do que seus concorrentes para a triagem de vulnerabilidades.

Agora é a vez do DerCodeFix

É mais fácil com ele. Avaliaremos se a correção proposta corrige a vulnerabilidade (Boa) ou não (Não Boa) e observaremos a precisão do processamento.

Tabela de resultados

De acordo com a pesquisa, a tarefa de gerar uma correção é notavelmente mais difícil do que a triagem de vulnerabilidades. E isso é claramente confirmado pelas estatísticas. Aqui, o treinamento e a adaptação do modelo DerAI para resolver tarefas específicas são visíveis como nunca.

Nossas conclusões:

A IA é mais do que aplicável em AppSec, e a indústria está se movendo ativamente nessa direção. Mas o uso de LLMs clássicos para resolver tarefas atuais é improdutivo: é mais barato e fácil jogar uma moeda na triagem, e a eficiência não será pior do que a dos grandes LLMs. Mas há uma solução, são modelos especializados, adaptados para segurança, integrados ao próprio analisador de segurança de código, como o DerAI no appScreener. Esses modelos mostram excelentes resultados hoje e são mais do que aplicáveis na vida real no momento.

Esperamos suas ideias e pensamentos nos comentários!