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.

```text
CI scanner gate: FAIL - new CVE-2026-ZZZZZ in transitive dep [pkg] introduced by this PR
```

1. 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.
2. 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.
3. 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.
4. 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.
5. 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