13 findings no Juice Shop. Nenhuma virou issue.

Eu quase cometi uma gafe constrangedora que muitos desenvolvedores e analistas iniciantes de segurança cometem: quase abri 13 issues no GitHub do famoso projeto OWASP Juice Shop.

A IA tinha trabalhado muito bem. Ela gerou um relatório lindo com 13 apontamentos cirúrgicos, mapeados para o padrão OWASP ASVS e com arquivo:linha exatos: SQL Injection no login, eval() no perfil de usuário, CORS aberto com * e até um IDOR clássico onde um usuário podia ver a cesta de compras de outro.

Eu já estava pronto para postar os relatórios no repositório quando bati o olho na descrição do projeto no package.json:

"Probably the most modern and sophisticated insecure web application".

Foi o momento do choque de realidade: aquilo não era um bug ou falha acidental. A vulnerabilidade é o próprio produto.

Neste artigo, vamos entender por que ambientes de laboratório (CTFs e labs deliberadamente inseguros) servem exclusivamente para calibrar seus sensores e prompts, e por que abrir issues em labs é o maior atestado de amadorismo técnico que existe.

1. Lab Deliberadamente Inseguro vs Código de Produção

Antes de rodar qualquer agente de segurança ou scanner, a regra fundamental de engenharia é identificar o propósito do repositório:

                     ┌─────────────────────────────────────────┐
                     │          Qual é o Alvo do Scan?         │
                     └────────────────────┬────────────────────┘
                                          │
                  ┌───────────────────────┴───────────────────────┐
                  ▼                                               ▼
     ┌─────────────────────────┐                     ┌─────────────────────────┐
     │   Laboratório de Treino │                     │  Software de Produção   │
     │ (Juice Shop, WebGoat)   │                     │ (Next.js, Cal.com, etc) │
     └────────────┬────────────┘                     └────────────┬────────────┘
                  │                                               │
     Propósito: Ensinar falhas                       Propósito: Resolver problema
     Vulnerabilidades: INTENCIONAIS                  Vulnerabilidades: ACIDENTAIS
                  │                                               │
                  ▼                                               ▼
     [ Ação: Calibrar prompts ]                      [ Ação: Responsible Disclosure ]
     (NUNCA abrir issue!)                            (Issue ou e-mail privado)

Matriz Comparativa: Não Confunda as Portas

Se o README.md diz "intentionally vulnerable" ou "hacking challenge", seu relatório não deve ir para a internet. Seu relatório deve ficar na sua máquina para testar se a IA é precisa.

2. A Radiografia dos 13 Achados no Juice Shop

Rodamos uma análise puramente estática com agentes de código, sem enviar requisições de rede (sem tráfego e sem exploração ativa).

O modelo local analisou 13 arquivos centrais de rotas e bibliotecas (routes/, lib/, data/) e gerou exatamente 13 apontamentos mapeados contra o padrão OWASP ASVS:

3. Para Que Serve um Lab: Medindo Precisão e Recall com Matriz de Confusão

Se você nunca deve abrir issues em labs, para que serve rodar agentes neles?

Para calibrar a sua esteira de engenharia antes de tocar em código corporativo.

Sem um denominador formal, dizer que um agente "acertou bastante" é apenas opinião. Em engenharia, precisamos da Matriz de Confusão:

                        ┌──────────────────────────────────────────────┐
                        │          Matriz de Confusão Medida           │
                        └──────────────────────┬───────────────────────┘
                                               │
                       ┌───────────────────────┴───────────────────────┐
                       ▼                                               ▼
         [ Vulnerabilidade Real ]                            [ Código Inofensivo ]
         (Challenges do Lab)                                 (Código Seguro/Mocks)
  ┌─────────────────────────────────────────┐     ┌─────────────────────────────────────────┐
  │ True Positives (TP): 10                 │     │ False Positives (FP): 3                 │
  │ Apontou e o desafio existia de fato     │     │ Apontou risco onde era mock ou proxy    │
  └─────────────────────────────────────────┘     └─────────────────────────────────────────┘
  ┌─────────────────────────────────────────┐     ┌─────────────────────────────────────────┐
  │ False Negatives (FN): 106               │     │ True Negatives (TN): N/A                │
  │ Desafios reais não vistos no estático   │     │ Linhas seguras não alertadas            │
  └─────────────────────────────────────────┘     └─────────────────────────────────────────┘

As Métricas Reais do Experimento:

• População Total de Desafios do Lab (Ground Truth): 116 vulnerabilidades catalogadas na documentação oficial do Juice Shop.
• Amostra Analisada: 13 arquivos centrais de código estático inspecionados pelo agente.
• Precisão (Precision): 10 / (10 + 3) = 76,9%. Quando o agente apontou um risco crítico de negócio, ele estava correto em mais de 3 a cada 4 vezes.
• Cobertura Global (Recall): 10 / 116 = 8,6%.

[!NOTE]
Por que um Recall de 8,6% é um dado excelente e libertador?
Porque leitura puramente estática de código só enxerga o que está escrito no arquivo. Ela é completamente cega para falhas de lógica em runtime, ataques de timing, desserialização dinâmica ou encadeamento complexo de pacotes. Isso prova numericamente que nenhum agente de IA estático substitui sensores dinâmicos (DAST, fuzzing e testes end-to-end).

4. Eficiência de Custo: Classificação Local com Downshift

Fazer varreduras completas em bases inteiras de código usando exclusivamente modelos de nuvem de raciocínio profundo consome tokens muito rápido.

A recomendação para times maduros é utilizar um classificador local em Go como o Downshift (harness-downshift):

• O classificador analisa a complexidade e a extensão dos arquivos localmente na sua máquina;
• Funções simples e arquivos de configuração passam por linters estáticos locais;
• Apenas trechos que envolvem regras de autenticação, criptografia ou autorização complexa são enviados para modelos de raciocínio avançado via OpenRouter.

Referências Técnicas Canônicas

Para explorar laboratórios de segurança e entender como treinar seus conhecimentos de forma ética:

• 📖 Guia Canônico Oficial: Pwning OWASP Juice Shop Official Companion Guide - A documentação de referência que detalha a arquitetura intencional e as categorias de vulnerabilidade do projeto.
• 📖 Checklist de Verificação: OWASP ASVS 5.0 (Application Security Verification Standard) - O checklist padrão ouro de requisitos de segurança para arquitetura e código.
• 📖 Metodologia de Teste: OWASP Web Security Testing Guide (WSTG v4.2) - Procedimentos estruturados para auditoria estática e dinâmica de aplicações web.

Resumo em Uma Frase

Use laboratórios como o Juice Shop para afiar a sua espada e testar a precisão dos seus agentes de IA; mas guarde a lâmina na bainha quando estiver diante do placar de desafios de outros desenvolvedores.

A maturidade de um engenheiro de software não se mede pela quantidade de issues que ele abre, mas pela capacidade de discernir onde cada achado tem valor de verdade.