Dependency Cve Triage.prompt

---
agent: "application-security-analyst"
name: dependency-cve-triage
description: "Triage a dependency CVE using local repo evidence and remediation guidance."
---

# 🛡️ Prompt: Dependency CVE Triage

Act as a **security vulnerability analyst** investigating a known CVE in the context of a web application dependency.

---

## ✅ Context / Assumptions

- Inputs:
  - `${input:cve-number:Which CVE would you like me to analyze? (e.g., CVE-2024-12345)}`
  - `${input:package-name:What dependency/package is this about? (optional if obvious from repo)}`
- Prefer evidence-first: cite file paths and (when possible) line ranges for dependency usage.
- If external browsing is available, use reputable sources (NVD, vendor advisories). If not, state that limitation.

## 🔍 Procedure

1. Confirm the vulnerable component:
   - package name, ecosystem, affected versions, direct vs transitive.
2. Summarize the vulnerability:
   - exploit vector, preconditions, impact, and common exploitation patterns.
3. Assess local context:
   - where the dependency is used (imports, call sites)
   - reachability of the vulnerable path
   - configuration/environment preconditions
   - existing mitigations (sandboxing, WAF, auth boundaries)
4. Recommend remediation:
   - upgrade to fixed version (preferred)
   - safe workaround/mitigation (explicitly labeled as stopgap)
5. Provide validation steps:
   - tests/requests to prove non-reachability or that the fix works

## 📦 Output Format

Return two sections:

1) **Dependency Tracker fields** (exactly this format):

   ```txt
   - **Comment:** TEXT_FIELD
   - **Analysis:** [Not Set, Exploitable, In Triage, Resolved, False Positive, Not Affected]
   - **Justification:** [Not Set, Code not present, Code not reachable, Requires configuration, Requires dependency, Requires environment, Protected by compiler, Protected at runtime, Protected at perimeter, Protected by mitigating control]
   - **Vendor Response:** [Not Set, Can not fix, Will not fix, Update, Rollback, Workaround available]
   - **Details:** TEXT_FIELD
   ```

2) **Evidence & validation** (Markdown):

   - **Local evidence**: where the dependency is referenced (file paths + line ranges if available)
   - **Reachability reasoning**: why reachable/not reachable
   - **Remediation plan**: upgrade/workaround + rollout notes
   - **Verification steps**: commands/tests/requests to confirm

## ✅ Quality checks

- Clearly separate what is proven by local code evidence vs what comes from external advisories.
- If you cannot confirm a claim (e.g., no browsing), say so and provide the next best verification step.
- Avoid recommending disabling security controls as the primary remediation.

---

Use clear and concise reasoning. If implementation context is missing, ask for what you need to make a grounded assessment.
Avoid speculation. If you cannot determine the impact, state that explicitly.