sharkitect-solutions/vulnerability-scanner

Vulnerability Scanner

Performs structured vulnerability assessments using OWASP 2025 categories, maps attack surfaces, prioritizes findings by exploitability and business impact, and produces actionable remediation reports.

Scope Boundary

| This Skill (vulnerability-scanner) | The security-best-practices Skill | |---|---| | Finding vulnerabilities: scanning, assessment, attack surface mapping | Preventing vulnerabilities: secure coding patterns, framework-specific hardening | | Risk prioritization: CVSS + EPSS + business context scoring | Code-level implementation: parameterized queries, input validation, output encoding | | Reporting: structured findings with severity, location, remediation | Reference library: 10 framework-specific security guides | | Methodology: reconnaissance, discovery, analysis, reporting phases | Operating modes: passive (while coding), active (review), report generation |

When both apply: Use vulnerability-scanner to find issues, then use security-best-practices to implement the fixes using framework-specific secure patterns.

File Index

| File | Purpose | When to Load | |---|---|---| | SKILL.md | Scanning methodology, OWASP 2025, risk prioritization | Always (auto-loaded) | | checklists.md | OWASP Top 10, auth, API, data protection audit checklists | During active security audits | | attack-surface-mapping.md | Entry point catalogs by technology, trust boundary identification, data flow analysis, automated discovery techniques | When performing initial reconnaissance or mapping attack surfaces | | remediation-playbook.md | Fix patterns by OWASP category, emergency patching procedure, dependency upgrade framework, remediation sprint planning | When implementing fixes for discovered vulnerabilities | | scripts/security_scan.py | Automated code pattern scanning | When running automated validation |

Scanning Methodology

Override rule: If the user's organization has an existing threat model, security policy, or vulnerability management framework, align your methodology to their framework rather than imposing this one. If they use a different classification system (DREAD, custom severity matrix), map findings to their system. If they use a GRC tool (DefectDojo, Snyk dashboard, Jira with security fields), format findings to import into their system rather than generating standalone reports.

1. Reconnaissance: Understand the target before scanning.

   • Identify technology stack (languages, frameworks, databases, cloud provider)
   • Map entry points (APIs, forms, file uploads, WebSocket endpoints)
   • Document data flows (input -> processing -> storage -> output)
   • Identify trust boundaries (where authentication/authorization is checked)
   • If the user has an existing asset inventory or architecture diagram, use it as the starting point rather than rediscovering from scratch

2. Discovery: Systematic search for potential issues.

   • Run automated pattern scanning (scripts/security_scan.py)
   • Review configuration files for insecure defaults
   • Analyze dependency tree for known vulnerabilities
   • Search for high-risk code patterns (see Code Pattern Analysis below)
   • Load checklists.md and work through relevant sections

3. Analysis: Validate findings and eliminate false positives.

   • Confirm each finding is actually exploitable in context
   • Score using the Risk Prioritization Framework below
   • Map attack chains (how findings combine for greater impact)
   • Maintain a verified baseline -- don't re-flag accepted risks

4. Reporting: Produce actionable output.

   • Structure findings using the Finding Template below
   • Classify by severity (Critical > High > Medium > Low)
   • Include specific file paths, line numbers, and reproduction steps
   • Provide remediation guidance with code examples

OWASP Top 10: 2025

| Rank | Category | What Changed from 2021 | Key Questions to Ask | |---|---|---|---| | A01 | Broken Access Control | SSRF merged in; now broadest category | Can users access resources they shouldn't? Are IDORs possible? Is SSRF blocked? | | A02 | Security Misconfiguration | Elevated priority -- cloud/container configs are primary attack surface | Are default credentials changed? Are unnecessary features disabled? Are security headers set? | | A03 | Software Supply Chain (NEW) | Entirely new category reflecting real-world attack trends | Are dependencies audited? Are lock files committed? Is CI/CD pipeline secured? | | A04 | Cryptographic Failures | Renamed from "Sensitive Data Exposure" to focus on root cause | Are passwords properly hashed? Are secrets in code? Is TLS enforced? | | A05 | Injection | Remains critical but scope expanded beyond SQL | Are all queries parameterized? Is user input in system commands? Is output encoded? | | A06 | Insecure Design | Architecture-level flaws, not just implementation bugs | Was threat modeling done? Are business logic edge cases handled? | | A07 | Authentication Failures | Session and credential management issues | Is MFA available? Are sessions invalidated on logout? Is brute force prevented? | | A08 | Integrity Failures | Unsigned updates, tampered build artifacts | Are dependencies verified by checksum? Is the CI/CD pipeline protected from injection? | | A09 | Logging & Monitoring Failures | Blind spots that prevent breach detection | Are security events logged? Are alerts configured? Is sensitive data excluded from logs? | | A10 | Exceptional Conditions (NEW) | Error handling failures that create security gaps | Do exceptions fail open or closed? Are catch-all handlers hiding errors? Are race conditions in auth checked? |

Supply Chain Security Assessment (A03)

| Attack Vector | What to Check | How to Check | |---|---|---| | Dependency vulnerabilities | Known CVEs in direct and transitive dependencies | npm audit, pip-audit, cargo audit, or Snyk/Dependabot | | Typosquatting | Package names similar to popular packages | Verify package publisher, check download counts, compare to official registry | | Lock file integrity | Lock files committed and not manually edited | git log on lock files; verify checksums match registry | | CI/CD pipeline | Who can modify build scripts, deploy configs | Review permissions on .github/workflows/, Jenkinsfile, etc. | | Build artifact integrity | Signed releases, reproducible builds | Check for signing keys, compare build outputs |

Code Pattern Analysis

High-risk patterns to search for during discovery phase.

| Pattern | Risk | Search Terms / Regex | |---|---|---| | SQL injection | String concatenation in queries | "SELECT.*" + , f"SELECT, .format( near SQL, %s without parameterization | | Command injection | User input in shell commands | os.system(, subprocess.call(.*shell=True, exec(, eval( | | Unsafe deserialization | Arbitrary object instantiation | pickle.loads(, yaml.load( without SafeLoader, unserialize(, JSON.parse with reviver | | Path traversal | User input in file paths | open(.*request, fs.readFile(.*req, ../ not sanitized | | Disabled security | Explicit security bypass | verify=False, --insecure, allowInsecure, dangerouslySetInnerHTML, | safe | | Hardcoded secrets | Credentials in source code | password =, api_key =, secret =, token =, high-entropy strings | | Weak cryptography | Broken or obsolete algorithms | MD5, SHA1 for security (not checksums), DES, RC4, Math.random() for tokens |

Risk Prioritization Framework

Raw CVSS scores are insufficient. Combine with exploitability and business context.

| Factor | Weight | How to Assess | |---|---|---| | CVSS base score | Severity of the vulnerability itself | Use NVD calculator or tool output | | EPSS score | Probability of exploitation in the wild | Check FIRST.org EPSS data; >0.5 = actively exploited | | Asset value | Business impact if compromised | PII = high, internal tool = medium, static content = low | | Exposure | How accessible the vulnerability is | Internet-facing API = high, internal service = medium, local-only = low | | Exploit complexity | How difficult to exploit | No auth required = high, requires admin access = low |

Prioritization decision tree:

• EPSS >0.5 (actively exploited) -> CRITICAL: Immediate action regardless of CVSS
• CVSS >= 9.0 + internet-facing -> CRITICAL
• CVSS 7.0-8.9 + high asset value -> HIGH
• CVSS 7.0-8.9 + low asset value -> MEDIUM
• CVSS <7.0 -> Schedule based on available capacity

Override: If the organization has existing SLA-based severity tiers (e.g., P1/P2/P3 with specific remediation timelines), map findings to their tiers. The decision tree above is a starting point, not a mandate.

Finding Template

Each finding must include all five elements to be actionable.

| Element | Content | |---|---| | What | Clear vulnerability description with category (e.g., "SQL injection via unsanitized user input in search parameter") | | Where | Exact file path, line number, and endpoint (e.g., src/api/search.py:47, GET /api/search?q=) | | Why | Root cause explanation (e.g., "User input concatenated into SQL query string without parameterization") | | Impact | Business consequence with severity (e.g., "CRITICAL: Full database read access including user credentials and PII") | | Fix | Specific remediation with code example (e.g., "Replace string concatenation with parameterized query using cursor.execute(sql, params)") |

If the user requests a different reporting format (SARIF, CycloneDX, CSV, or direct import into their SIEM/ticketing system), adapt the output format accordingly. The five elements above must still be present regardless of format.

Fail-Open vs Fail-Closed Assessment (A10)

| Scenario | Fail-Open (Vulnerable) | Fail-Closed (Secure) | |---|---|---| | Authentication service error | Default to allowing access | Default to denying access | | Input parsing exception | Accept the input | Reject the input | | Authorization check timeout | Grant permissions | Deny permissions | | Rate limit counter error | Allow unlimited requests | Block requests until counter recovers | | Catch-all exception handler | Log and continue processing | Log, alert, and halt the operation |

Assessment rule: For every try/catch or error handler in security-critical code, ask: "If this fails, does the user get MORE or LESS access?" If more, it's fail-open and must be fixed.

Scanning Anti-Patterns

| Name | Pattern | Why it fails | Quantified impact | |---|---|---|---| | Pre-Launch Panic | Scheduling security scanning only before launch | Rewriting code under deadline pressure; teams ship known vulnerabilities rather than delay | Vulnerabilities found in dev cost 6x less to fix than in production (IBM SSDF) | | Framework Blindness | Assuming framework protections cover all vulnerabilities | Custom endpoints, raw queries, and middleware misconfig bypass all framework defaults | 40% of injection findings in enterprise apps are in code paths that bypass the ORM | | Internal-Only Fallacy | Skipping scans for internal tools because "no one will attack it" | Internal systems are primary lateral movement targets after initial breach | 60%+ of post-breach lateral movement involves internal system compromise (Mandiant) | | CVSS Tunnel Vision | Using CVSS score as sole prioritization metric | Ignores exploitability (EPSS), asset value, and exposure context | Teams adding EPSS and business context reduce mean-time-to-remediation by 40% | | WAF Complacency | Treating WAF as substitute for application-level security | WAFs catch known attack patterns; business logic flaws, broken access control, and supply chain attacks bypass entirely | WAF-protected applications still average 3.2 critical findings per penetration test | | Clean Bill Fallacy | Declaring "secure" based on zero automated scan findings | May mean scan coverage was insufficient or tools missed the attack surface entirely | 70% of manual penetration tests find critical issues that automated scans missed |

False Positive Management

Automated scanners produce 30-70% false positives depending on language and tool maturity. Managing noise is a core scanning skill.

| Scan Phase | False Positive Rate | Management Approach | |---|---|---| | First scan of a codebase | 50-70% -- most findings need manual triage | Spend 60% of time on triage, 40% on real findings. Build initial suppression baseline | | Subsequent scans (same tool) | 20-40% -- suppression file eliminates known FPs | Focus on NEW findings only. Review suppression file quarterly | | Multi-tool scanning | 10-20% overlap -- cross-validation reduces FPs | Finding flagged by 2+ tools is almost certainly real. Single-tool-only findings need manual verification |

• Build a suppression file for confirmed false positives (tool-specific: .semgrep.yml, .snyk, .trivyignore)
• Never suppress without documenting WHY it's a false positive -- future reviewers need context
• Re-review suppressions quarterly -- code changes can turn false positives into real vulnerabilities
• If false positive rate exceeds 50% on subsequent scans, the tool rules need recalibration, not more suppression

Rationalization Table

| Rationalization | Why It Fails | |---|---| | "We'll do a security scan before launch" | Vulnerabilities introduced early persist through development; scanning only at the end means rewriting code under deadline pressure | | "Our framework handles security automatically" | Frameworks provide defaults, not guarantees; custom endpoints, raw queries, and misconfigured middleware bypass framework protections | | "This is an internal tool, no one will attack it" | Internal tools are the primary lateral movement target after initial breach; 60%+ of breaches involve internal system compromise | | "The CVSS score is only 6.5, it can wait" | CVSS ignores context; a 6.5 on an internet-facing API handling PII is more dangerous than a 9.0 on an air-gapped system | | "We already have a WAF, so application security isn't critical" | WAFs catch known patterns; custom business logic vulnerabilities, broken access control, and supply chain attacks bypass WAFs entirely | | "Zero critical findings means we're secure" | Absence of findings doesn't mean absence of vulnerabilities; it may mean the scan wasn't thorough enough or the tool missed the attack surface |

Red Flags

• No dependency scanning in CI/CD pipeline -- known CVEs ship to production undetected
• Catch-all exception handlers that swallow errors without logging or alerting
• Security scan results from 6+ months ago treated as current -- threat landscape changes weekly
• Findings reported without file paths or line numbers -- unreproducible findings don't get fixed
• CVSS score used as sole prioritization metric without considering exploitability (EPSS) or business context
• Lock files not committed to version control -- dependency integrity cannot be verified
• No threat model documented -- scanning without understanding assets and threat actors produces noise, not signal
• eval(), exec(), or dynamic code execution found anywhere in the application

NEVER

• Report findings without specific file paths, line numbers, and reproduction steps -- vague findings are ignored by development teams
• Use CVSS score alone to prioritize remediation -- always combine with EPSS (exploitability), asset value, and exposure context
• Skip the reconnaissance phase and jump directly to automated scanning -- scanners without context produce false positives and miss business logic vulnerabilities
• Mark a codebase as "secure" based on passing automated scans alone -- automated tools miss logical vulnerabilities, broken access control, and design-level flaws
• Ignore supply chain security (A03) because "we only use popular packages" -- popular packages are high-value targets precisely because of their widespread adoption