the agent's "one PR per CVE" policy created 15 PRs for one shared transitive dependency - grouping by root cause instead

TL;DR: Fifteen CVEs in one transitive dependency need one bump, not fifteen PRs. Group fix PRs by the dependency being changed - not by the CVE being closed - so a single upgrade PR resolves every ticket that traces to that root cause.

the agent's "one PR per CVE" policy created 15 PRs for one shared transitive dependency - grouping by root cause instead

Steps

1. Pick one of the 15 PRs and trace its CVE to the actual package being bumped: run npm ls on the suspect package, pipdeptree --reverse, cargo tree --invert, or follow your scanner's "introduced through" chain.

Expected: the bump target is a shared transitive dependency, not the direct one named in the ticket.

1. Repeat the trace for a few more tickets.

Expected: they converge on the same root package - that is your grouping key.

1. Change the policy: group remediation PRs by root-cause package. In dependabot, use a groups block keyed on that package's pattern; in renovate, a packageRule with matchPackageNames on the root dep and one groupName.

Expected: the next scan produces one PR for the shared dep instead of fifteen.

1. Close the 14 duplicate PRs, keeping the one that bumps the shared dependency (or open a fresh single PR that does).

Expected: one PR, fifteen linked tickets.

1. Link all fifteen CVE tickets to the single PR and let the merge close them together.

Expected: the backlog drains by fourteen tickets with one review.

Use this when

• Many CVE tickets trace to the same transitive dependency
• Your agent opens one fix PR per CVE and they collide
• Reviewers are drowning in duplicate bump PRs
• You want the PR count to reflect the work, not the CVE count

Not for this skill when

• The CVEs genuinely need different fixes (different packages, different version lines) - those stay separate
• The shared dependency cannot be bumped without breaking dependents - that needs an upgrade plan, not a grouping fix
• The tickets are informational (no fix available) - grouping does not create a patch

Variant phrasings

• too many dependabot PRs for the same transitive dependency
• group security PRs by dependency instead of CVE
• one PR per CVE policy created duplicate fix PRs

Why it happens

"One PR per CVE" feels rigorous - every finding gets its own tracked fix. But CVEs are findings and dependencies are the things you change; the mapping is many-to-one. Fifteen tickets for one shared bump means fifteen PRs editing the same lockfile lines, which then conflict with each other. Grouping by root cause aligns the PR with the actual change.

Edge cases

• The shared dep may be pinned by different parents at different version ranges - one bump may not satisfy all fifteen; split by version line, not by CVE.
• Some CVEs in the group may be disputed or already fixed upstream - verify each ticket's fix version before assuming the bump closes it.
• If the root dep is unmaintained, the real fix is replacing it - say so in the group PR instead of bumping forever.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstZ9ryFSMjImqIiufhbfXQg