Skill: brandonwise/vulnerability-scanner (version 1.0.0)

# Vulnerability Scanner Advanced vulnerability analysis for OWASP 2025, supply chain security, attack surface mapping, and risk prioritization. ## Description USE WHEN: - Auditing code for security vulnerabilities - Reviewing dependencies for supply chain risks - Scanning for hardcoded secrets or credentials - Identifying dangerous code patterns (injection, XSS, deserialization) - Preparing for security audits or penetration tests - Prioritizing vulnerability remediation by risk DON'T USE WHEN: - Need runtime dynamic analysis (use actual pentest tools) - Scanning compiled binaries (this is source-code focused) - Need compliance-specific audits (PCI-DSS, HIPAA have dedicated tools) ## Scripts | Script | Purpose | Usage | |--------|---------|-------| | `scripts/security_scan.py` | Full security scan | `python scripts/security_scan.py <path> [--scan-type all\|deps\|secrets\|patterns\|config]` | ### Quick Start ```bash # Full scan python scripts/security_scan.py /path/to/project # Just check for secrets python scripts/security_scan.py /path/to/project --scan-type secrets # Summary output python scripts/security_scan.py /path/to/project --output summary ``` ## Reference Files | File | Purpose | |------|---------| | [checklists.md](checklists.md) | OWASP Top 10, Auth, API, Data protection checklists | --- ## 1. Security Expert Mindset ### Core Principles | Principle | Application | |-----------|-------------| | **Assume Breach** | Design as if attacker already inside | | **Zero Trust** | Never trust, always verify | | **Defense in Depth** | Multiple layers, no single point | | **Least Privilege** | Minimum required access only | | **Fail Secure** | On error, deny access | ### Threat Modeling Questions Before scanning, ask: 1. What are we protecting? (Assets) 2. Who would attack? (Threat actors) 3. How would they attack? (Attack vectors) 4. What's the impact? (Business risk) --- ## 2. OWASP Top 10:2025 ### Risk Categories | Rank | Category | Think About | |------|----------|-------------| | **A01** | Broken Access Control | Who can access what? IDOR, SSRF | | **A02** | Security Misconfiguration | Defaults, headers, exposed services | | **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, build integrity | | **A04** | Cryptographic Failures | Weak crypto, exposed secrets | | **A05** | Injection | User input → system commands | | **A06** | Insecure Design | Flawed architecture | | **A07** | Authentication Failures | Session, credential management | | **A08** | Integrity Failures | Unsigned updates, tampered data | | **A09** | Logging & Alerting | Blind spots, no monitoring | | **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states | ### 2025 Key Changes ``` 2021 → 2025 Shifts: ├── SSRF merged into A01 (Access Control) ├── A02 elevated (Cloud/Container configs) ├── A03 NEW: Supply Chain (major focus) ├── A10 NEW: Exceptional Conditions └── Focus shift: Root causes > Symptoms ``` --- ## 3. Supply Chain Security (A03) ### Attack Surface | Vector | Risk | Question to Ask | |--------|------|-----------------| | **Dependencies** | Malicious packages | Do we audit new deps? | | **Lock files** | Integrity attacks | Are they committed? | | **Build pipeline** | CI/CD compromise | Who can modify? | | **Registry** | Typosquatting | Verified sources? | ### Defense Principles - Verify package integrity (checksums) - Pin versions, audit updates - Use private registries for critical deps - Sign and verify artifacts --- ## 4. Attack Surface Mapping ### What to Map | Category | Elements | |----------|----------| | **Entry Points** | APIs, forms, file uploads | | **Data Flows** | Input → Process → Output | | **Trust Boundaries** | Where auth/authz checked | | **Assets** | Secrets, PII, business data | ### Prioritization Matrix ``` Risk = Likelihood × Impact High Impact + High Likelihood → CRITICAL High Impact + Low Likelihood → HIGH Low Impact + High Likelihood → MEDIUM Low Impact + Low Likelihood → LOW ``` --- ## 5. Risk Prioritization ### CVSS + Context | Factor | Weight | Question | |--------|--------|----------| | **CVSS Score** | Base severity | How severe is the vuln? | | **EPSS Score** | Exploit likelihood | Is it being exploited? | | **Asset Value** | Business context | What's at risk? | | **Exposure** | Attack surface | Internet-facing? | ### Prioritization Decision Tree ``` Is it actively exploited (EPSS >0.5)? ├── YES → CRITICAL: Immediate action └── NO → Check CVSS ├── CVSS ≥9.0 → HIGH ├── CVSS 7.0-8.9 → Consider asset value └── CVSS <7.0 → Schedule for later ``` --- ## 6. Exceptional Conditions (A10 - New) ### Fail-Open vs Fail-Closed | Scenario | Fail-Open (BAD) | Fail-Closed (GOOD) | |----------|-----------------|---------------------| | Auth error | Allow access | Deny access | | Parsing fails | Accept input | Reject input | | Timeout | Retry forever | Limit + abort | ### What to Check - Exception handlers that catch-all and ignore - Missing error handling on security operations - Race conditions in auth/authz - Resource exhaustion scenarios --- ## 7. Scanning Methodology ### Phase-Based Approach ``` 1. RECONNAISSANCE └── Understand the target ├── Technology stack ├── Entry points └── Data flows 2. DISCOVERY └── Identify potential issues ├── Configuration review ├── Dependency analysis └── Code pattern search 3. ANALYSIS └── Validate and prioritize ├── False positive elimination ├── Risk scoring └── Attack chain mapping 4. REPORTING └── Actionable findings ├── Clear reproduction steps ├── Business impact └── Remediation guidance ``` --- ## 8. Code Pattern Analysis ### High-Risk Patterns | Pattern | Risk | Look For | |---------|------|----------| | **String concat in queries** | Injection | `"SELECT * FROM " + user_input` | | **Dynamic code execution** | RCE | `eval()`, `exec()`, `Function()` | | **Unsafe deserialization** | RCE | `pickle.loads()`, `unserialize()` | | **Path manipulation** | Traversal | User input in file paths | | **Disabled security** | Various | `verify=False`, `--insecure` | ### Secret Patterns | Type | Indicators | |------|-----------| | API Keys | `api_key`, `apikey`, high entropy | | Tokens | `token`, `bearer`, `jwt` | | Credentials | `password`, `secret`, `key` | | Cloud | `AWS_`, `AZURE_`, `GCP_` prefixes | --- ## 9. Cloud Security Considerations ### Shared Responsibility | Layer | You Own | Provider Owns | |-------|---------|---------------| | Data | ✅ | ❌ | | Application | ✅ | ❌ | | OS/Runtime | Depends | Depends | | Infrastructure | ❌ | ✅ | ### Cloud-Specific Checks - IAM: Least privilege applied? - Storage: Public buckets? - Network: Security groups tightened? - Secrets: Using secrets manager? --- ## 10. Anti-Patterns | ❌ Don't | ✅ Do | |----------|-------| | Scan without understanding | Map attack surface first | | Alert on every CVE | Prioritize by exploitability + asset | | Ignore false positives | Maintain verified baseline | | Fix symptoms only | Address root causes | | Scan once before deploy | Continuous scanning | | Trust third-party deps blindly | Verify integrity, audit code | --- ## 11. Reporting Principles ### Finding Structure Each finding should answer: 1. **What?** - Clear vulnerability description 2. **Where?** - Exact location (file, line, endpoint) 3. **Why?** - Root cause explanation 4. **Impact?** - Business consequence 5. **How to fix?** - Specific remediation ### Severity Classification | Severity | Criteria | |----------|----------| | **Critical** | RCE, auth bypass, mass data exposure | | **High** | Data exposure, privilege escalation | | **Medium** | Limited scope, requires conditions | | **Low** | Informational, best practice | --- > **Remember:** Vulnerability scanning finds issues. Expert thinking prioritizes what matters. Always ask: "What would an attacker do with this?"


Security scan verdicts — ClawScan: clean | static analysis: suspicious | VirusTotal: clean | SkillSpector: clean (LOW)