Skip to main content
AI/MLRobotti-io

dependency-cve-triage

Triage a dependency CVE using local repo evidence and remediation guidance.

Stars
42
Source
Robotti-io/copilot-security-instructions
Updated
2026-05-17
Slug
Robotti-io--copilot-security-instructions--dependency-cve-triage
View on GitHubRaw SKILL.md

// install — copy + paste into any project

mkdir -p .claude/skills && curl -fsSL https://raw.githubusercontent.com/Robotti-io/copilot-security-instructions/HEAD/plugins/copilot-security/skills/dependency-cve-triage/SKILL.md -o .claude/skills/dependency-cve-triage.md

Drops the SKILL.md into .claude/skills/dependency-cve-triage.md. Works with Claude Code, Cursor, and any agent that loads SKILL.md files from .claude/skills/.

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.