| slug | dependency-vulnerability-response |
| name | Dependency Vulnerability Response |
| version | 0.1.0 |
| description | Respond to a reported CVE in a project dependency. |
| category | guardrails |
| tags | ["security","vulnerability","dependencies","cve"] |
| inputs | [{"name":"cve","type":"string","required":true,"description":"CVE identifier and dependency"},{"name":"exposure","type":"string","required":true,"description":"How the dependency is used"}] |
| output | {"format":"markdown","description":"Response plan with triage, mitigation options, and verification."} |
| author | badhope |
| license | MIT |
| created | "2026-06-21T00:00:00.000Z" |
| updated | "2026-06-21T00:00:00.000Z" |
When to use
A scanner reports a CVE, a security advisory is published, or during a security review.
Inputs
Provide the CVE/dependency and how the project uses it.
Output
A triage and mitigation plan with verification steps.
Prompt
Respond to a dependency vulnerability.
Output:
1. Triage: severity, exploitability in this project's usage, affected versions
2. Options: upgrade, patch, remove, workaround, accept risk
3. Decision: recommended path with rationale
4. Verification: how to confirm the fix (scanner output, test, code review)
5. Communication: who to notify and timeline
6. Prevention: how to catch similar issues earlier
Do not download or execute exploit code.
When NOT to use
- Vulnerabilities in development-only tools with no production exposure
- False positives from scanners without a published advisory
- Issues already tracked by a dedicated security team with an existing runbook
Example
Input:
cve: 'CVE-2024-1234 in lodash < 4.17.21'
exposure: 'Used for object merging in request handlers'
Output:
## Triage
Severity: HIGH. Affects deep merge in request parsing; exploitable if user input reaches merge.
## Options
1. Upgrade to lodash 4.17.21 (preferred).
2. Replace with native structuredClone where applicable.
## Verification
Run `npm audit`; confirm lodash version in lockfile. Add a test with a malicious payload shape.
Footguns
These are the bugs that bite every new user.
Check them before shipping:
-
Accepting scanner findings without triage: Every CVE doesn't apply to every usage.
- how to detect: upgrading dependencies that don't actually fix a vulnerability in your code
- how to fix: verify the vulnerable code path is actually reachable in your codebase
-
Exploits executed during investigation: Running proof-of-concept code to "understand" the vulnerability.
- how to detect: malware detected in analysis environment
- how to fix: analyze CVE description and affected versions without running exploit code
-
Pinning to a fixed version without understanding range: Upgrading to a version that still has the issue.
- how to detect: scanner still reports vulnerability after upgrade
- how to fix: check exact affected versions, upgrade to a safe version
-
Not communicating to stakeholders: Security issues without notification lead to surprise.
- how to detect: customers find out about vulnerability from external sources
- how to fix: follow disclosure timeline, notify affected parties early
-
No regression test added: Fix is applied but no test prevents the vulnerability from returning.
- how to detect: same CVE appears again after some months
- how to fix: add a test case that would fail if the vulnerable pattern is reintroduced