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 | safeguard gate CLI step |
| 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 | Detect drift from approved baseline | eBPF runtime collector |
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
The Kubernetes admission controller ships as a Helm chart:
helm install safeguard-admission safeguard/admission-controller \
--namespace safeguard-system \
--set policy.mode=enforce \
--set policy.source=cluster-policies.safeguard.shIt validates 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.
For dry-run rollouts, set policy.mode=audit — the controller logs violations without denying.
CI Gate
The safeguard gate CLI exits with a non-zero code when any blocking rule matches, and writes a machine-readable JSON report:
# .github/workflows/ci.yml
- name: Safeguard gate
run: safeguard gate --policy ./policies/ --sbom ./sbom.cdx.jsonOutput (stdout):
$ safeguard gate --policy ./policies/ --sbom ./sbom.cdx.json
Evaluating 14 policies across 1 SBOM (487 components)...
BLOCK no-known-exploited-critical log4j-core@2.17.1 (CVE-2021-44832, KEV)
WARN license-allow-list proprietary-lib@1.2.3 (MIT-0 not on allow-list)
PASS requires-sbom-attestation
PASS requires-slsa-l3
Result: BLOCK (1 blocking violation)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.