Describe layers: checks when a dependency is added, a gate in the build, and a review step before deploy, each with a defined exception path. Say what blocks and what merely warns, because customers care about enforcement more than tooling.
Why "we scan" is not an answer
Scanning finds. A gate decides. A customer asking how vulnerable open source is kept out of production wants to know which findings stop a release and who can override. NIST SP 800-218 includes the example of building automatic detection of known vulnerabilities into the toolchain (PW.4.4) and of reviewing provenance and composition data automatically for new vulnerabilities (RV.1.1).
The layers
| Stage | Check | Typical action |
|---|---|---|
| Pull request | New or changed dependencies matched to advisories and license rules | Block or comment |
| Build | Inventory generated and checked against policy | Fail on defined rules |
| Pre deploy | Image and package scan, exploitation signal | Hold for review |
| Runtime | Ongoing matching of the shipped inventory to new advisories | Create a ticket |
State which of these you have today. Do not describe the runtime layer if you scan at build alone.
Decide what blocks
Write a short rule, for example: block when a component has a known exploited vulnerability that is reachable, or a license on the deny list. Warn on everything else and track it. A gate that blocks too often gets disabled, which is worse than a modest gate that holds.
Exceptions
Every gate needs an override. Record who approved, why, the compensating control and an expiry date. Customers who ask for evidence will often ask for an exception list, so keep it clean.
Reply template
Dependency changes are checked on each pull request and again in the build against vulnerability and license rules. Defined conditions block the change. Exceptions require a named approver and an expiry date. After release, the shipped inventory is rechecked against new advisories.
Making the answer believable
Customers who press on this topic often ask for an example of a blocked release. Keep one on file, with names removed: the change, the rule that stopped it, who looked at it and how it was resolved. A block that was then fixed properly shows the gate and the people both work.
Also be ready for the opposite question: what happened when a gate was overridden? If the exception log is empty, the customer may suspect nobody checks. A small number of recorded, expiring exceptions is a healthy sign.
Try it yourself
Click through it at your own pace, or open it full screen.
Trigger the gate in the demo and read why it stopped the change. A clear reason is what turns a block into something developers accept.
Safeguard provides policies, gates and guardrails for pull requests, plus reachability analysis to help separate exploitable findings from noise.
Quick check
Should every medium severity finding block a build?
Usually not. Block on exploitable and exploited issues, track the rest with owners and dates.
What do we show a customer as proof?
The written rule, a screenshot or export of a blocked change, and the exception log with sensitive details removed.
Sources
Last reviewed: 19 October 2026.
