How do I install the Dependency Vulnerability Triage skill?

Run npx skillmds@latest add poly-gents/dependency-vulnerability-triage in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Dependency Vulnerability Triage safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Dependency Vulnerability Triage?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Dependency Vulnerability Triage free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Dependency Vulnerability Triage?

poly-gents (@poly-gents) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Dependency Vulnerability Triage by poly-gents

Name: Dependency Vulnerability Triage
Author: poly-gents

Dependency Vulnerability Triage

Triage a stream of Dependabot / Snyk / GitHub advisory alerts: filter by reachability and exploitability, decide upgrade vs mitigate vs accept, and route through the normal PR + approval flow.

poly-gents 50a5490 2 files · 3.2 KB Updated Sep 17, 2026

File contents

Dependency vulnerability triage

Most dependency alerts are noise. Some are five-alarm fires. Triage them with this loop so neither extreme dominates your week.

When to run

A new Dependabot alert lands.
A scheduled Snyk scan reports new findings.
A GitHub advisory references a dependency you ship.
A customer or security partner files a CVE-shaped ticket.

The triage loop

Identify. Pull the alert (github_dependabot_alerts or snyk_list_issues). Record CVE id, package, installed version, fixed version (if any), CVSS, and affected repos.
Filter by reachability. Is the vulnerable code path called from your runtime? Use agent_filesystem_search to find imports. Unreachable = lower priority.
Filter by exploitability. Is the input an attacker can actually reach (HTTP body, file upload, third-party callback)? Or is it internal-only?
Decide.
- Upgrade when a fixed version exists and the upgrade is low-risk. Open a PR via github_create_pull_request and run production-validation.
- Mitigate when no fix exists but you can sandbox / WAF-rule / disable the feature. Document the mitigation.
- Accept when reachability + exploitability are both low. Write the acceptance with reasoning into the security log; auto-snooze the alert with the same reasoning, never blind-snooze.
Track. File a planning task (jira_create_task) per finding so the decision is auditable later.

Severity policy (defaults)

Critical, reachable, exploitable: page on-call via pagerduty, fix-forward within 24h.
High, reachable: PR within 5 business days.
Medium / low: batch into a weekly upgrade PR.
Anything in customer-data or auth paths is one severity higher than the CVSS says.

Anti-patterns

Auto-merging Dependabot PRs without production-validation.
Snoozing alerts without a written acceptance rationale.
Treating a reachability-unknown alert as "no big deal".

---name: dependency-vulnerability-triagedescription: Triage a stream of Dependabot / Snyk / GitHub advisory alerts: filter by reachability and exploitability, decide upgrade vs mitigate vs accept, and route through the normal PR + approval flow.---# Dependency vulnerability triageMost dependency alerts are noise. Some are five-alarm fires. Triage them with this loop so neither extreme dominates your week.## When to run- A new Dependabot alert lands.- A scheduled Snyk scan reports new findings.- A GitHub advisory references a dependency you ship.- A customer or security partner files a CVE-shaped ticket.## The triage loop1. **Identify.** Pull the alert (`github_dependabot_alerts` or `snyk_list_issues`). Record CVE id, package, installed version, fixed version (if any), CVSS, and affected repos.2. **Filter by reachability.** Is the vulnerable code path called from your runtime? Use `agent_filesystem_search` to find imports. Unreachable = lower priority.3. **Filter by exploitability.** Is the input an attacker can actually reach (HTTP body, file upload, third-party callback)? Or is it internal-only?4. **Decide.** - **Upgrade** when a fixed version exists and the upgrade is low-risk. Open a PR via `github_create_pull_request` and run `production-validation`. - **Mitigate** when no fix exists but you can sandbox / WAF-rule / disable the feature. Document the mitigation. - **Accept** when reachability + exploitability are both low. Write the acceptance with reasoning into the security log; auto-snooze the alert with the same reasoning, never blind-snooze.5. **Track.** File a planning task (`jira_create_task`) per finding so the decision is auditable later.## Severity policy (defaults)- Critical, reachable, exploitable: page on-call via `pagerduty`, fix-forward within 24h.- High, reachable: PR within 5 business days.- Medium / low: batch into a weekly upgrade PR.- Anything in customer-data or auth paths is one severity higher than the CVSS says.## Anti-patterns- Auto-merging Dependabot PRs without `production-validation`.- Snoozing alerts without a written acceptance rationale.- Treating a reachability-unknown alert as "no big deal".

Frequently asked questions