Introducing Safeguard Guardrails: Automated Policy Enforcement for Your Supply Chain

We are launching Safeguard Guardrails today. It is the feature our customers have been asking for since we launched policy gates: the ability to define supply chain security policies once and have them enforced automatically across every project, every pipeline, and every deployment.

Policy gates tell you pass or fail. Guardrails tell you why, suggest how to fix it, and can block or allow automatically based on configurable thresholds. It is the difference between a traffic light and a guardrail on a mountain road -- one tells you to stop, the other keeps you on the road.

What Are Guardrails?

Guardrails are configurable policy rules that evaluate your software supply chain continuously. Each guardrail checks a specific condition and responds with one of four actions:

• Allow -- the condition is met, proceed normally
• Warn -- the condition is not ideal, but not blocking. Developers see a warning with remediation guidance.
• Block -- the condition is a hard failure. Deployment is blocked until the issue is resolved.
• Quarantine -- the condition is severe enough to quarantine the affected artifact pending security review.

You define guardrails at the organization level, and they apply to all projects within scope. Individual projects can have additional guardrails but cannot weaken organization-level ones.

Built-in Guardrail Categories

We ship with five categories of pre-built guardrails. Each includes sensible defaults that you can customize.

Vulnerability Guardrails

• Critical CVE blocking -- block deployments with unresolved critical CVEs. Default: block. Configurable by severity threshold and age.
• KEV blocking -- block deployments with components in CISA's Known Exploited Vulnerabilities catalog. Default: block, no exceptions.
• Vulnerability age limits -- warn or block when vulnerabilities remain unresolved beyond configurable timeframes. Default: warn at 30 days, block at 90 days for high severity.
• VEX-adjusted severity -- when VEX documents indicate a vulnerability is not exploitable, adjust the effective severity. Default: reduce severity by one level for "Not Affected" with reachability evidence.

License Guardrails

• License allowlist -- define permitted licenses (MIT, Apache-2.0, BSD-2-Clause, etc.) and block components with other licenses. Default: warn on copyleft, block on AGPL and SSPL.
• License conflict detection -- detect license combinations that are legally incompatible. Default: block on detected conflicts.
• Unknown license detection -- flag components where the license could not be determined. Default: warn.

SBOM Quality Guardrails

• Minimum quality score -- enforce a minimum SBOM quality score across all five dimensions (completeness, accuracy, freshness, depth, actionability). Default: warn below 70, block below 50.
• Required fields -- ensure all SBOM components have required fields (PURL, hash, license, supplier). Default: warn on missing PURL, block on missing hash.
• Freshness enforcement -- block SBOMs that are older than a configurable threshold relative to the latest code change. Default: warn at 7 days, block at 30 days.

Dependency Health Guardrails

• Maintainer risk -- flag dependencies with high maintainer risk scores (single maintainer, low activity). Default: warn at risk score 7+, block at 9+.
• Dependency age -- flag dependencies that have not been updated in a configurable period. Default: warn at 12 months, block at 24 months.
• Deprecated package detection -- block or warn when deprecated packages are detected. Default: warn.
• Known malicious package detection -- block packages that appear in known malicious package databases. Default: block, no exceptions.

Attestation Guardrails

• SLSA level enforcement -- require minimum SLSA provenance levels for dependencies. Default: warn when SLSA L1 not present.
• Signature verification -- require Sigstore signatures for container images. Default: warn when not present.
• Provenance verification -- verify that build provenance matches expected build systems and source repositories. Default: warn on mismatch.

Custom Guardrails

Built-in guardrails cover the common cases. Custom guardrails let you encode your organization's specific policies.

Custom guardrails use a declarative rule language:

guardrails:
  - name: "no-chinese-dependencies"
    description: "Block components from specific registries"
    condition:
      field: "component.purl"
      operator: "not_matches"
      value: "pkg:npm/@specific-registry/*"
    action: "block"
    message: "Components from unapproved registries are not allowed."

  - name: "maximum-dependency-count"
    description: "Warn when dependency count exceeds threshold"
    condition:
      field: "sbom.component_count"
      operator: "greater_than"
      value: 500
    action: "warn"
    message: "This project has more than 500 dependencies. Consider reducing."

Custom guardrails can reference any field in the SBOM, vulnerability data, or project metadata. They support logical operators (AND, OR, NOT), numeric comparisons, string matching, and date-based conditions.

How Guardrails Integrate

Guardrails evaluate continuously, not just at deployment time. Here is how they fit into your workflow:

IDE integration. Through the Safeguard MCP Server, developers see guardrail status while coding. Add a new dependency that triggers a license guardrail? You see the warning immediately, before you even commit.

CI/CD integration. Guardrails run as part of your build pipeline. A blocking guardrail fails the build with a clear error message and remediation steps. Non-blocking guardrails add annotations to your build output.

Desktop app integration. The Safeguard Desktop App shows guardrail status in real time for all tracked projects. The SBOM diff view highlights changes that would trigger guardrails before you push.

Dashboard integration. The Safeguard web dashboard shows organization-wide guardrail compliance. Which projects are in violation? What are the most common violations? What is the trend over time?

Notification integration. Guardrail violations can trigger notifications through Slack, email, PagerDuty, or webhooks. Configure escalation based on severity -- warnings go to Slack, blocks go to email, quarantines page on-call.

Exception Management

Real-world policy enforcement needs exceptions. A critical production fix should not be blocked by a license warning on a transitive dependency. Guardrails support exceptions with:

• Time-limited waivers -- "ignore this violation for 7 days while we work on a fix"
• Scope-limited exceptions -- "this guardrail does not apply to internal tooling projects"
• Approval-based overrides -- "a security lead must approve any exception to KEV blocking"

All exceptions are audit-logged. You always know who approved what exception, when, and for how long.

Pricing and Availability

Guardrails are available today for all Safeguard.sh plans. The free tier includes up to 5 custom guardrails. Professional and Enterprise plans include unlimited custom guardrails plus guardrail analytics and compliance reporting.

How Safeguard.sh Helps

Safeguard Guardrails transforms supply chain security from a periodic audit into continuous enforcement. Define your policies once, and Guardrails enforces them automatically across every project, every pipeline, and every deployment. With built-in rules for vulnerabilities, licenses, SBOM quality, dependency health, and attestation -- plus unlimited custom rules -- Guardrails ensures your entire organization stays within your security boundaries. Try Guardrails today at safeguard.sh.