Guardrails & Enforcement
Policy-as-code guardrails enforced across CI/CD, registries, runtime, and procurement.
Guardrails & Enforcement
A guardrail is a rule that Safeguard enforces on your behalf. Unlike a scanner that only reports, a guardrail blocks, gates, or auto-remediates — at the moment a risk appears in your pipeline.
Enforcement Points
Guardrails can be enforced at six points in the software lifecycle:
| Point | What's enforced | Mechanism |
|---|---|---|
| IDE | Pre-commit checks for vulnerable packages, secrets, insecure patterns | Safeguard IDE extension |
| Commit | Server-side checks via API / webhook before merge | GitHub / GitLab checks API |
| CI | Gate on SBOM, license, CVE, signing, SLSA level | Platform policy gates on the scans of connected repositories |
| Registry | Block pushes that violate policy | Registry webhook + Notation/Cosign policy |
| Admission | Block Kubernetes deployments of non-compliant images | Admission controller (Kyverno / Sigstore policy-controller) |
| Runtime | Requests, SQL queries, commands, file paths, outbound calls, LLM calls and MCP tool calls checked against your guardrails (early access) | Safeguard Guard, at the library and framework level inside your application, as middleware |
Every guardrail produces a signed audit record. Auditors can replay any enforcement decision.
The Policy Language
Guardrails are defined in YAML. Each policy has a target (what it applies to), one or more rules, and an effect.
apiVersion: safeguard.sh/v1
kind: Policy
metadata:
name: block-critical-cves-in-prod
spec:
targets:
- kind: Image
labels:
env: production
rules:
- id: no-known-exploited-critical
description: Block production images containing KEV-listed CVEs.
condition: |
any(
vulnerabilities,
severity == "critical" AND kev == true
)
effect: BLOCK
exception:
allowed: false
approvers: ["security-leads@company.com"]
- id: requires-sbom-attestation
condition: attestations.sbom == null
effect: BLOCK
- id: requires-slsa-l3
condition: slsa.level < 3
effect: WARNRules evaluate against a document that combines SBOM, vulnerability, license, signature, provenance, and reachability data. Effects are BLOCK, WARN, or AUTO_FIX.
Built-In Guardrails
Safeguard ships with curated guardrails you can enable with one click:
- KEV in production — block images with any CVE on CISA's Known Exploited Vulnerability list.
- EO 14028 SBOM required — require a CycloneDX SBOM attestation signed in the last 90 days.
- SLSA level 3 provenance — require a Sigstore-verifiable provenance attestation.
- License allow-list — block deployment of any component with a non-allow-listed license.
- Abandoned package — block deployment of any package with zero commits in 365 days and a CVE open > 180 days.
- Unsigned container — block pods pulling images without a valid Cosign or Notation signature.
- Typosquat detected — block any package whose name is within edit-distance 2 of a top-1000 package but not owned by the expected publisher.
- AI model provenance — block loading model weights that do not have a signed model card.
Auto-Fix Guardrails
With Griffin AI integrated, certain guardrails can auto-remediate instead of blocking.
Example: a CI guardrail detects that a dependency upgrade introduces a CVE. Instead of failing the build, Griffin opens a PR that pins the dependency to the last safe version, updates the lockfile, and re-runs tests.
Auto-fix guardrails require a pre-approved scope (which repos, which package ecosystems, which severity bands). See Auto-Fix.
Exceptions and Breakglass
Every blocking guardrail supports time-boxed exceptions:
- An approver with the right role can grant an exception for a specific asset for a specific duration.
- Exceptions appear in the audit log and expire automatically.
- Emergency breakglass exceptions require two-person approval and trigger alerts in the security channel.
Enforcement at Admission
Not available yet. The Kubernetes admission controller is not published, so there is nothing to install. Earlier revisions of this page showed a helm install command for an admission controller chart that does not exist. Don't install a chart that claims to be Safeguard's admission controller.
Safeguard's own Helm chart is for Guard, not the admission controller. It is an OCI chart at oci://registry.safeguard.sh/charts/guard, in early access, and pulling it requires a Safeguard pull token. See Guard SDK for how Guard installs.
The admission controller is designed to validate every pod spec against the image policy:
- Resolve the image digest.
- Fetch SBOM and signature from the registry or Safeguard Portal.
- Evaluate applicable policies.
- Admit, warn, or deny.
CI Gate
Gates are evaluated by the platform on the scans it runs for your connected
repositories, not by a command in your pipeline. The CLI has no gate
command, and safeguard scan reports findings without failing the build on
them. See CI/CD Integration for what a pipeline can
run today.
Procurement Guardrails
TPRM extends guardrails to vendor intake:
- Require a signed SBOM from the vendor before contract signing.
- Block vendors whose SBOMs contain components with active critical CVEs.
- Require attestation of NIST SSDF practices for vendors handling regulated data.
See TPRM for procurement-specific policies.
Observability
Every guardrail decision is:
- Logged to the Safeguard audit stream.
- Emitted as OpenTelemetry span for SIEM ingestion.
- Counted in the Enforcement dashboard (allow/warn/block trends by policy, team, asset class).
Use this to measure guardrail health — a policy that fires a BLOCK thousands of times per week probably needs either auto-fix or a policy refinement.
Related
- Policies and Gates — UI for creating and managing policies.
- Auto-Fix — Griffin AI auto-remediation capabilities.
- CI/CD Integration — adding the gate to pipelines.
- Attestation — signed evidence that guardrails consume.