When product security wants a gate to block and platform worries about broken builds, run the gate in advisory mode for a fixed trial, measure false positives and build time, then decide against criteria agreed beforehand. Name the tiebreaker before the argument starts. Data and a date turn opinions into a decision.
Why this disagreement is healthy
Both positions are legitimate. Product security carries the risk of letting a bad change through. Platform carries the cost of stopping every developer. Neither is wrong, and a gate that satisfies only one of them will not last. If it is too soft, it is ignored. If it is too hard, it gets bypassed.
A five step resolution path
- State the risk in one sentence. For example: a known exploited vulnerability could reach production through a dependency update.
- Agree the success measures. Typical ones are the share of blocked builds that were real issues, added minutes per build, and number of bypass requests per week.
- Run advisory mode for two to four weeks. The gate reports but does not stop the build.
- Review the numbers together. If most blocks would have been real, move to blocking. If noise is high, tune the rule first.
- Record the decision, the rule, the date and the approver in the tracker.
Pick the tiebreaker up front
Decide who breaks a tie before anyone needs one. Common choices are the head of engineering for delivery impact or the security lead for risk acceptance, depending on your policy. NIST SP 800-218 task PO.2.3 suggests obtaining upper management commitment and gives the example of appointing a single leader responsible for the secure development process, including release to production. That leader is a natural tiebreaker.
Start narrow, widen later
Rather than debating all findings, block a small set first. Known exploited vulnerabilities and critical issues in reachable code are a defensible starting point because few teams will argue they should ship. Expand after the first rule has settled. SSDF PO.4.1 includes the example of adding security criteria to existing checks, such as an agile team's definition of done, which is a gentler route than a new standalone gate.
Give developers a fast path
Every blocking gate needs a documented way through for emergencies, with an approver and an expiry, so the record shows each bypass. Without it, teams build their own workarounds. The post on who owns CI security gates covers the ownership split in more detail.
Try it yourself
Click through it at your own pace, or open it full screen. Use it to see how exploitability context can narrow a blocking rule to findings that matter.
Where Safeguard fits
Safeguard offers policies, gates and guardrails plus reachability analysis, which helps narrow a block to findings that are actually reachable. A free scan lets both teams look at the same sample results before the debate.
Quick check
Is advisory mode a cop out?
Not if it has an end date and a decision at the end. Advisory with no review date quietly becomes permanent.
How many bypasses are too many?
There is no universal number. Watch the trend. A rising count usually means the rule is too noisy or the fix path is too slow.
Sources
- NIST SP 800-218, Secure Software Development Framework 1.1, tasks PO.2.3 and PO.4.1.
Last reviewed: 19 October 2026.
