Extracting Recurring Vulnerabilities from Black-Box LLM-Generated Software

Each language version is independently generated for its own context, not a direct translation.

Imagine que você está construindo uma casa usando um arquiteto robótico superinteligente (uma IA de geração de código). Você pede a ele: "Faça uma porta para entrar" ou "Crie um sistema para pagar contas". O robô é rápido e faz o trabalho, mas ele tem um defeito curioso: ele é previsível.

Sempre que você pede "porta", ele usa o mesmo modelo de fechadura, que tem um defeito de fábrica. Sempre que você pede "pagamento", ele usa o mesmo cofre, que tem uma dobradiça frágil. O problema é que, como o robô é tão rápido, ele constrói milhares de casas usando esses mesmos modelos defeituosos.

Este artigo de pesquisa é como um detetive particular que descobriu como explorar essa previsibilidade.

Aqui está a explicação do que eles descobriram, usando analogias simples:

1. O Problema: A "Firma" do Robô

Quando os robôs (IAs como GPT, Claude, Gemini) escrevem código, eles não pensam como humanos. Eles seguem padrões estatísticos. Se eles aprenderam a fazer um "botão de login" de uma maneira insegura uma vez, é muito provável que eles façam milhares de botões de login inseguros exatamente da mesma maneira.

Os pesquisadores chamam isso de "Vulnerabilidade Recorrente". É como se o robô tivesse um "taco de golfe" com um defeito específico: toda vez que ele usa esse taco para bater na bola, a bola vai para o mesmo lugar errado.

2. A Solução: A "Tabela de Decodificação" (FSTab)

Os autores criaram uma ferramenta chamada FSTab (Tabela de Recurso-Segurança). Pense nela como um dicionário de detetive ou um mapa do tesouro.

Como funciona: O detetive olha apenas para a frente da casa (o que o usuário vê no site: botões, formulários, menus).
A Mágica: Com base apenas no que ele vê na frente, a tabela diz: "Ei, se esse site tem um botão 'Login' feito pelo robô X, é 94% de chance de que a porta dos fundos (o servidor) tenha uma fechadura quebrada."

O incrível é que o detetive não precisa entrar na casa nem ver os planos originais (o código fonte). Ele só precisa saber qual robô construiu o site e o que o site faz.

3. O Ataque: "Adivinhando o Invisível"

Imagine que você é um ladrão. Em vez de tentar arrombar cada porta de cada casa da cidade (o que levaria anos), você usa a tabela FSTab.

Você vê que o site tem um "Formulário de Cadastro".
Você consulta a tabela do robô que fez o site.
A tabela diz: "Ah, robôs desse tipo sempre deixam uma janela aberta no formulário de cadastro".
Você vai direto para essa janela e entra.

Isso é o que chamam de Ataque de Caixa-Preta. Você não sabe como a casa foi construída por dentro, mas sabe exatamente onde estão as falhas porque conhece a "personalidade" do construtor.

4. A Descoberta Chocante: "Universalidade"

O estudo descobriu algo assustador: essas falhas não dependem do tipo de site.

Se o robô faz um site de e-commerce com uma falha no carrinho de compras, ele provavelmente fará a mesma falha em um site de blog ou em um sistema interno de empresa.

É como se o robô tivesse um "vício" em usar fechaduras ruins. Não importa se é uma casa, um escritório ou uma loja; se ele faz uma porta, ele usa a mesma fechadura defeituosa. Isso significa que um atacante pode estudar um tipo de site e usar esse conhecimento para invadir qualquer outro tipo de site feito pelo mesmo robô.

5. Por que isso importa?

Para os Desenvolvedores: Eles precisam parar de confiar cegamente que a IA está segura só porque o código "parece" funcionar. Eles precisam verificar se o robô está usando seus "vícios" inseguros.
Para a Segurança: Estamos criando um novo tipo de risco. Não é apenas um hacker tentando quebrar um código difícil; é um hacker usando a previsibilidade da própria IA contra nós.
A Metáfora Final: É como se a IA fosse um cozinheiro que sempre coloca sal demais na sopa. Se você sabe que ele é o cozinheiro, você não precisa provar a sopa inteira para saber que ela está salgada. Você só precisa olhar para o nome dele na porta da cozinha.

Resumo em uma frase

Os pesquisadores criaram um mapa que permite que hackers prevejam onde estão as falhas de segurança em softwares feitos por IAs, apenas olhando para o que o usuário vê na tela, porque essas IAs repetem os mesmos erros de construção como se fossem um "padrão de fábrica" inevitável.

Each language version is independently generated for its own context, not a direct translation.

Título: Extração de Vulnerabilidades Recorrentes de Software Gerado por LLMs de Caixa-Preta

1. O Problema

O uso de Grandes Modelos de Linguagem (LLMs) para geração de código está em crescimento acelerado, com cerca de 30% das novas funções Python em algumas regiões sendo geradas por IA. No entanto, há um risco crítico de segurança: os LLMs tendem a seguir padrões de código recorrentes e templates canônicos ao gerar software.

O problema central identificado é que essas repetições de padrões não são apenas funcionais, mas frequentemente vulneráveis. Um único modelo de LLM pode introduzir as mesmas falhas de segurança (ex: injeção de SQL, falta de rate limiting, exposição de pilhas de erro) em múltiplos programas, independentemente do domínio da aplicação ou da formulação do prompt.

A lacuna atual na segurança reside no fato de que as defesas existentes (como analisadores estáticos) operam post-hoc (após a geração) e tratam cada programa isoladamente. Elas não conseguem prever vulnerabilidades ocultas no backend baseando-se apenas nas funcionalidades visíveis no frontend (caixa-preta), nem modelam a regularidade cruzada entre programas gerados pelo mesmo modelo.

2. Metodologia: FSTab (Feature–Security Table)

Os autores propõem o FSTab, uma tabela de consulta que mapeia funcionalidades de frontend observáveis para vulnerabilidades de backend latentes, específicas de cada modelo de LLM.

A. Construção do FSTab (Fase de Treinamento/Construção):

Geração de Corpus: O modelo alvo gera um grande conjunto de aplicações completas (multi-arquivos) em diversos domínios.
Rótulo Automático: O código gerado é analisado por ferramentas de análise estática (CodeQL e Semgrep) para identificar vulnerabilidades reais (ground truth) e por parsers para extrair funcionalidades de frontend (ex: "login com senha", "upload de arquivo").
Mapeamento Probabilístico: Em vez de usar contagens simples de frequência, o FSTab utiliza a Informação Mútua Ponto a Ponto (PMI) para calcular a associação entre uma funcionalidade $f$ $f$ e uma vulnerabilidade $r$ $r$ .
- Fórmula: $S_{PMI}(f, r) = \log \frac{\hat{P}(r|f)}{\hat{P}(r)}$
- Isso identifica vulnerabilidades que são especificamente prováveis para uma funcionalidade, em vez de serem apenas comuns globalmente.
Seleção Diversificada: Um algoritmo ganancioso com penalidade de diversidade ( $\lambda$ ) seleciona as top- $k$ vulnerabilidades para cada funcionalidade, evitando que regras genéricas dominem a tabela.

B. O Ataque de Caixa-Preta (Fase de Inferência):

Reconhecimento: O atacante interage com a interface do usuário (UI) de um software gerado por um LLM desconhecido (ou conhecido) e identifica funcionalidades visíveis (ex: um botão de "Resetar Senha").
Consulta: O atacante consulta a tabela FSTab específica para aquele modelo de LLM.
Inferência: Com base nas funcionalidades observadas, o FSTab retorna uma lista priorizada de vulnerabilidades de backend prováveis, sem necessidade de acesso ao código-fonte.

3. Métricas de Avaliação

Para quantificar a persistência das vulnerabilidades, o paper introduz quatro métricas principais:

FVR (Feature Vulnerability Recurrence): Quão frequentemente uma mesma funcionalidade (ex: login) gera a mesma vulnerabilidade em diferentes programas.
RVP (Rephrasing Vulnerability Persistence): Se as vulnerabilidades persistem mesmo quando o prompt é reescrito semanticamente (mantendo o mesmo significado).
DVR (Domain Vulnerability Recurrence): Se as vulnerabilidades se repetem dentro do mesmo domínio de aplicação (ex: e-commerce).
CDT (Cross-Domain Transfer): Se um FSTab construído em um domínio (ex: blogs) consegue prever vulnerabilidades em outro domínio (ex: ferramentas internas).

4. Resultados Experimentais

O estudo avaliou 6 modelos de ponta (GPT-5.2, Claude-4.5 Opus, Gemini-3 Pro/Flash, Composer, Grok) em 5 domínios diferentes (E-commerce, Ferramentas Internas, Mídia Social, etc.).

Sucesso do Ataque (ASR - Attack Success Rate): O FSTab demonstrou alta eficácia. Em alguns casos, como no modelo Composer, atingiu 100% de taxa de sucesso na previsão de vulnerabilidades em domínios de e-commerce.
Transferência Cruzada (CDT): O resultado mais alarmante foi a alta transferência entre domínios. Mesmo quando o domínio alvo era excluído do treinamento do FSTab, a taxa de sucesso permaneceu alta (ex: até 94% para o Claude-4.5 Opus em Ferramentas Internas). Isso indica que as vulnerabilidades são inerentes ao modelo, não ao domínio.
Persistência de Reescrita (RVP): Modelos como o Composer e GPT-5.2 mostraram alta persistência (cerca de 50% das vulnerabilidades repetidas) mesmo com variações significativas no prompt, sugerindo viéses internos profundos e não apenas artefatos de prompts específicos.
Fingerprinting: Cada modelo possui um "perfil de vulnerabilidade" único. Por exemplo, o Grok mostrou viéses arquitetônicos fortes, enquanto o Gemini-3 Pro apresentou alta rigidez em certas operações de dados.

5. Contribuições Principais

Ataque Universal de Caixa-Preta: Demonstração de que é possível inferir vulnerabilidades de backend ocultas apenas observando o frontend, utilizando o FSTab.
Framework de Avaliação Modelo-Cêntrico: Introdução de métricas (FVR, RVP, DVR, CDT) para medir a estabilidade e persistência de falhas de segurança em modelos de geração de código.
Caracterização Empírica: Evidência robusta de que a geração de código por LLMs cria uma superfície de ataque previsível e repetitiva, onde falhas de segurança são "impressões digitais" do modelo.

6. Significado e Impacto

Risco de Segurança Sistêmico: O trabalho expõe que a segurança do software gerado por IA não é apenas um problema de "bugs aleatórios", mas de padrões de falha sistemáticos. Isso permite que atacantes realizem triagem de vulnerabilidades em escala massiva sem precisar analisar o código.
Mudança de Paradigma na Defesa: A defesa não pode depender apenas de varreduras estáticas pós-geração. É necessário avaliar a "segurança persistente" dos modelos durante o treinamento e a inferência.
Implicações para Desenvolvimento: Desenvolvedores e empresas devem tratar a identidade do modelo gerador como um fator de risco crítico. A existência de um "Fingerprint de Vulnerabilidade" sugere que mitigar esses riscos exigirá a redução da rigidez dos templates de geração e a introdução de objetivos de segurança condicionados às funcionalidades durante o processo de geração.

Em resumo, o paper alerta que a eficiência da geração de código por LLMs vem acompanhada de uma reprodutibilidade de falhas de segurança, criando um vetor de ataque novo e altamente eficiente que explora a própria natureza estatística dos modelos.