dependency-vulnerability-triage

name	dependency-vulnerability-triage
description	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 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

1. 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".