Stop the risky dependency at merge, not three sprints later.
OSPulse policy gates run in your pipeline and fail the build that introduces a compromised or actively-exploited dependency, while everything below your threshold flows through. Baselines and expiring exceptions mean you can turn it on across a large estate without breaking every pipeline on day one.
Four steps, and none of them is a rip-and-replace.
Write the policy once.
Set the thresholds that matter to you: a minimum health score, no actively-exploited components, no unacknowledged critical advisory, an SBOM on every release. It lives with your OSPulse config, not scattered across a dozen pipeline YAMLs.
Run the gate in the pipeline.
The OSPulse CLI runs in any CI system and returns a clean pass or fail with the reasons attached. No agent to babysit, no separate dashboard to reconcile against the build log.
Fail the build that earns it.
A merge that introduces a compromised or actively-exploited dependency stops at the gate, with the evidence in the check output. Everything below your threshold flows through untouched, so the signal stays trusted.
Roll it out without a revolt.
Baselines let you adopt the gate on a large estate without failing every existing build, and exceptions expire on a date you set, so a temporary waiver does not quietly become permanent.
The gate, at a glance.
| Runs in | Any CI system, via the OSPulse CLI |
|---|---|
| Ecosystems | npm, PyPI, Maven, NuGet, Go, Cargo, RubyGems, Composer, Docker |
| Gate on | Health score, active exploitation, advisory severity, missing SBOM |
| Adoption | Baselines plus expiring exceptions |
| Output | Pass or fail with the evidence in the check |
| SBOM | CycloneDX and SPDX on every gated release |
Frequently asked
Will turning this on break all our builds?
Not if you baseline first. A baseline accepts the current state of an estate so the gate only fails on new risk introduced from that point, and you tighten the thresholds over time rather than in one painful afternoon.
Can teams get an exception for a known issue?
Yes, and every exception carries an expiry date you set. The waiver clears the gate until then and reappears automatically when it lapses, so nothing rots into a permanent hole.
Which CI systems does it work with?
The gate is the OSPulse CLI with an exit code, so it runs anywhere you can run a command: GitHub Actions, Azure Pipelines, GitLab CI, Jenkins, and the rest. There is no bespoke plugin to keep alive.
Does it gate on more than known CVEs?
Yes. You can fail a build on active exploitation and on supply-chain compromise signals, not only on published CVEs, which is the whole point of catching a bad dependency at the moment it is introduced.
Put a gate on your pipeline.
Start with the free health check, then wire the CLI into CI when you are ready to gate.