mk:vulnerability-scanner

Vulnerability Scanner

Think like an attacker, defend like an expert.

When to Use

• Security audit of a project or module
• Before shipping code that handles auth, payments, or user data
• When asked to "scan for vulnerabilities", "security check", "audit security"
• When mk:cso delegates specific scanning tasks

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

Process

1. Map attack surface — entry points, data flows, trust boundaries, assets
2. Load scanning methodology — read references/scanning-methodology.md
3. Reconnaissance — understand technology stack, entry points, data flows
4. Discovery — configuration review, dependency analysis, code pattern search
5. Analysis — validate findings, eliminate false positives, score risks
6. Report — each finding: What, Where, Why, Impact, How to fix

Threat Modeling Questions

Before scanning, ask: What are we protecting? Who would attack? How? What's the impact?

References

Reference	When to load	Content
scanning-methodology.md	Step 2 — executing scan	OWASP Top 10, supply chain, code patterns, risk prioritization, reporting format

Runtime Scripts

Script	Purpose	Usage
security-scan.py	Security pattern scanning	.claude/skills/.venv/bin/python3 .claude/scripts/security-scan.py
injection-audit.py	Prompt injection detection	.claude/skills/.venv/bin/python3 .claude/scripts/injection-audit.py

Gotchas

• False positives in test fixtures: Security scan flags intentionally insecure test data → Exclude test/fixtures/ and mocks/ from vulnerability scans
• Dependency confusion attacks missed: Scanner checks known CVEs but not package name typosquatting → Cross-reference package names against known typosquat databases