# Vulnerability Assessment

> 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.

- Skill: `ashutoshsrivastava17/vulnerability-assessment` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/vulnerability-assessment`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/vulnerability-assessment/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/vulnerability-assessment

---


# 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