A Blocked Merge Is Not a Dead End
A blocked merge is not a dead end. It’s a decision that needs to be made and recorded. When a policy blocks, the pull request gets the finding, the rule that fired, and the evidence. From there you have three honest routes.Route 1: Fix It
Upgrade or replace the component. The next scan re-evaluates and the gate clears on its own.Route 2: Correct the Finding
If the finding is wrong, because your own code matched its published copy or the wrong package was identified, triage it properly. Marking something original removes it from the gate because it genuinely doesn’t apply.Route 3: Request an Approval
Sometimes the risk is real, understood, and accepted. From the finding, request a Policy Approval. It asks you for three things:- A category for why it doesn’t apply or is tolerable: the vulnerable code isn’t reachable, mitigations are in place, it’s under investigation, and so on.
- A justification in your own words.
- An expiry: 30 days, 90 days, a date you choose, or never.
Give a request an expiry. An approval with no expiry is a decision
nobody will revisit. The Dashboard tracks how many are active and warns
you when they’re about to lapse. Use that.
Finding What’s Waiting on You
An Admin doesn’t have to open policies one at a time to find pending requests. The project’s Policies page has an Approvals tab, alongside All Policies and Needs Attention, counting what’s still awaiting a decision across every policy attached to the project. It counts pending requests only, so it returns to zero once the queue is clear. Approve or reject straight from the row. The Status filter switches to Approved, Rejected, or Revoked, which is also where an approval already granted can be revoked.The queue covers one project at a time.