SlipItIn/.github/skills/security-specialist/steering/validation.md

Steering: Validate a Finding

Determine se um finding reportado é real e explorável. Produza um verdict: confirmed, rejected, ou needs-more-info.

Princípio: Validação Adversarial

O agente que valida NUNCA deve ser o agente que encontrou o finding. Hunting agents são biased para encontrar coisas; validation agents são biased para matar false positives. Este step adversarial é crítico.

---

Step 1: Load Finding Details

python3 scripts/scan_db.py show --finding-id <id>

Extraia:

• Tipo de vulnerabilidade claimed (CWE)
• Location (file, line, function, ou endpoint)
• Source do report (qual scanner, ou manual)
• Evidência ou PoC existente
• Trace claimed (se disponível)

Step 2: Read the Code at the Finding Location

Abra o file. Leia a function. Entenda o que faz. Não confie no snippet do scanner — scanners truncam contexto e perdem surrounding logic.

Perguntas:

• O pattern que o scanner flagged realmente existe aqui?
• É dead code? (unreachable, commented out, behind permanent feature flag)
• Foi refatorado desde o scan? (cheque git log)
• Se o código não bate com o report → provável false positive de resultados stale.

Step 3: Testes de Validação (5 Gates)

Aplique todos os testes abaixo. O finding deve sobreviver cada um:

3a. Exploitation Test

Leia o código real em cada step do trace. O data flow funciona como claimed?

• Pode construir o exact input (HTTP request, CLI invocation, API call, crafted file) que triggera isto?
• O input realmente alcança o sink sem ser blocked/transformed/validated no caminho?

3b. Impact Test

O que o atacante realmente ganha?

• Se a resposta é "aprende field names" ou "causa um error" → LOW máximo
• Se não pode descrever dano concreto em 2 frases → severity provavelmente está inflada

3c. Baseline Test

O comparável identificado em Phase 1 tem o mesmo pattern?

• Se sim e já foi explorado → finding MAIS FORTE, não mais fraco
• Se sim e nunca explorado em anos de produção → entenda por quê antes de reportar
• Se não tem comparável ou comparável não tem o pattern → proceda normalmente

3d. Mitigation Test

Existe outra layer que previne exploitation?

• WAF rules
• Middleware de input validation upstream
• Framework defaults (auto-escape, parameterized queries, CSRF tokens)
• Database constraints
• Network isolation
• Rate limiting

Mitigações não tornam false positive — reduzem severity. Note mas ainda confirme o flaw subjacente.

3e. Parser/Runtime Behavior Test

Se o exploit depende de como parser/runtime handles input específico:

• Verifique contra a spec ou implementação REAL
• NÃO assuma behavior de intuição
• Cite a spec ou teste dinamicamente
• Os false positives mais convincentes vêm de reasoning "o parser vai interpretar isso como..." sem verificar

Step 4: Trace the Data Flow

Identify the Source

• HTTP request parameters (query, body, headers, cookies)
• File uploads
• Database records (se populated por user input elsewhere)
• Message queues / event payloads

Trace Through Transformations

• Validado? (type check, regex, allowlist)
• Sanitizado? (HTML encoding, SQL escaping, shell quoting)
• Transformado em safe type? (parsed as integer, resolved as enum)
• Passa por framework-level protection? (ORM parameterization, template auto-escape)

Document the Chain

Source: req.query.search (user-controlled, string, sem length limit)
  → passed to: buildQuery(search) em db/queries.js:45
  → buildQuery concatena em SQL string (SEM parameterization)
  → executed via: db.raw(query) em db/queries.js:52
Sink: raw SQL execution
Mitigations: nenhuma encontrada
Verdict: CONFIRMED — SQL injection clássica

Step 5: Attempt Proof-of-Concept

Se pode demonstrar exploitation safety sem causar dano:

Para injection flaws: Construa payload que produz observable side effect. Para auth bypasses: Mostre o request que alcança protected resources sem credentials válidos. Para path traversal: Mostre o path que resolve fora do diretório intended.

Quando Dynamic Testing Não É Viável

• Rely em static trace: source → transforms → sink
• State: "Static analysis only — no dynamic confirmation"
• Note o que seria necessário para confirmar dinamicamente
• Ainda válido para confirmed se static trace é unambíguo

Step 6: Render Verdict

Verdict	Critérios
confirmed	Data attacker-controlled alcança dangerous sink com proteção insuficiente. Exploit path claro. Todos 5 gates passed.
rejected	Pattern não existe, código unreachable, ou mitigações previnem completamente exploitation. Evidência concreta de por quê.
needs-more-info	Não pode determinar. Especifique exatamente o que está faltando.

Step 7: Record

python3 scripts/scan_db.py validate \
  --finding-id <id> \
  --verdict <confirmed|rejected|needs-more-info> \
  --evidence "source: req.query.q → sink: db.raw() em queries.js:52, sem parameterization" \
  --poc "GET /api/search?q=' OR 1=1--" \
  --notes "Static trace only, no dynamic confirmation"

Princípios

• Finding sem traceable data flow não é confirmed — é hipótese.
• Scanners reportam patterns, não exploits. Seu job é determinar se o pattern é explorável em contexto.
• "Rejected" é fine. Documente por quê e siga em frente.
• "Needs-more-info" é honesto. Melhor que adivinhar.
• Mitigações reduzem risco mas não eliminam findings. SQLi behind WAF ainda é SQLi.
• Kill false positives agressivamente, mas não mate findings reais. Report curto com 3 findings reais vale mais que report longo com 30 teóricos.