<critical_rules>
NEVER scan these directories - they are infrastructure, not application code:
- .claude/ - SecureVibes testing infrastructure
- env/, venv/, .venv/ - Python virtual environments  
- node_modules/ - Node.js dependencies
- .git/ - Version control
- __pycache__/, .pytest_cache/ - Python cache
- dist/, build/, .eggs/ - Build artifacts

When using Grep, Glob, LS, or Read tools:
1. ALWAYS check file paths BEFORE reading
2. SKIP any file in the directories above
3. Focus ONLY on application source code

Example good paths to scan:
✅ ./app.py
✅ ./src/routes.py
✅ ./lib/utils.js
✅ ./models/user.py

Example bad paths to SKIP:
❌ ./env/lib/python3.13/site-packages/flask/app.py
❌ ./.claude/skills/dast/authorization-testing/reference/validate_idor.py
❌ ./node_modules/express/lib/router.js
❌ ./.venv/lib/site-packages/requests/api.py

If Grep returns results in infrastructure directories, IGNORE them completely.
</critical_rules>

<false_positive_prevention>
CRITICAL: Apply these checks to reduce false positives and improve finding quality.

1. TRUST BOUNDARY ANALYSIS - Trace data origins before flagging injection:
   - UNTRUSTED: User input, HTTP requests, webhooks, file uploads, external APIs
   - SEMI-TRUSTED: Authenticated user input, database values from user submissions
   - TRUSTED: Admin configuration files, code constants, environment variables set by operators
   - SYSTEM: Internal function calls, hardcoded values, compile-time constants
   
   RULE: Flag injection/tampering when attacker-influenced data reaches sensitive sinks.
   If data originates from operator-only static config and cannot be attacker-modified at runtime, treat as lower risk.
   IMPORTANT EXCEPTION FOR PR REVIEW: if changed code routes user-modifiable config/preferences/env values into
   command argv, shell bodies, network targets, or auth decisions, treat it as an exploitable vulnerability chain.
   
   Example - Flag this (user input → template):
     userInput = request.body.template
     render(userInput)  // VULNERABLE - untrusted source
   
   Example - Don't flag as HIGH (admin config → template):
     adminConfig = loadConfig("mappings.yaml")  // Trusted source
     render(adminConfig.template)  // Security consideration, not injection vulnerability

2. AUTHENTICATION PREREQUISITE ANALYSIS - Factor in attack prerequisites:
   - Does exploiting this require prior authentication?
   - Does it require admin/privileged access?
   - Does it require local system access?
   - Does it require specific network position (localhost, same LAN)?
   
   SEVERITY ADJUSTMENT RULES:
   - Unauthenticated remote → severity as-is
   - Requires authentication → reduce severity by one level (unless auth bypass)
   - Requires admin access → reduce to LOW or MEDIUM (admins can already do damage)
   - Requires local access → usually reduce severity, unless changed code creates direct command/option injection,
     credential exfiltration, or privileged execution pivots.
   
   Example - Don't flag as HIGH:
     "IDOR allows accessing other users' sessions" 
     BUT requires valid gateway authentication first
     → Should be MEDIUM (auth is a prerequisite)

3. INTENTIONAL DESIGN vs MISCONFIGURATION:
   - Configuration CAPABILITY is not a vulnerability (e.g., "config allows wildcard")
   - Default-OFF dangerous features are security considerations, not vulnerabilities
   - Explicit opt-in features with clear documentation are by-design
   
   RULE: If a feature requires explicit admin action to enable:
   - It's a "security consideration" or "hardening opportunity"
   - Severity should be LOW or INFO unless default is dangerous
   
   Example - Don't flag as CRITICAL:
     "Wildcard '*' in allowFrom grants elevated access to everyone"
     IF: User must explicitly set allowFrom: ["*"] in config
     → This is intentional power-user config, not a vulnerability

4. CLOSED-SET vs OPEN-INPUT VALIDATION:
   - If input is validated against a known enumeration, bypass is unlikely
   - Case normalization issues only matter if attacker controls the enumeration
   
   Example - Theoretical, not practical:
     "Tool policy bypass via case normalization"
     BUT: Tool names come from a fixed SDK enumeration, not user input
     → Should be LOW or omitted (attacker can't inject new tool names)

5. DEPLOYMENT CONTEXT AWARENESS:
   - Personal/developer tools have different threat models than enterprise SaaS
   - Rate limiting matters more for public-facing services
   - Local-only services have reduced attack surface
   
   When in doubt, note the deployment context in the threat description.
</false_positive_prevention>
