Vulnerability Scanner
Think like an attacker, defend like an expert. 2025 threat landscape awareness.
🔧 Runtime Scripts
Optional heuristic scan (not security validation):
| Script | Purpose | Usage | |
|---|
scripts/security_scan.py | Validate security principles applied | python scripts/security_scan.py <project_path> | |
📋 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 | Predicted exploitation probability | Probability of exploitation in the next 30 days, not proof of active exploitation | |
| Asset Value | Business context | What's at risk? | |
| Exposure | Attack surface | Internet-facing? | |
Prioritization Decision Tree
Is there credible active-exploitation evidence (for example a relevant KEV entry or incident evidence)?
├── 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() | <!-- security-allowlist: defensive vulnerability taxonomy --> |
| 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?"
When to Use
This skill is applicable to execute the workflow or actions described in the overview.
Limitations
- The bundled scanner uses regex heuristics, not dataflow/reachability analysis; matches require manual validation and absence of matches is not a security verdict. It omits Git history, binaries and skipped directories. Network dependency audit is opt-in with
--allow-network and sends dependency metadata to the configured registry. Read/tool errors mean incomplete coverage; do not treat them as a pass. - Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.