Shadows Security Scanner

Security Scanner — 7-Phase Audit Pipeline

Version: 1.1.0 | Author: Shadows Company | License: MIT

WHEN TO TRIGGER

WHEN NOT TO TRIGGER

PREREQUISITES

Required:

Optional (auto-detected for dependency scanning in Phase 2):

If no package manager is detected, Phase 2 is skipped with a note in the report.

PROTOCOL — 7 PHASES

Phase 1 — RECONNAISSANCE

Map the attack surface: 1. List all entry points (routes, APIs, webhooks, forms) 2. Identify data flows (user input -> storage -> output) 3. Map authentication and authorization boundaries 4. Identify external service integrations 5. Check for exposed ports and services

# Node.js — find all route definitions
grep -rn "app\.\(get\|post\|put\|delete\|patch\)" --include="*.js" --include="*.ts" -l
Python — find all route definitions
grep -rn "@app\.\(route\|get\|post\)" --include="*.py" -l

Phase 2 — DEPENDENCY SCAN

Check for known vulnerabilities in dependencies:

# Node.js — requires npm
npm audit --json 2>/dev/null || echo "npm audit not available — install npm or skip Phase 2"
Python — requires pip-audit (pip install pip-audit)
pip audit 2>/dev/null || echo "pip audit not available — install pip-audit or skip Phase 2"
Rust — requires cargo-audit (cargo install cargo-audit)
cargo audit 2>/dev/null || echo "cargo-audit not available — install cargo-audit or skip Phase 2"

For each vulnerability found:

> NOTE: npm audit and pip audit make network calls to vulnerability databases (registry.npmjs.org, pypi.org/pyup.io). These are read-only queries.

Phase 3 — APPLICATION SECURITY TESTS

Check OWASP Top 10:

1. Injection (SQL, NoSQL, OS, LDAP) - Search for string concatenation in queries - Verify parameterized queries are used

   grep -rn "f['\"].*SELECT\|f['\"].*INSERT\|f['\"].*UPDATE" --include="*.py"
   grep -rn "query.*\+\|exec.*\+" --include="*.js" --include="*.ts"
   

2. Broken Authentication - Check session management: grep -rn "session\|cookie\|jwt\|token" --include="*.py" --include="*.js" --include="*.ts" | grep -i "expir\|ttl\|maxage" - Verify MFA implementation if applicable

3. Sensitive Data Exposure - Search for hardcoded secrets:

   grep -rniE "(password|secret|api_key|token|private_key)\s*[:=]\s*['\"][^'\"]{8,}" --include="*.py" --include="*.js" --include="*.ts" --include="*.env"
   

4. XSS — Search for unsanitized user input in HTML output:

   grep -rn "innerHTML\|dangerouslySetInnerHTML\|v-html\|\|safe" --include="*.js" --include="*.ts" --include="*.jsx" --include="*.tsx" --include="*.html" --include="*.py"
   

   grep -rn "eval(\|pickle\.loads\|yaml\.load(" --include="*.py" --include="*.js" --include="*.ts"
   

Phase 4 — API SECURITY

For each API endpoint: 1. Authentication required? (JWT, API key, session) 2. Authorization enforced? (role checks, ownership validation) 3. Rate limiting configured? 4. Input validation present? (schema validation, type checking) 5. Response doesn't leak internal details? (stack traces, DB structure) 6. CORS properly configured?

Phase 5 — HARDENING CHECK

Verify infrastructure hardening.

HTTP Security Headers (only when user provides a target URL):

# Replace $TARGET_URL with the URL provided by the user
curl -sI "$TARGET_URL" | grep -iE "(strict-transport|content-security|x-frame|x-content-type)"

> IMPORTANT: Only run this check when user provides a target URL. Never make network requests to URLs not explicitly provided by the user.

Checklist:

Phase 6 — SECRETS VERIFICATION

# Check git history for leaked secrets (local operation, no network)
git log --all -p | grep -iE "(api[_-]?key|secret|token|password)\s*[:=]\s*['\"]" | head -20
Verify .gitignore covers sensitive files
cat .gitignore | grep -E "(\.env|secret|credential|\.pem|\.key)"

Verify:

Phase 7 — REPORT

Generate a structured security report using the OUTPUT FORMAT below.

LIMITATIONS

Grep-based scanning (Phases 3 and 6) uses pattern matching to detect common vulnerability signatures. This approach has inherent limitations:

False positives:

False negatives:

Recommendation: Complement grep-based scans with dedicated tools:

RULES

1. Never skip phases — even if project seems simple 2. Evidence-based — every finding must have file:line or command output 3. Severity accuracy — don't inflate or downplay risks 4. Actionable remediation — every finding must include HOW to fix 5. No false security — passing this scan doesn't mean 100% secure

SECURITY CONSIDERATIONS

OUTPUT FORMAT

# Security Audit Report
Date: [YYYY-MM-DD]
Scope: [project/module name]
Auditor: [agent name]
Executive Summary
Critical: [count] | High: [count] | Medium: [count] | Low: [count]
Overall Risk: [Critical/High/Medium/Low]
Findings
[CRITICAL/HIGH] Finding Title
Category: [OWASP category]
Location: [file:line]
Description: [what's wrong]
Impact: [what could happen]
Remediation: [how to fix]
Status: [Open/Fixed]
Dependency Vulnerabilities
| Package | Severity | CVE | Fix Version |
|---------|----------|-----|-------------|
| ...     | ...      | ... | ...         |
Hardening Status
| Check | Status |
|-------|--------|
| HSTS  | [PASS/FAIL] |
| CSP   | [PASS/FAIL] |
| ...   | ...    |
Recommendations (Priority Order)
1. [Most critical action]
2. [Second priority]
3. [Third priority]

Published by Shadows Company — "We work in the shadows to serve the Light."

Required:

Optional (auto-detected for dependency scanning in Phase 2):

If no package manager is detected, Phase 2 is skipped with a note in the report.

1. Never skip phases — even if project seems simple 2. Evidence-based — every finding must have file:line or command output 3. Severity accuracy — don't inflate or downplay risks 4. Actionable remediation — every finding must include HOW to fix 5. No false security — passing this scan doesn't mean 100% secure