How would you handle a pre-existing backlog of medium-severity security findings that predates your new scanning rollout, without blocking every team's work on day one?

Don't gate merges on the pre-existing backlog at all — only gate on new findings introduced going forward, exactly as designed — and handle the backlog as a separate, tracked, prioritized remediation effort with its own timeline, visibility, and ownership, rather than retroactively making every team's current work blocked by debt they didn't create today.

The key principle is separating two genuinely different problems that are easy to conflate: preventing new risk from entering the codebase (which the gating design already handles by only blocking on newly-introduced high/critical findings) and remediating existing risk that's been present, unaddressed, for some time already. Gating merges on the full backlog would mean every team's routine work — completely unrelated to the security debt — gets blocked by findings someone else's code introduced possibly years ago, which is both unfair and, practically, causes exactly the "engineers route around or ignore the gate" failure mode a credible security program needs to avoid.

The practical handling: surface the backlog as its own tracked work, separate from the PR-gating mechanism entirely — a dashboard or ticket-tracker view of the accumulated findings, prioritized by actual severity and exploitability (not just the scanner's raw severity label, which doesn't always reflect real-world risk in context), with clear ownership assigned per repository or team. This makes the backlog visible and actionable without being a blocking gate on unrelated work.

Prioritization for the backlog itself should weigh real risk, not just count: internet-facing services carrying a known-exploitable vulnerability are a different priority than an internal tool with a theoretical finding that's hard to actually exploit given the system's real exposure. A blanket "fix everything, in severity order, regardless of context" approach tends to burn effort on low-real-risk findings while genuinely dangerous ones queue behind them just because of label severity rather than actual exploitability.

A reasonable middle ground some organizations use: set a remediation deadline policy going forward (e.g. "critical findings, once identified, must be fixed within 7 days; high within 30") that applies to both new and existing findings, giving the backlog a real, tracked timeline without making it an immediate PR-blocking gate — this creates accountability without the immediate-blocking problem, and can be escalated (director visibility, blocking gate after the deadline passes) for items a team isn't addressing.

• Keep PR-gating scoped to newly-introduced findings only — don't retroactively block unrelated work on pre-existing debt.
• Track the backlog separately, with clear ownership and visibility, rather than leaving it invisible until someone happens to look.
• Prioritize backlog remediation by actual risk/exploitability, not just the scanner's raw severity label.
• A remediation-deadline policy (with escalation after the deadline) creates real accountability without the immediate-blocking problem a hard gate would cause.

• OWASP: DevSecOps Guideline
• NIST: Guide to Enterprise Patch Management Planning