Dependabot Alerts

Dependabot Alerts

Triage open Dependabot security alerts into GUS work items. Output is work items only — no branches, bumps, or PRs. The auto-build-wi workflow claims each WI and does the build/PR.

User-invoked only. Never auto-fire.

Never

• No npm overrides in package.json. Ever.
• No blind lockfile bumps. Trace the dependency to its outermost consumer first.

Input

• Bare invocation → list open alerts: gh api repos/forcedotcom/salesforcedx-vscode/dependabot/alerts --paginate --jq '[.[] | select(.state=="open")]' | jq -s add. --paginate is required — the API defaults to 30/page and silently returns only page 1 without it (e.g. 33 open alerts, not the ~14 page 1 shows).
• User-specified package / GHSA / CVE → act on that alert only.

(Repo is a monorepo, workspaces packages/*. npm 11.)

Per alert: trace the thread

Find who pulls the vulnerable package in, working outward to a package.json.

1. npm why <vuln-pkg> (or npm ls <vuln-pkg>) from repo root → every path to a direct dep declared in a package.json (root or a packages/*).
2. For each path, the outermost consumer is the direct dep at the top of that path. One alert can have several.

Per consumer: pick the fix

Try in order; stop at the first that works:

1. Bump the consumer in package.json. A newer version of the consumer resolves <vuln-pkg> to a patched version (consumer already shipped the fix). Edit the version in whichever package.json declares it. Best — preferred.
2. pnpm update <consumer>. Consumer's existing semver range already allows a patched <vuln-pkg>, but the lockfile is stale. No package.json change. Second best.
3. Unfixable — consumer's latest still pins the vulnerable version. Skip this path silently. No WI.

Pick the lowest consumer version that resolves <vuln-pkg> to a patched version, never latest — fewer majors crossed, fewer breaking changes to vet.

Vet major-version bumps

If the chosen bump crosses a major version (e.g. ^1.x → ^3.0.0), spawn one subagent per crossing bump to vet it before drafting the WI. One bump may span several majors (1→3 = two changelogs); independent bumps vet in parallel.

Each subagent's task:

1. Read the consumer's release notes / CHANGELOG for every major crossed (e.g. 1→3 means read 2.0.0 and 3.0.0). There may be one or five.
2. For each breaking change found, grep our code for the affected API/behavior and decide if it breaks us specifically.
3. Return: does the bump break us? What breaks, where (file:line), and the lowest version that clears the vuln without a breaking change.

What the subagent looks for:

• ESM-only ("type": "module"). Our .github/actions/* and most packages are CJS (tsc module: node16, require() output). An ESM-only dep can't be require()d from a CJS build — breaking migration, not a bump.
• Dropped Node engine support — must satisfy the consuming context (.github/actions/* run using: node20; extensions target their own engine).
• Transitive major bumps the consumer drags in (e.g. Octokit majors) — only breaking if our usage touches the changed API.

Act on the verdict:

• Breaking change avoidable at a lower major that still clears the vuln → prefer it, cap the range below the breaking major (e.g. ^2.0.0, not ^3.0.0). Note the cap + reason in Details__c.
• Only fixing version forces a breaking migration → the WI is not a simple bump. Put the subagent's findings (what breaks, file:line, required changes) in Details__c so auto-build-wi plans for it.