Policy gates: stop vulnerabilities before production

Why alerts aren't enough

Most security tools report after the fact. A finding lands in a dashboard, someone triages it, a ticket goes to the owning team, and in the meantime the release keeps moving. If the finding was missed or the scan never saw the package, the vulnerability is in production before anyone decides anything.

Policy gates can also stop a build in real-time, before the release moves on.

What a gate can stop

Rule	What happens
Findings in the build	A build with findings your policy rules out is blocked.
A specific CVE	Once your team has decided a CVE must not ship, builds that contain it are blocked.
A known malicious release	A malicious release with a published CVE, such as xz, is flagged and can be blocked the same way.
A license	License policy rules can block a build that brings in a license you have ruled out.

A gate is only as good as what it sees

A gate built on a lockfile scan can only block what the lockfile lists. CRACI sees the traffic coming into each build, so its gates work from what the job really pulled in:

• Transitive dependencies at every depth. See transitive dependencies.
• Hidden dependencies, such as code downloaded by install scripts, Rust build scripts that download at build time, and the base image of a container build.
• Packages restored from a CI cache, which are recorded and marked as cached.

Every component in a CRACI SBOM was in the build, so a gate is never working from a package that was only inferred. For the reasoning, see build-time SBOMs.

Gates and egress policy do different jobs

Risk	What stops it
A dependency with a known CVE you ruled out	Policy gate
A license you ruled out	Policy gate
A connection to a host the build does not need	Egress policy, set to default deny
A new malicious package with no advisory yet	Not flagged until an advisory exists. An egress policy set to default deny still blocks it from sending your secrets to a host the build does not need.

When a new CVE lands

1. CRACI re-evaluates monitored SBOMs and flags what is affected.
2. Your security team triages it and sends it to the team that owns the fix.
3. Build history shows which builds contained it, and so how long you were affected.
4. The owning team ships the fix, and a policy gate keeps the CVE out of later builds.

The fix stays yours. The gate makes sure it stays fixed. See vulnerability tracking.

What gates don't do

• No reachability analysis. A gate works from whether a package is in the build, not from whether your code calls the vulnerable function.
• No malware detection. Advisories drive the gate, so a brand-new malicious package is not caught by it.
• No code scanning. SAST and secrets scanning are out of scope by design, and plenty of excellent tools work alongside CRACI.

Policy gates: frequently asked questions

What is a policy gate?

A rule that stops a build when it breaks your policy. Instead of reporting a problem for someone to pick up later, the gate keeps the build from going further.

How is a policy gate different from a scanner alert?

An alert depends on someone acting on it in time. A gate acts by itself. CRACI's gates also work from a record of what the build pulled in, so they can catch packages that a lockfile scan would never see.

Can I block one specific CVE?

Yes. A policy gate can block builds that contain a specific CVE, so that a vulnerability your team has decided on doesn't come back in a later build.

Can a gate block a license?

Yes. Every recorded package carries its declared license, and license policy rules can block a build on a license.

Does a gate stop new malware?

Not by itself. A known malicious release with a published CVE is flagged like any other vulnerability, and a gate can block builds that contain it. A new malicious package isn't flagged until an advisory exists. An egress policy set to default deny is what limits the damage in that window.

Which CI systems work with policy gates?

GitHub Actions, on CRACI runners. Other CI systems are on the roadmap.