name: vulnerability-scanner
description: A structured method for security review that combines an attacker mindset with the OWASP Top 10 (2025), supply-chain risk, attack-surface mapping, exploit-aware risk ranking, and code-pattern and secret analysis. Use it when scanning a project for vulnerabilities, checking OWASP alignment, assessing dependency and supply-chain exposure, or prioritizing which findings to fix first.
Vulnerability Scanner
Reason like the attacker, then close the gap like the defender. Keep the current threat landscape in view.
Automation
| Script | What it does | How to run |
|---|
scripts/security_scan.py | Checks deps, secrets, risky patterns, and config | python scripts/security_scan.py <project_path> |
Reference
| File | Contents |
|---|
| checklists.md | Copy-ready checklists: OWASP, auth, API, data protection |
The defender's mental model
Operating assumptions
- Assume breach -- design as though an attacker is already inside.
- Zero trust -- verify every request; trust nothing implicitly.
- Layered defense -- no single control should be load-bearing.
- Least privilege -- grant the minimum access that works.
- Fail closed -- when something errors, deny rather than allow.
Frame the threat before scanning
- What's valuable here? (the assets)
- Who would come after it? (the actors)
- By what route? (the vectors)
- What does a successful hit cost the business? (the impact)
OWASP Top 10 (2025)
| Code | Category | The core question |
|---|
| A01 | Broken Access Control | Who can reach what? Watch for IDOR and SSRF |
| A02 | Security Misconfiguration | Leftover defaults, missing headers, exposed services |
| A03 | Software Supply Chain (new) | Dependencies, CI/CD, build integrity |
| A04 | Cryptographic Failures | Weak crypto, leaked secrets |
| A05 | Injection | Untrusted input flowing into interpreters |
| A06 | Insecure Design | Flaws baked into the architecture |
| A07 | Authentication Failures | Sessions and credential handling |
| A08 | Integrity Failures | Unsigned updates, tampered data |
| A09 | Logging & Alerting | Blind spots, no monitoring |
| A10 | Mishandling Exceptional Conditions (new) | Error handling, fail-open behavior |
What shifted from 2021
- SSRF folded into Access Control (A01).
- Misconfiguration rose in prominence with cloud and container defaults.
- Supply chain promoted to its own category (A03) and a primary focus.
- A new entry for exceptional-condition handling (A10).
- Overall emphasis moved toward root causes over surface symptoms.
Supply chain (A03)
Where it gets attacked
- Dependencies -- malicious or compromised packages. Do new ones get reviewed?
- Lock files -- the integrity anchor. Are they committed?
- Build pipeline -- a high-value target. Who can change it?
- Registries -- typosquatting and impersonation. Are sources verified?
How to defend it
- Verify integrity via checksums.
- Pin versions and review every bump.
- Host critical dependencies in a private registry.
- Sign build artifacts and verify those signatures.
Mapping the attack surface
Catalog the four things
- Entry points -- APIs, forms, file uploads.
- Data flows -- input through processing to output.
- Trust boundaries -- where authn/authz is actually enforced.
- Assets -- secrets, PII, business-critical data.
Score it
Risk is likelihood times impact:
- High likelihood, high impact -> critical
- Low likelihood, high impact -> high
- High likelihood, low impact -> medium
- Low likelihood, low impact -> low
Ranking what to fix first
CVSS plus real-world context
- CVSS -- base severity. How bad is it intrinsically?
- EPSS -- exploitation probability. Is it being used in the wild?
- Asset value -- what's actually at stake here?
- Exposure -- is it reachable from the internet?
Decision path
- Actively exploited (EPSS above ~0.5)? -> critical, fix now.
- Otherwise weigh CVSS:
- 9.0 or higher -> high.
- 7.0-8.9 -> weigh against asset value.
- below 7.0 -> schedule it.
Exceptional conditions (A10)
Fail open vs fail closed
- Auth check errors out -> bad: grant access; good: deny access.
- Input fails to parse -> bad: accept it anyway; good: reject it.
- A dependency times out -> bad: retry forever; good: cap retries and abort.
What to look for
- Catch-all handlers that swallow and ignore errors.
- Security-relevant operations with no error handling at all.
- Race conditions around authn/authz.
- Paths that allow resource exhaustion.
How to run a scan
- Recon -- understand the target: tech stack, entry points, data flows.
- Discovery -- surface candidates: review config, analyze dependencies, search code patterns.
- Analysis -- validate and rank: drop false positives, score risk, trace attack chains.
- Reporting -- deliver action: reproduction steps, business impact, concrete remediation.
Reading the code
Patterns that signal danger
- Query strings built by concatenation -> injection, e.g.
"SELECT * FROM " + user_input. - Dynamic code execution -> RCE, e.g.
eval(), exec(), Function(). - Unsafe deserialization -> RCE, e.g.
pickle.loads(), unserialize(). - User input in file paths -> path traversal.
- Disabled safety switches -> e.g.
verify=False, --insecure.
Secrets to hunt for
- API keys --
api_key, apikey, high-entropy strings. - Tokens --
token, bearer, JWT-shaped values. - Credentials --
password, secret, key. - Cloud creds --
AWS_, AZURE_, GCP_ prefixes.
Cloud considerations
Who owns which layer
You own your data and application code; the provider owns the underlying infrastructure; OS and runtime ownership depends on the service model.
Quick cloud checks
- IAM -- is least privilege actually applied?
- Storage -- any buckets exposed publicly?
- Network -- are security groups tightly scoped?
- Secrets -- managed through a secrets manager?
Habits to drop
- Scanning blind -> map the attack surface first.
- Alerting on every CVE -> rank by exploitability and asset value.
- Re-flagging known false positives -> keep a verified baseline.
- Patching symptoms -> fix the underlying cause.
- A single pre-deploy scan -> scan continuously.
- Trusting third-party code on faith -> verify integrity and review it.
Writing up findings
Each finding answers
- What is the vulnerability?
- Where is it (file, line, endpoint)?
- Why does it happen (root cause)?
- Impact -- what's the business consequence?
- Fix -- the specific remediation.
Severity bands
- Critical -- RCE, auth bypass, large-scale data exposure.
- High -- data exposure, privilege escalation.
- Medium -- limited blast radius, needs specific conditions.
- Low -- informational or best-practice.
Scanners surface issues; judgment decides what matters. For every finding, ask: what would an attacker actually do with this?