Put the platform in the pull request as a short, specific comment first, and add a blocking gate only for a small set of agreed rules. Developers accept checks that are fast, accurate, and explain the fix. They route around checks that are slow, noisy, or silent about why they failed.
What the pull request is good for
The pull request is the cheapest moment to catch a risky dependency. The author has context, the change is small, and reverting costs nothing. A finding discovered a year later costs far more to fix.
The check should answer three things about the change: did it add a new dependency, did it raise or lower known risk, and does it break a rule.
Advise before you block
| Stage | Behavior | Goal |
|---|---|---|
| Advise | Comment only, never fails | Build trust, tune noise |
| Soft gate | Fails, but an author can override with a reason | Teach the rules |
| Hard gate | Fails, override needs security approval | Protect against agreed worst cases |
Stay in advise long enough to measure whether comments lead to changes. Move a rule up a stage only when its false positive rate is low.
Rules worth blocking on
Start narrow. Good candidates are a dependency with a known exploited vulnerability and a fixed version available, a package from an unapproved source, and a license your policy forbids. CISA recommends using its Known Exploited Vulnerabilities catalog as an input to prioritization, which makes the first rule easy to justify to developers.
Avoid blocking on every high severity score. Severity alone produces noise. Combine severity with reachability and exploitation.
Design a good comment
- Name the package, version, and the rule it broke.
- Say whether the vulnerable code is reachable.
- Show the fixed version, and a ready change if possible.
- Link to how to request an exception.
- Keep it under ten lines.
A comment that says only failed policy check teaches nobody anything.
Speed and reliability
If the check adds minutes to every pull request, developers will resent it. Cache results and scan only the changed manifests. Decide what happens when the platform is down: failing open keeps work moving, failing closed protects but halts it. Many teams fail open with an alert for the first quarter.
Exceptions without friction
Allow an author to request a time limited exception inside the pull request, routed to the policy owner. Track how many are granted. A flood means the rule is wrong, not the developers.
A worked example
Take a hypothetical team that adds a platform check to its pull requests. In the first month the check only comments. A developer opens a pull request adding a new HTTP client library. The comment appears within a minute: the package, the version, one known advisory, whether the vulnerable code is reachable, and a newer version that fixes it, with a suggested change.
The developer reads it, bumps the version, and pushes. The comment updates to show the finding resolved. No meeting was needed.
In the second month the team turns one rule into a soft gate: a dependency listed in the CISA Known Exploited Vulnerabilities catalog with a fixed version available fails the check. A developer who truly needs the old version can override with a written reason, which goes to the policy owner. Over the month, three overrides are requested and two are accepted for good reasons. The team reviews them and refines the rule to exclude a case where the affected feature is disabled.
In the third month the rule becomes a hard gate. Overrides now need security approval. Because developers saw it work for two months, nobody is surprised.
Comment template
| Section | Content |
|---|---|
| Summary line | Rule name and result |
| Component | Package, version, how it is introduced |
| Why it matters | Advisory, exploitation status, reachability |
| What to do | Fixed version, ready change, or mitigation |
| If you disagree | Link to request an exception |
Handling pull requests from bots and agents
Automated update bots and AI coding agents open many pull requests. Apply the same checks, and add two rules: automated changes to manifests need a human reviewer, and automated pull requests should group related updates to avoid flooding reviewers. A check that is quiet on routine safe updates keeps attention for real problems.
Merge queue and protected branches
Make the check required on protected branches only after you trust it. Combine it with a merge queue so results are fresh. If the platform's data changes between approval and merge, a rerun at merge time avoids merging something that became risky overnight.
Metrics for the check itself
Track the false positive rate, the override rate, the time added to pull requests, and the share of comments that lead to a change. If the override rate climbs, the rule is wrong. If the comment action rate is low, the comment is unclear. Treat the check as a product with users.
Rolling out to a monorepo
Run checks per package path, so a change in one service does not rescan everything. Give each path an owner in a code owners file, and route comments to them.
Try it yourself
Click through it at your own pace, or open it full screen. Look at what the developer sees when a gate fails and how the fix is offered.
Safeguard provides policies, gates, and guardrails, plus dependency scanning and reachability analysis, so a pull request check can carry the reachability note. A free scan at gold.safeguard.sh/scan previews the findings.
Quick check
Should every finding block a merge?
No. Block a short list of high confidence rules and advise on the rest.
Should the gate fail open or closed?
Either can be right. Decide deliberately, and alert on platform outages.
Should bot pull requests skip the check?
No. They change dependencies too. Run the same rules and require human review of the result.
Sources
Last reviewed: 19 October 2026.
