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
# 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 |
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:
- What are we protecting? (Assets)
- Who would attack? (Threat actors)
- How would they attack? (Attack vectors)
- 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:
- What? - Clear vulnerability description
- Where? - Exact location (file, line, endpoint)
- Why? - Root cause explanation
- Impact? - Business consequence
- 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?"
1---2name: vulnerability-scanner3description: Vulnerability Scanner4---5# Vulnerability Scanner67Advanced vulnerability analysis for OWASP 2025, supply chain security, attack surface mapping, and risk prioritization.89## Description1011USE WHEN:12- Auditing code for security vulnerabilities13- Reviewing dependencies for supply chain risks 14- Scanning for hardcoded secrets or credentials15- Identifying dangerous code patterns (injection, XSS, deserialization)16- Preparing for security audits or penetration tests17- Prioritizing vulnerability remediation by risk1819DON'T USE WHEN:20- Need runtime dynamic analysis (use actual pentest tools)21- Scanning compiled binaries (this is source-code focused)22- Need compliance-specific audits (PCI-DSS, HIPAA have dedicated tools)2324## Scripts2526| Script | Purpose | Usage |27|--------|---------|-------|28| `scripts/security_scan.py` | Full security scan | `python scripts/security_scan.py <path> [--scan-type all\|deps\|secrets\|patterns\|config]` |2930### Quick Start3132```bash33# Full scan34python scripts/security_scan.py /path/to/project3536# Just check for secrets37python scripts/security_scan.py /path/to/project --scan-type secrets3839# Summary output40python scripts/security_scan.py /path/to/project --output summary41```4243## Reference Files4445| File | Purpose |46|------|---------|47| [checklists.md](checklists.md) | OWASP Top 10, Auth, API, Data protection checklists |4849---5051## 1. Security Expert Mindset5253### Core Principles5455| Principle | Application |56|-----------|-------------|57| **Assume Breach** | Design as if attacker already inside |58| **Zero Trust** | Never trust, always verify |59| **Defense in Depth** | Multiple layers, no single point |60| **Least Privilege** | Minimum required access only |61| **Fail Secure** | On error, deny access |6263### Threat Modeling Questions6465Before scanning, ask:661. What are we protecting? (Assets)672. Who would attack? (Threat actors)683. How would they attack? (Attack vectors)694. What's the impact? (Business risk)7071---7273## 2. OWASP Top 10:20257475### Risk Categories7677| Rank | Category | Think About |78|------|----------|-------------|79| **A01** | Broken Access Control | Who can access what? IDOR, SSRF |80| **A02** | Security Misconfiguration | Defaults, headers, exposed services |81| **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, build integrity |82| **A04** | Cryptographic Failures | Weak crypto, exposed secrets |83| **A05** | Injection | User input → system commands |84| **A06** | Insecure Design | Flawed architecture |85| **A07** | Authentication Failures | Session, credential management |86| **A08** | Integrity Failures | Unsigned updates, tampered data |87| **A09** | Logging & Alerting | Blind spots, no monitoring |88| **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states |8990### 2025 Key Changes9192```932021 → 2025 Shifts:94├── SSRF merged into A01 (Access Control)95├── A02 elevated (Cloud/Container configs)96├── A03 NEW: Supply Chain (major focus)97├── A10 NEW: Exceptional Conditions98└── Focus shift: Root causes > Symptoms99```100101---102103## 3. Supply Chain Security (A03)104105### Attack Surface106107| Vector | Risk | Question to Ask |108|--------|------|-----------------|109| **Dependencies** | Malicious packages | Do we audit new deps? |110| **Lock files** | Integrity attacks | Are they committed? |111| **Build pipeline** | CI/CD compromise | Who can modify? |112| **Registry** | Typosquatting | Verified sources? |113114### Defense Principles115116- Verify package integrity (checksums)117- Pin versions, audit updates118- Use private registries for critical deps119- Sign and verify artifacts120121---122123## 4. Attack Surface Mapping124125### What to Map126127| Category | Elements |128|----------|----------|129| **Entry Points** | APIs, forms, file uploads |130| **Data Flows** | Input → Process → Output |131| **Trust Boundaries** | Where auth/authz checked |132| **Assets** | Secrets, PII, business data |133134### Prioritization Matrix135136```137Risk = Likelihood × Impact138139High Impact + High Likelihood → CRITICAL140High Impact + Low Likelihood → HIGH141Low Impact + High Likelihood → MEDIUM142Low Impact + Low Likelihood → LOW143```144145---146147## 5. Risk Prioritization148149### CVSS + Context150151| Factor | Weight | Question |152|--------|--------|----------|153| **CVSS Score** | Base severity | How severe is the vuln? |154| **EPSS Score** | Exploit likelihood | Is it being exploited? |155| **Asset Value** | Business context | What's at risk? |156| **Exposure** | Attack surface | Internet-facing? |157158### Prioritization Decision Tree159160```161Is it actively exploited (EPSS >0.5)?162├── YES → CRITICAL: Immediate action163└── NO → Check CVSS164 ├── CVSS ≥9.0 → HIGH165 ├── CVSS 7.0-8.9 → Consider asset value166 └── CVSS <7.0 → Schedule for later167```168169---170171## 6. Exceptional Conditions (A10 - New)172173### Fail-Open vs Fail-Closed174175| Scenario | Fail-Open (BAD) | Fail-Closed (GOOD) |176|----------|-----------------|---------------------|177| Auth error | Allow access | Deny access |178| Parsing fails | Accept input | Reject input |179| Timeout | Retry forever | Limit + abort |180181### What to Check182183- Exception handlers that catch-all and ignore184- Missing error handling on security operations185- Race conditions in auth/authz186- Resource exhaustion scenarios187188---189190## 7. Scanning Methodology191192### Phase-Based Approach193194```1951. RECONNAISSANCE196 └── Understand the target197 ├── Technology stack198 ├── Entry points199 └── Data flows2002012. DISCOVERY202 └── Identify potential issues203 ├── Configuration review204 ├── Dependency analysis205 └── Code pattern search2062073. ANALYSIS208 └── Validate and prioritize209 ├── False positive elimination210 ├── Risk scoring211 └── Attack chain mapping2122134. REPORTING214 └── Actionable findings215 ├── Clear reproduction steps216 ├── Business impact217 └── Remediation guidance218```219220---221222## 8. Code Pattern Analysis223224### High-Risk Patterns225226| Pattern | Risk | Look For |227|---------|------|----------|228| **String concat in queries** | Injection | `"SELECT * FROM " + user_input` |229| **Dynamic code execution** | RCE | `eval()`, `exec()`, `Function()` |230| **Unsafe deserialization** | RCE | `pickle.loads()`, `unserialize()` |231| **Path manipulation** | Traversal | User input in file paths |232| **Disabled security** | Various | `verify=False`, `--insecure` |233234### Secret Patterns235236| Type | Indicators |237|------|-----------|238| API Keys | `api_key`, `apikey`, high entropy |239| Tokens | `token`, `bearer`, `jwt` |240| Credentials | `password`, `secret`, `key` |241| Cloud | `AWS_`, `AZURE_`, `GCP_` prefixes |242243---244245## 9. Cloud Security Considerations246247### Shared Responsibility248249| Layer | You Own | Provider Owns |250|-------|---------|---------------|251| Data | ✅ | ❌ |252| Application | ✅ | ❌ |253| OS/Runtime | Depends | Depends |254| Infrastructure | ❌ | ✅ |255256### Cloud-Specific Checks257258- IAM: Least privilege applied?259- Storage: Public buckets?260- Network: Security groups tightened?261- Secrets: Using secrets manager?262263---264265## 10. Anti-Patterns266267| ❌ Don't | ✅ Do |268|----------|-------|269| Scan without understanding | Map attack surface first |270| Alert on every CVE | Prioritize by exploitability + asset |271| Ignore false positives | Maintain verified baseline |272| Fix symptoms only | Address root causes |273| Scan once before deploy | Continuous scanning |274| Trust third-party deps blindly | Verify integrity, audit code |275276---277278## 11. Reporting Principles279280### Finding Structure281282Each finding should answer:2831. **What?** - Clear vulnerability description2842. **Where?** - Exact location (file, line, endpoint)2853. **Why?** - Root cause explanation2864. **Impact?** - Business consequence2875. **How to fix?** - Specific remediation288289### Severity Classification290291| Severity | Criteria |292|----------|----------|293| **Critical** | RCE, auth bypass, mass data exposure |294| **High** | Data exposure, privilege escalation |295| **Medium** | Limited scope, requires conditions |296| **Low** | Informational, best practice |297298---299300> **Remember:** Vulnerability scanning finds issues. Expert thinking prioritizes what matters. Always ask: "What would an attacker do with this?"