Safeguard Docs

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:

PointWhat's enforcedMechanism
IDEPre-commit checks for vulnerable packages, secrets, insecure patternsSafeguard IDE extension
CommitServer-side checks via API / webhook before mergeGitHub / GitLab checks API
CIGate on SBOM, license, CVE, signing, SLSA levelPlatform policy gates on the scans of connected repositories
RegistryBlock pushes that violate policyRegistry webhook + Notation/Cosign policy
AdmissionBlock Kubernetes deployments of non-compliant imagesAdmission controller (Kyverno / Sigstore policy-controller)
RuntimeRequests, 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: WARN

Rules 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:

  1. Resolve the image digest.
  2. Fetch SBOM and signature from the registry or Safeguard Portal.
  3. Evaluate applicable policies.
  4. 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.

On this page