vulnerability-scanner
starsforks
How to install vulnerability-scanner?
one-man-company/skills-contextmanager/vulnerability-scanner
$npx -y skills add One-Man-Company/Skills-ContextManager --skill vulnerability-scannerAdvanced vulnerability analysis principles. OWASP 2025, Supply Chain Security, attack surface mapping, risk prioritization.
SKILL.md
| 1 | # Vulnerability Scanner |
| 2 | |
| 3 | > Think like an attacker, defend like an expert. 2025 threat landscape awareness. |
| 4 | |
| 5 | ## 🔧 Runtime Scripts |
| 6 | |
| 7 | **Execute for automated validation:** |
| 8 | |
| 9 | | Script | Purpose | Usage | |
| 10 | |--------|---------|-------| |
| 11 | | `scripts/security_scan.py` | Validate security principles applied | `python scripts/security_scan.py <project_path>` | |
| 12 | |
| 13 | ## 📋 Reference Files |
| 14 | |
| 15 | | File | Purpose | |
| 16 | |------|---------| |
| 17 | | [checklists.md](checklists.md) | OWASP Top 10, Auth, API, Data protection checklists | |
| 18 | |
| 19 | --- |
| 20 | |
| 21 | ## 1. Security Expert Mindset |
| 22 | |
| 23 | ### Core Principles |
| 24 | |
| 25 | | Principle | Application | |
| 26 | |-----------|-------------| |
| 27 | | **Assume Breach** | Design as if attacker already inside | |
| 28 | | **Zero Trust** | Never trust, always verify | |
| 29 | | **Defense in Depth** | Multiple layers, no single point | |
| 30 | | **Least Privilege** | Minimum required access only | |
| 31 | | **Fail Secure** | On error, deny access | |
| 32 | |
| 33 | ### Threat Modeling Questions |
| 34 | |
| 35 | Before scanning, ask: |
| 36 | 1. What are we protecting? (Assets) |
| 37 | 2. Who would attack? (Threat actors) |
| 38 | 3. How would they attack? (Attack vectors) |
| 39 | 4. What's the impact? (Business risk) |
| 40 | |
| 41 | --- |
| 42 | |
| 43 | ## 2. OWASP Top 10:2025 |
| 44 | |
| 45 | ### Risk Categories |
| 46 | |
| 47 | | Rank | Category | Think About | |
| 48 | |------|----------|-------------| |
| 49 | | **A01** | Broken Access Control | Who can access what? IDOR, SSRF | |
| 50 | | **A02** | Security Misconfiguration | Defaults, headers, exposed services | |
| 51 | | **A03** | Software Supply Chain 🆕 | Dependencies, CI/CD, build integrity | |
| 52 | | **A04** | Cryptographic Failures | Weak crypto, exposed secrets | |
| 53 | | **A05** | Injection | User input → system commands | |
| 54 | | **A06** | Insecure Design | Flawed architecture | |
| 55 | | **A07** | Authentication Failures | Session, credential management | |
| 56 | | **A08** | Integrity Failures | Unsigned updates, tampered data | |
| 57 | | **A09** | Logging & Alerting | Blind spots, no monitoring | |
| 58 | | **A10** | Exceptional Conditions 🆕 | Error handling, fail-open states | |
| 59 | |
| 60 | ### 2025 Key Changes |
| 61 | |
| 62 | ``` |
| 63 | 2021 → 2025 Shifts: |
| 64 | ├── SSRF merged into A01 (Access Control) |
| 65 | ├── A02 elevated (Cloud/Container configs) |
| 66 | ├── A03 NEW: Supply Chain (major focus) |
| 67 | ├── A10 NEW: Exceptional Conditions |
| 68 | └── Focus shift: Root causes > Symptoms |
| 69 | ``` |
| 70 | |
| 71 | --- |
| 72 | |
| 73 | ## 3. Supply Chain Security (A03) |
| 74 | |
| 75 | ### Attack Surface |
| 76 | |
| 77 | | Vector | Risk | Question to Ask | |
| 78 | |--------|------|-----------------| |
| 79 | | **Dependencies** | Malicious packages | Do we audit new deps? | |
| 80 | | **Lock files** | Integrity attacks | Are they committed? | |
| 81 | | **Build pipeline** | CI/CD compromise | Who can modify? | |
| 82 | | **Registry** | Typosquatting | Verified sources? | |
| 83 | |
| 84 | ### Defense Principles |
| 85 | |
| 86 | - Verify package integrity (checksums) |
| 87 | - Pin versions, audit updates |
| 88 | - Use private registries for critical deps |
| 89 | - Sign and verify artifacts |
| 90 | |
| 91 | --- |
| 92 | |
| 93 | ## 4. Attack Surface Mapping |
| 94 | |
| 95 | ### What to Map |
| 96 | |
| 97 | | Category | Elements | |
| 98 | |----------|----------| |
| 99 | | **Entry Points** | APIs, forms, file uploads | |
| 100 | | **Data Flows** | Input → Process → Output | |
| 101 | | **Trust Boundaries** | Where auth/authz checked | |
| 102 | | **Assets** | Secrets, PII, business data | |
| 103 | |
| 104 | ### Prioritization Matrix |
| 105 | |
| 106 | ``` |
| 107 | Risk = Likelihood × Impact |
| 108 | |
| 109 | High Impact + High Likelihood → CRITICAL |
| 110 | High Impact + Low Likelihood → HIGH |
| 111 | Low Impact + High Likelihood → MEDIUM |
| 112 | Low Impact + Low Likelihood → LOW |
| 113 | ``` |
| 114 | |
| 115 | --- |
| 116 | |
| 117 | ## 5. Risk Prioritization |
| 118 | |
| 119 | ### CVSS + Context |
| 120 | |
| 121 | | Factor | Weight | Question | |
| 122 | |--------|--------|----------| |
| 123 | | **CVSS Score** | Base severity | How severe is the vuln? | |
| 124 | | **EPSS Score** | Exploit likelihood | Is it being exploited? | |
| 125 | | **Asset Value** | Business context | What's at risk? | |
| 126 | | **Exposure** | Attack surface | Internet-facing? | |
| 127 | |
| 128 | ### Prioritization Decision Tree |
| 129 | |
| 130 | ``` |
| 131 | Is it actively exploited (EPSS >0.5)? |
| 132 | ├── YES → CRITICAL: Immediate action |
| 133 | └── NO → Check CVSS |
| 134 | ├── CVSS ≥9.0 → HIGH |
| 135 | ├── CVSS 7.0-8.9 → Consider asset value |
| 136 | └── CVSS <7.0 → Schedule for later |
| 137 | ``` |
| 138 | |
| 139 | --- |
| 140 | |
| 141 | ## 6. Exceptional Conditions (A10 - New) |
| 142 | |
| 143 | ### Fail-Open vs Fail-Closed |
| 144 | |
| 145 | | Scenario | Fail-Open (BAD) | Fail-Closed (GOOD) | |
| 146 | |----------|-----------------|---------------------| |
| 147 | | Auth error | Allow access | Deny access | |
| 148 | | Parsing fails | Accept input | Reject input | |
| 149 | | Timeout | Retry forever | Limit + abort | |
| 150 | |
| 151 | ### What to Check |
| 152 | |
| 153 | - Exception handlers that catch-all and ignore |
| 154 | - Missing error handling on security operations |
| 155 | - Race conditions in auth/authz |
| 156 | - Resource exhaustion scenarios |
| 157 | |
| 158 | --- |
| 159 | |
| 160 | ## 7. Scanning Methodology |
| 161 | |
| 162 | ### Phase-Based Approach |
| 163 | |
| 164 | ``` |
| 165 | 1. RECONNAISSANCE |
| 166 | └── Understand the target |
| 167 | ├── Technology stack |
| 168 | ├── Entry points |
| 169 | └── Data flows |
| 170 | |
| 171 | 2. DISCOVERY |
| 172 | └── Identify potential issues |
| 173 | ├── Configuration review |
| 174 | ├── Dependency analysis |
| 175 | └── Code pattern search |
| 176 | |
| 177 | 3. ANALYSIS |
| 178 | └── Validate and prioritize |
| 179 | ├── False positive elimination |
| 180 | ├── Risk scoring |
| 181 | └── Attack chain mapping |
| 182 | |
| 183 | 4. REPORTING |
| 184 | └── Actiona |
People who liked this also viewed
6 picksType
- find-skillsHelps users discover and install agent skills when they ask questions like "how do I do X", "find a skill for X", "is there a skill that can...", or express interest in extending capabilities. This skSkillsJul 2026
- grill-meA relentless interview to sharpen a plan or design.SkillsJul 2026
- vercel-react-best-practicesVercel's official collection of agent skillsSkillsJul 2026
- improve-codebase-architectureScan a codebase for deepening opportunities, present them as a visual HTML report, then grill through whichever one you pick.SkillsJul 2026
- setup-matt-pocock-skillsConfigure this repo for the engineering skills — set up its issue tracker, triage label vocabulary, and domain doc layout. Run once before first use of the other engineering skills.SkillsJul 2026
- triageMove issues and external PRs through a state machine of triage roles — categorise, verify, grill if needed, and write agent-ready briefs.SkillsJul 2026
