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

# Dependency CVE Triage

## Purpose

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

## When to use

Use this skill when asked to triage a dependency CVE using repository evidence and remediation guidance.

## Inputs to collect

- `${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)}`
- Repository evidence for dependency usage, if available
- External advisory links from reputable sources such as NVD or vendor advisories, if browsing is available

## How to use

- Prefer evidence-first analysis and cite file paths and, when possible, line ranges for dependency usage.
- If external browsing is available, use reputable sources such as NVD or vendor advisories.
- If external browsing is not available, state that limitation explicitly.
- If implementation context is missing, ask for what is needed to make a grounded assessment.
- Avoid speculation. If the impact cannot be determined, state that explicitly.

## Rules

- MUST confirm the vulnerable component, including package name, ecosystem, affected versions, and whether the dependency is direct or transitive.
- MUST summarize the vulnerability, including exploit vector, preconditions, impact, and common exploitation patterns.
- MUST assess local context, including dependency usage locations, reachability of the vulnerable path, configuration or environment preconditions, and existing mitigations such as sandboxing, WAF, or auth boundaries.
- MUST recommend remediation with upgrade to a fixed version as the preferred option.
- MUST label any workaround or mitigation as a stopgap when it is not the preferred long-term fix.
- MUST provide validation steps such as tests or requests to prove non-reachability or confirm the fix works.
- MUST clearly separate what is proven by local code evidence from what comes from external advisories.
- MUST state when a claim cannot be confirmed and provide the next best verification step.
- MUST avoid recommending disabling security controls as the primary remediation.

## Step-by-step process

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, including imports and call sites.
   - Reachability of the vulnerable path.
   - Configuration and environment preconditions.
   - Existing mitigations such as sandboxing, WAF, and auth boundaries.
4. Recommend remediation.
   - Upgrade to a fixed version as the preferred option.
   - Safe workaround or mitigation, explicitly labeled as a stopgap.
5. Provide validation steps.
   - Tests or requests to prove non-reachability or that the fix works.

## Output format

Return two sections.

### Dependency Tracker fields

Use 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
```

### Evidence and validation

- **Local evidence**: where the dependency is referenced, including file paths and line ranges if available
- **Reachability reasoning**: why the vulnerable path is reachable or not reachable
- **Remediation plan**: upgrade or workaround with rollout notes
- **Verification steps**: commands, tests, or requests to confirm the conclusion or fix

## Examples

### Example use

- Triage `${input:cve-number:Which CVE would you like me to analyze? (e.g., CVE-2024-12345)}` for `${input:package-name:What dependency/package is this about? (optional if obvious from repo)}` by confirming the affected package and versions, checking repository usage and reachability, documenting mitigations, and returning the tracker fields plus evidence and validation details.