Describe the gate as a rule with five parts: what it checks, what it blocks, who can override, how overrides are recorded and what it does not cover. Quote the actual configuration, not the aspiration. A truthful narrow answer beats a broad one that falls apart when the customer asks for a screenshot.
The question behind the question
"Do you block builds with vulnerabilities?" is really "will a known problem reach production without anyone deciding to let it?" The best answer shows that a human decision, recorded somewhere, stands between a finding and a release.
The five parts
What it checks
Name the signals. For example: a new vulnerability introduced by this pull request, severity at or above a level you state, an exploited in the wild flag, and whether a call path reaches the vulnerable code. CISA recommends using its KEV catalog as an input to a prioritization framework, so including it as a gate input is a defensible choice.
What it blocks
Be exact about the action. "Fails the required check on pull requests into the main branch" is a statement. "Prevents insecure code" is a slogan.
Who can override
Name the role, not the person. State whether an override needs a second approver.
How overrides are recorded
Say where the record lives, what fields it holds and for how long it is kept. See what an auditor can replay from an exception trail.
What it does not cover
Give one honest limit. For example: the gate checks pull requests, so a vulnerability disclosed after merge is found by the scheduled rescan instead, which has its own target.
A draft answer
Adjust to match your configuration.
| Part | Draft wording |
|---|---|
| Checks | New findings in each pull request against severity, exploited in the wild status and reachability |
| Blocks | A required status check on the main branch fails when a rule is met |
| Override | Security lead approval, recorded with reason and expiry |
| Record | Exception ticket linked to the pull request |
| Limit | Findings disclosed after merge are handled by the scheduled rescan |
Where reachability fits
Using reachability in a gate means a finding with no call path may pass with a note, while a reachable one blocks. That is a choice you should state, since some customers expect any critical to block. Explain the reason and how unknown results are treated. Treating unknown as blocking is the cautious default.
Check it against reality
Before you submit, open the repository settings and read the rule back. If the answer says required check and the setting says optional, fix the setting or the answer. Customers sometimes ask for proof, and a mismatch costs more than a modest claim.
Try it yourself
Click through it at your own pace, or open it full screen. Watch what the gate checks and what it does when a rule matches.
Quick check
Can we say we block all vulnerable builds?
Only if that is literally true. Most gates block on defined rules, so state the rules.
Do we mention overrides?
Yes. A gate with no override path usually gets bypassed informally, which is worse.
Safeguard provides policies, gates and guardrails that can use reachability and exploitation signals. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
