robotti-io/dependency-cve-triage

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:

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