La interfaz está localizada; las descripciones y documentos de las Skills se traducen automáticamente con IA a su idioma. El código, los comandos, rutas y términos técnicos se mantienen en el original, y prevalece el documento del autor.
Explorar Skills
Desarrollo · SKILL.md

dependency-vulnerability-triage

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.

Independent GitHub snapshot · Automated classification · Original documentation governs

Documentación de la Skill

GitHub

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".
Skills guardadas