vulnerability-scan

name

vulnerability-scan

description

Scans a project for security vulnerabilities — known CVEs in dependencies, dangerous code patterns, insecure configurations, exposed secrets, and framework-specific weaknesses. Use when asked to find vulnerabilities, audit security, check for CVEs, scan for zero-days, "is this project secure", "security audit", "find security issues", or any request about the overall security posture of a codebase. This is a whole-project audit, not a branch diff review — use it even when the user just says "check security" without specifying a diff.

Vulnerability Scan

Perform a systematic security audit of the entire project to surface vulnerabilities, insecure patterns, and dependency risks. This is a whole-project scan, not a diff review.

Why this matters

Security vulnerabilities in production code can lead to data breaches, unauthorized access, and service compromise. Most projects accumulate risk gradually — an outdated dependency here, a missing authorization check there. This scan surfaces those risks before attackers find them.

Scan Process

Phase 1: Reconnaissance

Understand what you're working with before diving into specific checks. This context shapes which vulnerability classes are relevant.

1. Identify the tech stack: language(s), framework(s), package managers, database(s)
2. Note the application type: web app, API, CLI tool, library, microservice
3. Check for deployment artifacts: Dockerfiles, CI/CD configs, infrastructure-as-code
4. Identify authentication/authorization mechanisms in use

Phase 2: Dependency Audit

Outdated dependencies with known CVEs are the lowest-hanging fruit for attackers.

1. Find dependency lock files (Gemfile.lock, package-lock.json, yarn.lock, poetry.lock, go.sum, Cargo.lock, etc.)
2. Run available audit tools if present in the project:
   • Ruby: bundle audit check --update or check Gemfile.lock against known advisories
   • Node: npm audit or yarn audit
   • Python: pip-audit or check against known advisories
   • If tools aren't installed, manually inspect dependency versions against known CVE databases
3. Flag dependencies that are significantly behind (major versions) as they accumulate unpatched vulnerabilities even without specific CVEs
4. Check for dependencies pulled from non-standard registries or pinned to git commits (supply chain risk)

Phase 3: Secrets Detection

Hardcoded secrets are one of the most common and damaging vulnerability classes.

1. Search for hardcoded credentials, API keys, tokens, and passwords in:
   • Source code files
   • Configuration files (especially those not in .gitignore)
   • Environment file templates (.env.example, .env.sample)
   • CI/CD configurations
   • Docker and infrastructure files
2. Check .gitignore coverage — are sensitive files properly excluded?
3. Look for secrets in git history if accessible (committed then removed is still exposed)
4. Check for overly permissive secret sharing (e.g., secrets in shared config vs. environment variables)

Phase 4: Code Pattern Scanning

Scan the codebase for patterns known to introduce vulnerabilities.

Injection vulnerabilities:

• SQL injection: string interpolation in queries, raw SQL with user input
• Command injection: system/exec/backtick calls with user-controlled input
• XSS: unescaped user input in templates/views, html_safe or raw on user content
• LDAP/XML/NoSQL injection where applicable
• Path traversal: user input in file paths without sanitization

Authentication & Authorization:

• Missing authorization checks on controller actions/endpoints
• Broken access control (e.g., direct object references without ownership checks)
• Weak password requirements or storage (plaintext, weak hashing)
• Session management issues (fixation, long-lived tokens, missing expiry)
• JWT weaknesses (none algorithm, weak secrets, missing expiry)

Data exposure:

• Sensitive data in logs (passwords, tokens, PII)
• Verbose error messages exposing internals in production
• API responses including more data than needed (over-fetching)
• Missing encryption for sensitive data at rest

Framework-specific checks:

For Rails projects:

• Mass assignment vulnerabilities (unpermitted params)
• CSRF protection disabled or misconfigured
• Unsafe render calls (user-controlled templates)
• Insecure direct object references in routes
• Missing protect_from_forgery
• Unsafe deserialization (YAML.load vs YAML.safe_load, Marshal)
• Brakeman-style checks if brakeman is available

For Node/JavaScript projects:

• Prototype pollution
• eval() or Function() with user input
• Insecure RegExp (ReDoS)
• Missing helmet/security headers
• Unsafe deserialization

For Python projects:

• pickle with untrusted data
• Jinja2 with autoescape disabled
• os.system/subprocess with shell=True and user input
• Django/Flask specific: DEBUG mode, ALLOWED_HOSTS, CSRF

Phase 5: Configuration & Infrastructure

1. Check security headers configuration (CSP, HSTS, X-Frame-Options, etc.)
2. Review CORS configuration for overly permissive origins
3. Check TLS/SSL configuration if visible
4. Review Dockerfile security (running as root, unnecessary packages, multi-stage builds)
5. Check CI/CD for secret leakage, unpinned actions, excessive permissions
6. Review database configuration for unsafe defaults

Phase 6: Multi-tenant & Data Isolation (if applicable)

If the application serves multiple tenants:

1. Check for consistent tenant scoping on all queries
2. Look for cross-tenant data leakage vectors
3. Verify tenant context is set early in the request lifecycle
4. Check background jobs maintain tenant context

Report Format

Present findings organized by severity. Each finding should be actionable — someone reading this should know exactly what to fix and why.

Critical (Exploitable now, likely to cause significant damage)

• The vulnerability, with file:line reference
• Why it's critical: what an attacker could achieve
• Remediation: specific code change or configuration fix

High (Exploitable with some effort, significant impact)

• Same structure as Critical

Medium (Requires specific conditions, moderate impact)

• Same structure as Critical

Low (Minimal impact or requires unlikely conditions)

• Same structure as Critical

Positive Observations

Note what the project does well — secure defaults in use, good patterns worth preserving. This helps the team understand their baseline and avoid regressing.

Summary

• Total findings by severity
• Top 3 priorities to address first (explain why these three)
• Overall security posture assessment (one paragraph)

Important Considerations

• Focus on exploitability, not theoretical purity. A finding that requires local filesystem access in a containerized app is less urgent than an unauthenticated API endpoint.
• Don't flag framework defaults as vulnerabilities unless they're genuinely dangerous in the project's context.
• When unsure about severity, explain your reasoning and let the user decide. False confidence is worse than expressed uncertainty.
• If security scanning tools are available (brakeman, npm audit, etc.), run them and incorporate their output. But don't rely solely on tools — they miss logic-level vulnerabilities that contextual analysis catches.
• For large codebases, prioritize: authentication/authorization code, API endpoints, data access layers, and configuration files. These are where the highest-impact vulnerabilities concentrate.