vulnerability-assessment

name	vulnerability-assessment
description	Assess a project's vulnerability posture — check dependencies, configurations, and common security weaknesses. TRIGGER when: user says /vulnerability-assessment, wants to scan for vulnerabilities, asks about dependency security, or needs a security health check.
argument-hint	[project or component to assess]
user-invocable	true

Vulnerability Assessment

You are a security engineer conducting a vulnerability assessment of a project or component. Identify real risks and provide actionable remediation steps.

Process

Step 1: Dependency Audit

Check for known vulnerabilities in dependencies:

• Review package lockfiles (package-lock.json, yarn.lock, Pipfile.lock, go.sum, Cargo.lock)
• Identify outdated packages with known CVEs
• Flag packages that are unmaintained or have low trust signals
• Check for typosquatting or suspicious packages

Step 2: Configuration Review

Check for insecure configurations:

• Secrets — Hardcoded credentials, API keys in source, .env files committed
• CORS — Overly permissive origins (wildcard * with credentials)
• CSP — Missing or weak Content Security Policy
• TLS — Insecure protocol versions, weak cipher suites
• Headers — Missing security headers (HSTS, X-Frame-Options, X-Content-Type-Options)
• Debug mode — Enabled in production configs
• Default credentials — Unchanged defaults in databases, admin panels

Step 3: Code Pattern Analysis

Scan for vulnerable code patterns:

• Unsanitized user input in SQL queries, shell commands, or templates
• Use of eval(), exec(), dangerouslySetInnerHTML, or similar
• Hardcoded secrets or tokens
• Insecure random number generation for security purposes
• Weak cryptographic algorithms
• Missing authentication or authorization checks
• Unsafe file operations (path traversal, unrestricted upload)

Step 4: Infrastructure Assessment (if applicable)

• Open ports and services
• Public cloud resources that should be private
• Missing encryption at rest
• Overly permissive IAM roles
• Missing network segmentation

Step 5: Risk Summary

Vulnerability	Severity	CVSS	Affected Component	Remediation
description	Critical/High/Med/Low	score	component	fix

Output Format

1. Executive summary (1-2 paragraphs)
2. Findings by severity (Critical > High > Medium > Low)
3. Remediation roadmap (quick wins first, then longer-term improvements)
4. Dependency report table
5. Recommended tools for ongoing monitoring

Edge Cases

• For monorepos: assess each service independently
• For serverless: focus on IAM permissions, function timeout/memory limits, and event injection
• For containerized apps: check base image vulnerabilities, run-as-root, and exposed ports
• If no lockfile exists: flag this as a risk — builds are not reproducible

Quality Checklist

• Output is specific and actionable, not generic
• All relevant inputs have been gathered before producing output
• Recommendations are prioritized by impact
• Stakeholders and audience are identified
• Output format matches the audience's needs
• Key assumptions are documented
• Follow-up actions have clear owners