Construindo seu Harness de Vulnerabilidades com IA, Parte 1

O problema: volume de achados maior do que a capacidade de triagem

Scanners de vulnerabilidade produzem achados mais rápido do que times de segurança conseguem analisar manualmente. À medida que os times de desenvolvimento entregam mais código com mais dependências, o volume de candidatos a vulnerabilidade só cresce. O desafio não é encontrar potenciais problemas — é separar o sinal do ruído na velocidade que o pipeline de entrega exige.

Para endereçar esse gap, a AWS publicou um guia técnico descrevendo um pipeline de três camadas que parte dos achados brutos de scanners e chega a um conjunto pequeno e priorizado, com evidências documentadas de exploitabilidade. Este é o primeiro post de uma série: o artigo complementar, Configurando seu harness de vulnerabilidades com IA, cobrirá o arquivo de direcionamento (steering file) que controla o comportamento do modelo dentro desse pipeline.

O que é um harness de testes

Um harness de testes é um framework automatizado que submete um sistema a entradas controladas e observa se as saídas correspondem ao comportamento esperado. Aplicado à detecção de vulnerabilidades, o harness recebe cada achado candidato, constrói um teste para avaliar a exploitabilidade, executa esse teste em ambiente controlado e registra as evidências.

É importante deixar claro: o harness é a infraestrutura de testes, não os resultados que ela produz.

Por que ferramentas tradicionais não são suficientes

Ferramentas tradicionais de Teste Estático de Segurança de Aplicações (SAST — Static Application Security Testing) funcionam por correspondência de padrões, com análise de fluxo de dados variando conforme a ferramenta e a linguagem. Elas identificam bem os sinks de formato conhecido, mas têm dificuldade com cadeias de múltiplos saltos, falhas de lógica de negócio, sanitização dependente de contexto e com determinar se um sink é alcançável a partir de uma entrada controlada pelo atacante.

A análise aumentada por IA preenche essa lacuna de raciocínio: rastreando entre arquivos, inferindo intenção e pesando o contexto de implantação. A distinção conceitual central é que o modelo não é executado contra a base de código — a base de código é contexto passado a um modelo com um prompt específico. O modelo recebe o código e aplica raciocínio sobre como os dados fluem, onde existem limites de confiança e se padrões relevantes de segurança estão presentes.

O escopo do contexto é uma das partes mais difíceis dessa arquitetura. Contexto demais pode sobrecarregar a janela de raciocínio do modelo; contexto de menos pode gerar lacunas de análise e falsos negativos. Para uma função AWS Lambda simples, o contexto relevante pode ser um único arquivo mais sua função do Gerenciamento de Identidade e Acesso da AWS (IAM). Para um microsserviço complexo com bibliotecas compartilhadas e infraestrutura em camadas, decidir o que incluir exige entender o grafo de dependências da aplicação.

O modelo pode raciocinar sobre a topologia de implantação se você fornecer esse contexto — por exemplo, passando constructs do Kit de Desenvolvimento em Nuvem da AWS (AWS CDK) ou templates do AWS CloudFormation como contexto adicional. Começar com escopo restrito e expandir apenas quando a avaliação inicial do modelo for inconclusiva tende a produzir resultados melhores do que passar tudo de uma vez.

Construindo o pipeline de três camadas

Scanners de segurança podem produzir grandes volumes de achados a cada execução. Muitos são falsos positivos — parecem vulnerabilidades, mas não são problemas reais. Para separar os problemas reais do ruído, o pipeline filtra os achados em três camadas. Cada camada aplica um tipo diferente de evidência. Ao final, resta um número menor de problemas priorizados e respaldados por evidências documentadas.

Camada 1: Concordância entre múltiplos scanners

A plausibilidade vem primeiro. A ideia é executar múltiplos scanners de forma independente contra a mesma base de código: quando dois ou mais convergem para o mesmo achado, a confiança aumenta. Quando apenas um scanner reporta um problema e nenhuma outra ferramenta concorda, o pipeline sinaliza esse achado para escrutínio extra.

Essa abordagem — chamada de concordância entre múltiplos scanners (multi-scanner agreement) — é uma forma de baixo custo de aumentar a confiança. Funciona com as ferramentas que você já usa e não requer nenhuma infraestrutura nova.

Camada 2: Verificação estrutural

A segunda camada verifica a estrutura. Scanners com IA descrevem como acreditam que uma vulnerabilidade funciona: os dados entram por uma função, passam por outra e chegam a um ponto onde podem causar dano. Porém, essas descrições podem estar erradas. Antes de um achado avançar, o pipeline o verifica contra o código real. Ele checa se a função mencionada pelo scanner existe, se o arquivo existe e se os dados podem fluir pelo caminho descrito. Caso contrário, o pipeline rejeita o achado.

Essa etapa de verificação usa a Árvore Sintática Abstrata (AST — Abstract Syntax Tree) do código: um mapa estruturado de como funções, arquivos e fluxos de dados se conectam na sua base de código.

Essa etapa protege a credibilidade do output do pipeline. Se achados não verificados chegam a revisores humanos, os times rapidamente aprendem a desconfiar dos resultados — o que reduz o valor de segurança da ferramenta.

Camada 3: Contexto de implantação

A camada final adiciona contexto de implantação. Vulnerabilidades existem dentro do contexto de uma arquitetura, que pode incluir controles de proteção — como regras do AWS WAF, isolamento de rede, requisitos de autenticação e validação de entrada. Essa camada lê seus templates de Infraestrutura como Código (IaC — Infrastructure as Code), como arquivos CloudFormation ou Terraform que definem sua arquitetura em nuvem, junto com o código-fonte da aplicação. Em seguida, verifica se um atacante consegue explorar a vulnerabilidade contornando os controles existentes.

Nem todos os controles oferecem o mesmo nível de proteção. Uma regra de firewall de aplicação web que bloqueia diretamente a técnica de ataque relevante oferece mitigação mais forte do que uma que trata um tipo diferente de vulnerabilidade. O pipeline trata a efetividade dos controles como um espectro, não como uma caixa de seleção de sim ou não.

O resultado: uma lista curta com alta confiança

O resultado é uma lista reduzida de achados. Cada um passou pelas três camadas: superou a verificação de plausibilidade, sua estrutura foi confirmada contra o código e seu contexto de implantação indica que pode ser explorado. O número de achados diminui a cada camada, e a confiança nos achados restantes aumenta.

Quatro princípios que emergiram da construção do pipeline

• Filtragem progressiva com evidências crescentes — Cada camada exige um tipo diferente de prova. A primeira verifica se o achado é plausível. A segunda determina se é estruturalmente real. A terceira analisa se é explorável no contexto. Usar três camadas focadas funciona melhor do que uma camada abrangente, porque cada uma captura um tipo diferente de erro.
• O contexto de infraestrutura transforma a priorização — Sem contexto de implantação, você pode assumir que um achado de severidade crítica é mais urgente do que um de severidade média. Porém, um achado crítico protegido por controles robustos pode ser menos urgente do que um achado médio diretamente exposto à internet. Para fazer essa avaliação, o pipeline precisa acessar seus templates de IaC, não apenas o código-fonte da aplicação.
• Concordância independente supera a confiança de uma única ferramenta — Nenhum scanner detecta de forma confiável toda a gama de vulnerabilidades. Nenhum modelo produz resultados corretos em todas as situações. Quando múltiplas ferramentas independentes concordam em um achado, essa concordância fornece um sinal mais forte do que o score de confiança auto-reportado de uma única ferramenta.
• Afirmações geradas por IA exigem verificação antes da revisão humana — Modelos de linguagem podem produzir outputs que soam plausíveis, mas podem não estar corretos. Verificar achados gerados por IA contra a estrutura real do código — antes que um humano os revise — é o que separa um sistema útil de um que corrói a confiança por meio de erros com aparência de certeza.

Como aplicar isso ao seu ambiente

Não é necessário construir tudo de uma vez. A recomendação é adotar as camadas na ordem de retorno imediato:

• Comece pela indexação — Construa (ou use) um índice baseado em AST da sua base de código que exponha pontos de entrada, sinks e configuração de autenticação. Isso não tem custo de execução e oferece um mapa da sua superfície de ataque antes de qualquer IA ser envolvida.
• Adicione triagem com múltiplos scanners — Pegue o output que você já obtém de ferramentas como Semgrep, CodeQL ou equivalentes, e passe-o pelo gate de AST mais uma classificação de exploitabilidade por um Modelo de Linguagem de Grande Escala (LLM — Large Language Model). Isso entrega redução substancial de ruído com investimento modesto.
• Adicione geração de hipóteses — Após a triagem estar estável, adicione descoberta orientada por IA de vulnerabilidades que os scanners perdem: cadeias de múltiplos saltos, falhas de lógica de negócio e fluxos de dados entre pacotes. Esta é a etapa onde a qualidade do direcionamento importa muito — veja o artigo Configurando seu harness de vulnerabilidades com IA.
• Adicione contexto de infraestrutura — Faça o parse do seu CDK ou CloudFormation, mapeie controles para classes de vulnerabilidade e aplique os multiplicadores. É aqui que sua priorização se torna mais precisa.
• Adicione verificação ao vivo — Execute provas de conceito (PoCs — Proofs of Concept) contra um alvo de pré-produção implantado com critérios estruturados de sucesso. Essa etapa exige mais overhead operacional, então execute-a por último e apenas para achados que já passaram pelo seu limiar de confiança.

Trate o pipeline como algo que você ajusta ao longo do tempo. Valide-o contra verdadeiros e falsos positivos conhecidos, ajuste os pesos e reexecute.

O que esse pipeline não resolve

O harness é infraestrutura de detecção. Ele ajuda a identificar quais achados são provavelmente reais e quais merecem atenção primeiro. Ele não:

• Corrige o código — Remediação é um problema separado. O harness produz achados com evidências suficientes para que um humano ou agente possa agir; o ato de remediar exige suas próprias ferramentas e processos.
• Substitui a revisão humana para ação final — Mesmo após três camadas de filtragem, o output é uma lista priorizada de achados provavelmente exploráveis, não exploits comprovados. Achados de Prioridade 0 (P0) ainda justificam revisão por um engenheiro antes de impulsionar mudanças no código.
• Captura classes de vulnerabilidade fora do perfil de detecção do conjunto de scanners — Se nenhum dos seus scanners procura por uma categoria específica de vulnerabilidade, o harness não a vai surfacear. A geração de hipóteses aumentada por IA fecha parte dessa lacuna, mas falhas novas ou de lógica de negócio ainda dependem do que o modelo consegue raciocinar a partir do código.
• Verifica o estado da infraestrutura ao vivo por padrão — Fazer o parse de IaC informa o que foi definido. Não informa se uma regra do WAF foi desabilitada na semana passada ou se um grupo de segurança foi modificado após a implantação. Verificação ao vivo é uma integração adicional, não uma propriedade das camadas em si.

Cada um desses limites aponta para onde a arquitetura se estende, não onde ela falha. O harness é o primeiro andar de um sistema de múltiplos andares, não o edifício inteiro.

O que vem a seguir

A arquitetura produz resultados consistentes quando o modelo recebe instruções consistentes. O artigo complementar, Configurando seu harness de vulnerabilidades com IA, cobre o arquivo de direcionamento que codifica essa metodologia como instruções executáveis por máquina — incluindo a fórmula de confiança, os multiplicadores de controle de infraestrutura e os gates de verificação que ajudam a evitar que achados alucinados cheguem aos seus engenheiros.

O mesmo modelo que produz avaliações rigorosas e baseadas em evidências com instruções bem elaboradas pode produzir classificações de severidade infladas e cadeias de ataque fabricadas sem essas instruções. A configuração é o que transforma capacidade em julgamento.

Para mais informações sobre os serviços mencionados neste post, consulte a documentação do AWS Lambda, do AWS WAF e do AWS CloudFormation.

Fonte

Building your AI vulnerability harness, Part 1 (https://aws.amazon.com/blogs/security/building-your-ai-vulnerability-harness-part-1/)