Test enforcement with three pull requests: one that should pass, one that should be blocked and one that should be blocked, then overridden with a recorded reason. If a product only warns, or the override leaves no trace, it fails the feature a report may have scored as present.
Why a score is not enough
A report can confirm a product has policy features. Forrester says its scores draw on questionnaires, demos, reference interviews and analyst expertise. A policy engine demonstrated on sample data does not show how it behaves in your repositories, with your branch rules and your developers' habits.
The three pull request test
- The clean change. Open a pull request that adds a dependency that should pass. Confirm it passes quickly and says why.
- The blocked change. Open one that adds a dependency that violates a rule you wrote, such as a disallowed license or a known exploited vulnerability. Confirm it is blocked and the message tells the developer what to do.
- The override. Request an exception. Confirm that it needs the right approver, requires a reason and is recorded with a time and name.
Questions beyond the three tests
- Where does enforcement run? In the pull request, in CI, at the registry or at deploy time?
- Can a developer bypass it quietly? Check branch protection and token permissions.
- How are rules written? In code, a UI or both? Can you version them?
- What is the failure mode? If the policy service is down, does the pipeline fail open or closed? Pick which you want.
- How fast is it? Add a stopwatch. A gate that adds minutes to every build will be resisted.
Check the rules you can express
Write five real rules from your own policies. Examples: no copyleft licenses in shipped code, no packages with a known exploited vulnerability, no packages below a minimum maintenance bar. CISA tells organizations to use its exploited vulnerabilities catalog as an input to prioritization, which makes it a reasonable source for the second kind. If the product cannot express your rules, that is a gap whatever the report says.
Measure developer friction
Ask two developers to use each product for a week. Count blocked pull requests and ask how many blocks were useful. A gate people trust gets left on.
Evidence for auditors
Ask how policy decisions are logged. A clear record of what was blocked, what was allowed and who overrode it is useful when an auditor asks how a control operates.
Try it yourself
Open the demo and watch a pull request pass through a gate. Look at what the developer sees on a block.
Click through it at your own pace, or open it full screen.
Safeguard offers policies, gates and guardrails, and the free scan at gold.safeguard.sh/scan is a quick way to see findings on your own repository first.
Quick check
Should gates block or only warn at first?
Many teams start in warn mode to learn the noise level, then move to block for high confidence rules.
Who should approve overrides?
A named role outside the requesting developer's team, such as security or the service owner, with a reason recorded.
Sources
Last reviewed: 19 October 2026.
