the patch PR's CI failed on the agent's own scanner gate - the fix introduced a new CVE in a transitive dependency
Fixes a patch PR whose CI fails on the agent's own scanner gate because the fix pulled in a new CVE through a transitive dependency. Use it when a security bump introduces a different vulnerability and the pipeline blocks the merge. Key trigger: the scanner gate reports a CVE in a package you did not directly change.
TL;DR: Run the scanner on the PR branch before merging and treat the gate as part of the fix, not a surprise after it. When the bump introduces a new transitive CVE, either pin the transitive dependency to a clean version, pick a different fixed version of the direct dependency, or take an explicit short-lived exception with an expiry. Never merge past the gate by disabling it.
CI scanner gate: FAIL - new CVE-2026-ZZZZZ in transitive dep [pkg] introduced by this PR- Identify which direct dependency pulled in the vulnerable transitive package: check the lockfile diff in the PR. Expected: you see the dependency chain, for example a direct bump from 2.1 to 2.2 dragging in a transitive 0.9 that carries the CVE.
- Check whether a newer patch of the direct dependency avoids the bad transitive: read its changelog or try the next version. Expected: you find a version whose transitive tree is clean, or confirm none exists yet.
- If a clean combination exists, pin the transitive dependency to the fixed version in the PR and re-run the gate. Expected: the scanner gate passes.
- If no clean combination exists, choose deliberately: a different remediation for the original CVE, or a time-boxed gate exception (30 days) with a ticket to revisit. Expected: the decision and its expiry are recorded, not just a bypass.
- Re-run the full CI including the scanner gate. Expected: green, with the exception (if any) visible in the gate output.
Use this when
- a security PR introduces a new CVE
- the scanner gate fails on transitive dependencies
- the fix is correct in isolation but the merged tree is not clean
- dependabot or snyk PRs keep failing the security gate
Not for this skill when
- the gate flags the original CVE as unfixed (the patch did not work)
- the CVE is a scanner false positive on the fixed version
- the gate itself is misconfigured or scanning the wrong branch
- the failure is a build or test failure, not a scanner finding
Variant phrasings
- dependabot PR fails security scan
- fix introduced new vulnerability CI blocked
- transitive dependency CVE after upgrade
- scanner gate fails on patch PR
Why it happens
Dependency upgrades move the whole transitive tree, and the new tree can contain a different known CVE. The scanner gate evaluates the merged result, so a fix that is correct in isolation still fails the pipeline when the ecosystem has not published a fully clean combination yet.
Edge cases
- pinning a transitive dep can break the direct dep's peer expectations - run the test suite, not just the gate
- exception expiries must re-trigger the gate or they become permanent - automate the revisit
- two agents patching the same tree concurrently can reintroduce the bad transitive - serialize security PRs per repo
- the "new" CVE may predate your PR and only now be visible because the gate started scanning that path - check first-seen dates before blaming the bump
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_JscBBG5ExBdNNNXcPkP5zA