Developers should confirm facts about their own code, such as whether a package ships and whether the call path exists, while the security or platform team owns the rules: which tool gates, which data sources count, and the tie break. Put a short time limit on each step so a disagreement never blocks a merge for days.
Why disagreements stall
A developer sees two comments with different advice and asks the security team. The security team is busy and replies a day later. Meanwhile the pull request waits. Nobody has authority to say which tool wins, so the conflict is escalated again and again.
The fix is not more meetings. It is a short written rule about who decides what.
A role split
| Decision | Owner | Why |
|---|---|---|
| Does this package ship in my service? | Service developer | They know the build |
| Is the vulnerable code reachable in my code? | Service developer, with AppSec support | They know the code |
| Which tool gates the merge? | AppSec or platform | One consistent answer across teams |
| Which advisory data counts for the gate? | AppSec | A policy question |
| Is an accepted risk allowed? | Service owner plus AppSec approval | Shared accountability |
| How are conflicts logged? | AppSec | One record |
Adjust the names to your org, but keep one owner per row.
A default rule
Write a tie break that applies when nobody has time. For example: the designated gating tool decides whether the merge is blocked. The other tool's findings are reviewed within a set time and never block by themselves. A developer can request an override with a one line reason, and the security team reviews overrides weekly.
This keeps work moving and puts the real discussion where it belongs, in a scheduled review.
Time limits
Pick limits you can meet.
- Developer triage: same working day for a blocking finding.
- AppSec answer to an escalation: next working day.
- Accepted risk review: weekly batch.
- Rule changes: monthly, with notes to all teams.
If a limit is missed, the default rule applies automatically. That is the whole point of having one.
Keep a record
Use a log with one row per disagreement and the decision made, such as the one described in our reconciliation template post at /resources/blog/a-reconciliation-log-template-for-scanner-disagreements. Over time it shows which disagreements recur and which rule changes would remove them.
Communicate the rule
Put the rule where developers work: the contributing guide and the pull request template. A rule nobody reads does not prevent escalations. Also tell developers what a good escalation contains: the package and version, both tool outputs, and what they already checked.
Review it
Revisit the split after a quarter. If one team generates most escalations, they may need training or a configuration fix. If most overrides are granted, the gate may be too strict. If few are granted, the rule may be working or may be discouraging requests, so ask developers.
Quick check
Should developers be allowed to override a block?
Yes, with a written reason and a review. An override path prevents workarounds that bypass the tool entirely.
Who picks the gating tool?
The security or platform team, once, for everyone, so the answer is consistent across teams.
Last reviewed: 19 October 2026.
