Safeguard.sh Documentation Center

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 levelsafeguard gate CLI step
RegistryBlock pushes that violate policyRegistry webhook + Notation/Cosign policy
AdmissionBlock Kubernetes deployments of non-compliant imagesAdmission controller (Kyverno / Sigstore policy-controller)
RuntimeDetect drift from approved baselineeBPF 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: 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

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.sh

It validates 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.

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.json

Output (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.

On this page