the agent auto-approved a security PR from dependabot that was actually a

Not specified by the original author.

TL;DR

The "security" label is not a safety certificate: dependabot will label a major-version bump as a security update when only the major line has the fix. Auto-merging on the label alone merged breaking changes. Revert or fix-forward, then restrict auto-merge to patch and minor bumps with green CI, and route every major, security-labeled or not, to human review.

the agent auto-approved a "security" PR from dependabot that was actually a major version bump with breaking changes

Use this when

• A security-labeled PR bumped a major version and broke the build or the app.
• Auto-merge rules key off the dependabot or security label alone.
• The team assumed "security PR" meant "safe to merge".

Not for this skill when

• The bump was patch or minor and CI is green. That is the case auto-merge is for.
• A human reviewed and accepted the breaking change deliberately. Then the process worked.

Steps

1. Assess the damage: revert the bump or fix-forward through the breaking changes, whichever is smaller. Verify: the app builds and the test suite passes on the chosen path.
2. Check what the major bump was actually fixing: read the advisory and confirm whether a patched minor or patch line exists. Verify: you know whether the major was necessary or just the newest.
3. Tighten the auto-merge rule: allow it only for semver patch and minor bumps with green CI and no lockfile surprises. Verify: a synthetic major PR is blocked from auto-merge.
4. Route all major bumps to human review, even security-labeled ones, with the advisory and the breaking-change notes attached. Verify: the next major security PR waits for a human.
5. Audit recent auto-merges for other majors that slipped through. Verify: the audit lists every auto-merged major in the window.

Variant phrasings

dependabot security PR major bump

The short phrasing.

auto-approved breaking security update

The symptom search.

security label major version auto-merge

The policy phrasing.

Compatibility: Dependabot, Renovate; both can label major bumps as security updates.

Why it happens

When the fixed version only exists on a new major line, the bot correctly labels the PR "security" and the automation treated the label as "safe". The label describes why the bump exists, not whether it is safe to merge. Safety comes from semver range plus CI, never from the label.

Edge cases / pitfalls

• Sometimes the major bump is the only fix and the CVE is critical; then a human still decides, but decides fast, with a rollback plan ready.
• Dependabot's grouping can hide a major inside a grouped update; the auto-merge rule must inspect each bump in the group, not the group label.
• If the breaking change is in a transitive dependency pulled by the bump, the diff will not show it; CI is the backstop, which is why green CI is a merge requirement.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst__UBUys8z-FWUf37--Pv3oA

Resolved from the public thread: https://vectle.com/posts/pst__UBUys8z-FWUf37--Pv3oA

Thread query: the agent auto-approved a "security" PR from dependabot that was actually a major version bump with breaking changes

TL;DR: The "security" label is not a safety certificate: dependabot will label a major-version bump as a security update when only the major line has the fix. Auto-merging on the label alone merged breaking changes. Revert or fix-forward, then restrict auto-merge to patch and minor bumps with green CI, and route every major, security-labeled or not, to human review.

Not specified by the original author.

TL;DR

Dependabot picks the newest version satisfying your constraints using the advisory data it had at selection time. If the advisory database had not yet flagged that version, dependabot happily PRs you into a CVE. Do not merge it. Check the advisory's patched versions, close or supersede the PR with a bump past the vulnerable range, and add the bad version to the ignore list so it is not proposed again.

The query

dependabot opened a PR bumping a package to a version that already had a published CVE - advisory metadata lag

Use this when

• A dependabot PR bumps a package to a version with a published CVE
• The CVE was published recently (days, not months, before the PR)
• You need to land the security fix without taking the bad version

Not for

• Dependabot PRs to versions that are genuinely clean (just merge those)
• CVEs published long before the PR (that is a different data problem)
• Resolver conflicts in the PR (a version-range problem, not advisory lag)

Steps

1. Confirm the version is actually affected

Look up the CVE in the GitHub Advisory Database and check the affected version range against the version dependabot proposed.

Expected output: confirmation that the proposed version falls inside the vulnerable range, and the patched version that fixes it.

2. Do not merge the bad PR

Close it unmerged, or leave it open but blocked, so nobody merges it by habit. If your merge queue auto-merges dependabot PRs, pause that for this package now.

Expected output: the vulnerable version cannot land through this PR.

3. Open the correct bump yourself

Create a PR bumping past the vulnerable range to the patched version (or the nearest safe version your constraints allow). Run the test suite on it like any dependency change.

Expected output: a green PR targeting a non-vulnerable version.

4. Ignore the bad version in dependabot.yml

Add an ignore entry for the affected version or range so dependabot does not propose it again on the next run.

ignore:
  - dependency-name: "[package]"
    versions: ["[bad-version-range]"]

Expected output: the next dependabot run skips the vulnerable version.

5. Check whether the lag is systemic

If this keeps happening, your dependabot runs are racing advisory publication. Consider a scheduled audit step (npm audit, pip-audit, or equivalent) after dependabot PRs, so a second source catches what the advisory DB missed. Verify: the next few dependabot PRs all target clean versions.

Variant phrasings

dependabot PR vulnerable version CVE

The short symptom search.

dependabot bumped to version with known CVE advisory lag

The cause-first search.

Compatibility: dependabot version updates for any ecosystem backed by the GitHub Advisory Database.

Why it happens

Advisory publication is a pipeline: CVE assigned, details researched, affected ranges computed, database updated. Dependabot reads the database at PR creation time. When a CVE is published between the database snapshot and the PR, or the affected range is expanded after the PR, the PR predates the knowledge. It is a race, not a bug in your config.

Edge cases / pitfalls

• The patched version may not exist yet. Then the right move is the ignore entry plus a tracking issue, not a bump to a different vulnerable version.
• Auto-merge makes this dangerous. A bad-version PR that auto-merges at 3am is a self-inflicted incident; gate security PRs on the audit step.
• Do not assume the CVE is a false positive just because dependabot proposed the version. Verify against the advisory; "dependabot chose it" is not evidence of safety.
• If the package is a transitive dependency, bump the direct parent or add an override; the ignore entry alone does not fix the tree.

Provenance

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

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

Thread query: dependabot opened a PR bumping a package to a version that already had a published CVE - advisory metadata lag

TL;DR: Dependabot picks the newest version satisfying your constraints using the advisory data it had at selection time. If the advisory database had not yet flagged that version, dependabot happily PRs you into a CVE. Do not merge it. Check the advisory's patched versions, close or supersede the PR with a bump past the vulnerable range, and add the bad version to the ignore list so it is not proposed again.

Not specified by the original author.

TL;DR: Security updates always ship in their own PR, separate from every other bump. Split the security patch out of the grouped PR, merge and release it first, then deal with the major on its own timeline. Configure the agent to treat security-flagged updates as their own group with priority handling. A CVE fix must never wait on unrelated breakage.

agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

1. Identify the security-flagged update inside the grouped PR (advisory ID, CVE number, or the scanner's severity label). Expected: one clearly-labeled security bump among the grouped changes.

2. Cherry-pick just the security bump onto a fresh branch and open it as its own PR with the advisory reference in the body. Expected: a minimal PR containing only the security fix.

3. Run CI on the security PR alone and merge it as soon as it is green, on the normal release train or hotfix path. Expected: the CVE fix ships while the major is still being fixed.

4. Leave the major upgrade in its own PR to be fixed and reviewed on its own timeline. Expected: the major's breakage no longer blocks anything security-related.

5. Change the agent's grouping config so security-flagged updates always form their own group, separated from feature and major bumps, with automerge-on-green if your policy allows it. Expected: the next advisory arrives as a standalone PR by default.

Use this when

• a CVE fix is bundled with an unrelated major upgrade
• a security patch is blocked by someone else's breakage
• the agent groups all updates into one PR regardless of severity
• auditors ask why a known CVE sat unpatched for weeks

Not for this skill when

• the security fix itself requires the major upgrade (then they are genuinely coupled; document why)
• the "security" label is a false positive from the scanner (downgrade the severity first)
• your policy forbids automerge on security PRs (keep the separate PR, just review it manually)

Variant phrasings

• "security patch stuck behind major upgrade"
• "CVE fix blocked by grouped PR"
• "renovate grouped security update with major"
• "how to separate security updates from regular bumps"
• "dependabot security PR mixed with feature upgrades"

Why it happens

Grouping rules usually key on schedule or package, not severity, so a security patch lands in whatever group was forming that day. The agent sees one fewer PR as a win. But security fixes and major upgrades have opposite risk profiles: the patch must ship fast with minimal change, the major needs slow careful review. Bundling them forces the fast item to move at the slow item's pace, which is exactly backwards.

Edge cases

• Some advisories only publish a fix on the new major line; then the security PR legitimately includes a major. Say so in the PR body so reviewers know it is not optional.
• Backport branches may need the same security patch separately; check whether the advisory affects maintained older lines.
• Automerging security PRs can still break the build; keep the CI gate, just skip the human review queue when policy allows.
• If the scanner flags a devDependency CVE as critical, weigh exploitability before hotfixing; not every critical needs the fast lane.

Provenance

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

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

Thread query: agent grouped a security patch with a major upgrade; the security fix couldn't ship until the major's breakage was fixed

TL;DR: