From Plain English Security Policy to Release Gates in Safeguard

To turn a written security standard into release gates in Safeguard, you express each rule as a policy, check what that policy matches against your real projects, link it to a gate with an action of Block, Warn or Notify, and add one CI step, safeguard ci scan --wait --fail-on-gate <gate>, so a failed gate fails the pipeline. Policies, gates and guardrails are generally available (GA), and so is creating policies from plain English. The work that remains yours is deciding what the rule should say, reviewing it before it blocks anyone, and wiring the gate into every pipeline that ships.

Key takeaways

• Policies, gates and guardrails are GA. A policy finds matching issues, a gate decides pass or fail from its linked policies, and a guardrail is the broader enforcement layer across the software lifecycle.
• Plain English policy creation and findings generation are GA. You write the rule as a sentence in Search, Griffin turns it into filters, and because a policy runs a starred search you see every match before anything is enforced.
• Each policy has one Action: Block fails the gate, Warn passes it with a named warning, Notify passes it and sends a notification. Approval in the current docs happens through the exception workflow, with an approver, a business justification and an expiry date.
• The CI gate is the Safeguard CLI (GA) running safeguard ci scan --wait --fail-on-gate <gate> in a plain shell step on any CI that runs bash and curl. It needs policy outcomes turned on for your workspace, which Safeguard does on request.
• Runtime enforcement through Guard is early access, and the Kubernetes admission controller is not published yet. The SAST engine that safeguard ci scan runs on the platform is early access, and SAST findings are not part of --fail-on yet.
• Autonomous remediation is GA but ships switched off, every category set to Manual. A gate does not fix anything by itself.
• The Compliance and GRC suite (GA) is where policy results, exception history and evaluation records become audit evidence.

Why a written security standard is not enough

Most organisations already have a secure development standard in a wiki or a PDF: "no critical vulnerabilities in production", "only approved licences", "exceptions require security approval". Engineers read it once. Auditors ask for it every year.

A document cannot stop a merge, and three things go wrong when the standard stays on paper.

Drift. One team gates on critical findings, another on high, a third commented out its scan step during an incident and never restored it. Nobody can say which repositories meet the standard.

Invisible exceptions. Without a system, exceptions become a chat message or a CI variable that skips the scan. They never expire and nobody reviews them.

No evidence. An auditor asking whether release 4.2 met your policy needs a record of which checks ran, what they found and who approved any waiver. A wiki page cannot produce that. A gate with an evaluation history can.

The fix is turning each rule into something a machine evaluates the same way every time, at a point where the result matters, with a recorded outcome. That is what the standards below ask for.

What do SSDF PO.1 and PS.1, NIST SP 800-204D and PCI DSS 6.2 expect?

The major frameworks agree on the shape of the answer: define requirements, check them automatically at key points, handle exceptions on purpose, and keep the evidence.

NIST SP 800-218 (SSDF 1.1): PO.1, PO.4 and PS.1

The Secure Software Development Framework is the reference most US federal software attestations point back to. Three of its practices map directly onto policies and gates.

PO.1, Define Security Requirements for Software Development. The practice asks that security requirements for software development "are known at all times" so they can be applied throughout the lifecycle. Task PO.1.1 covers requirements for the development infrastructure and processes. Task PO.1.2 covers requirements for the software the organisation builds. Two of the notional implementation examples under PO.1.2 read almost like a product specification for a gate:

• Example 2 asks you to define policies for the software's security requirements and verify compliance at key points in the SDLC, giving "classes of software flaws verified by gates" as an example.
• Example 7 asks you to establish processes for requirement exception requests, including periodic reviews of all approved exceptions.

PO.4, Define and Use Criteria for Software Security Checks. PO.4.1 asks you to define criteria for security checks and track them through the SDLC; its examples include severity scores and recording approvals, rejections and exception requests in the workflow system. PO.4.2 asks for mechanisms that gather the information the criteria need, with examples that include automating decisions based on the criteria, reviewing that automation periodically, and preventing alteration or deletion of the gathered information.

PS.1, Protect All Forms of Code from Unauthorized Access and Tampering. PS.1.1 asks that all forms of code, including configuration as code, are stored with least privilege access. Its examples include version control that ties every change to an individual account. A gate definition is itself configuration: if anyone can quietly edit the rule or delete the CI step, the gate is decoration.

Put together, SSDF wants a written requirement (PO.1), a defined and automated check (PO.4), a tamper resistant home for the code and configuration that implement both (PS.1), and an exception process with periodic review (PO.1.2 example 7).

NIST SP 800-204D: policy enforcement inside CI/CD

NIST published SP 800-204D in February 2024. Where SSDF says what to do, 800-204D says where in the CI/CD pipeline to do it.

Section 5.1.1 on secure builds asks you to specify build policies, enforce them "using techniques such as an agent and policy enforcement engine", and generate attestation evidence alongside the build. It describes a policy as a signed document encoding the requirements an artifact must meet. Section 5.1.4 says open source dependencies, including transitive ones, must be enumerated, understood and "evaluated for policy". Section 5.2 says continuous delivery controls can be implemented as verification policies that allow or disallow an artifact for deployment. The document maps its build policy requirement back to SSDF PO.1.

PCI DSS v4.0.1 Requirement 6.2

For anyone handling cardholder data, PCI DSS v4.0.1 Requirement 6.2 covers bespoke and custom software being developed securely. Its sub-requirements cover developing that software based on industry standards and secure coding practices, training the developers who write it, reviewing code before it is released to production, and using software engineering techniques that prevent or mitigate common attacks. Requirement 6.3 sits next to it and covers identifying and managing security vulnerabilities, including in third-party components.

A gate does not satisfy 6.2 on its own, because code review, training and secure design are human processes. What it gives a PCI programme is recorded evidence that every release passed the same automated checks before production, with any exception approved by a named person. Map gates against the requirement text and testing procedures in the PCI Security Standards Council document library, which is what assessors use.

OWASP SAMM: Policy and Compliance

The OWASP Software Assurance Maturity Model has a Governance practice called Policy and Compliance. Its stated driving theme is describing the organisation's standards and third-party obligations as application requirements, so that audits can be automated and run inside the SDLC. At its highest level it describes "low-latency checkpoints" with project teams so no project operates outside expectations without visibility.

Both of its streams, Policy and Standards and Compliance Management, end at level 3 with measuring and reporting each application's adherence. Gates with recorded outcomes produce exactly that measurement as a side effect of shipping.

CISA Secure by Design and the supporting data sources

CISA's Secure by Design programme puts the burden of security on software producers and asks executives to own it. It is principles rather than requirement IDs, but it is why buyers now ask how requirements are enforced, not just documented. Two public data sources show up in most vulnerability policies. CISA's Known Exploited Vulnerabilities catalog is, in CISA's words, the authoritative source of vulnerabilities that have been exploited in the wild. FIRST's Exploit Prediction Scoring System publishes a daily probability that a published CVE will be exploited in the next 30 days. A policy that says "no KEV listed vulnerabilities" or "nothing above an EPSS threshold" is anchored to data anyone can check.

The SLSA guidance on verifying artifacts notes that changes to a package's provenance expectations might require two-party control, a useful pattern for policy changes too.

What the standards ask for, side by side

In Safeguard, what is the difference between a policy, a gate and a guardrail?

A policy is a rule that produces findings. The Policies & Gates docs describe policies as rules that evaluate your SBOMs and generate findings: they define acceptable risk thresholds and required controls, and they can be advisory or blocking. Under the hood, the Policy outcomes docs say each policy runs its starred search every time it is evaluated on a gate. A policy that finds matching issues is Failed. A policy whose search runs to the end with no matches is Passed. A policy that could not run, because its starred search is missing or timed out, is Error, and an Error is never counted as a pass.

Example conditions in the docs include vulnerability severity, CVSS score, EPSS score, licence, component age, maintenance status and SLSA level. They draw on capabilities that are themselves GA: SCA and vulnerability management with EPSS and KEV enrichment, licence compliance, and attestation and signing.

A gate is a checkpoint that enforces policies. Gates block deployments when policies fail, integrate with CI/CD pipelines and require approvals for exceptions. A gate has no rules of its own. Its outcome is worked out from the policies linked to it, in a fixed order that the docs spell out (covered in the actions section below). Safeguard's offering material describes gates being placed at checkpoints by stage, such as Monitor or Plan & Fix, and by function, such as App Sec or Dev, so the same policy can be enforced differently for different audiences.

A guardrail is the broader enforcement idea. The Guardrails & Enforcement docs define a guardrail as a rule Safeguard enforces on your behalf, which blocks, gates or remediates at the moment a risk appears instead of only reporting it. The docs list enforcement points from the IDE through commit, CI, registry, Kubernetes admission and runtime. This post covers CI and pull requests. The docs themselves say the admission controller is not published yet, and runtime checks through Safeguard Guard are early access.

In short: the policy is the sentence in your standard, the gate is where it is checked, and the CI step connects the gate's verdict to your pipeline.

How do you write a policy in plain English and check what it will match before enforcing it?

Policy creation from plain English is GA, and the mechanism gives you a built-in preview step. Policies run starred searches, and Search accepts plain English. The Search docs say Griffin reads filter-like intent, such as severity, licence, project, reachability and exploitability, directly out of a sentence, with no query language to memorise. The docs give examples like these:

critical vulnerabilities in my-app                  # severity + project
MIT-licensed components                              # license
reachable and exploitable vulnerabilities only        # reachable + exploitable
lodash, but not deprecated versions                   # exclusion
critical or high severity findings                    # either/or

Search also supports inline mentions: typing @ opens a picker to scope the query to a project, and : references a specific entity such as a component or vulnerability. The newer conversational extras around Search, namely Skills, Workspaces and Connectors, are early access; you do not need them to write a policy.

That gives you a natural drafting loop:

1. Translate one sentence of your standard into a query, scoped with an @ mention. One rule per query; a policy encoding three rules is hard to explain when it fails.
2. Read the results before committing. Results are grouped into components, vulnerabilities and projects, and they are your preview of what the policy will match. If it returns hundreds of issues everywhere, the rule is too broad or your estate is not ready for it to block.
3. Refine through the conversation, for example "which of these are reachable?", until the results are what your standard means.
4. Star the search. The docs say to click the Star icon on the conversation; it then appears under Starred searches in the sidebar.
5. Create the policy around it. In the docs, the Policy Builder lives under Settings › Policies: click Create Policy, define conditions using the visual builder or YAML, set severity and actions, then save and enable. The policy evaluates its starred search each time it runs on a gate.

Two cautions. A plain English query is interpreted by a model, so treat the results as a draft; somebody accountable should sign off on the saved search and the policy settings. And Search only sees scan data that has finished processing, so an empty result may just be ahead of a scan.

If your tenant runs in Zero AI mode (GA), where the platform works with no LLM in the loop, plain English interpretation is not the path to use; build the policy with the visual builder or YAML instead.

Policy templates and YAML

You do not have to start from a blank page. The Policies & Gates docs list pre-built templates, including No Critical Vulnerabilities, License Compliance, EO 14028 Compliance, SLSA Level 2 and No Abandoned Packages.

For teams that want policy as code, the Guardrails & Enforcement docs describe a YAML policy language. Each policy has a target, one or more rules and an effect, and rules evaluate against a document that combines SBOM, vulnerability, licence, signature, provenance and reachability data. The docs show this example:

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

The apiVersion line is part of the document format, not an API call. Effects are BLOCK, WARN and AUTO_FIX. Auto-fix hands the problem to autonomous remediation, which is GA but ships switched off with every category set to Manual, and needs a pre-approved scope. Keep the YAML in a repository with code owners on the file, which meets the spirit of SSDF PS.1.1.

Which gate actions exist, and at which checkpoints?

Safeguard's offering material lists four gate behaviours: block, warn, notify and require approval. The current docs implement them like this.

Block, Warn and Notify are policy Actions

Each policy has exactly one Action, and it decides what a failed policy does to the gate. The Policy outcomes docs describe them:

Notify is deliberately quiet. You are notified when a policy goes from passing (or never evaluated) to failing, and again when a failing policy finds new matching issues. A policy that keeps failing with the same matches does not notify again.

Require approval is the exception workflow

In the current docs, approval is not a fourth Action on a policy. It is how a Block is set aside for a specific case. The Policies & Gates docs say gates "require approvals for exceptions", and describe the request flow: click Request Exception, select the policy and finding, provide a business justification, set an expiration date, and submit for approval. Approvers are notified, review and decide, and an audit trail is recorded. The YAML format adds an exception block per rule with allowed and approvers, so you can mark some rules as never waivable.

How a gate's outcome is decided

The order matters, because it decides what your pipeline sees. Per the Policy outcomes docs, a gate's outcome is worked out from its linked policies in this order:

1. No policies linked: Not evaluated.
2. Any Block policy failed: Failed.
3. Otherwise, any policy could not be evaluated: Error, with the reason.
4. Otherwise, any policy not evaluated yet: Not evaluated.
5. Otherwise, any Warn policy failed: Warning. The gate passes and the warning names the policy.
6. Otherwise: Passed. Failed Notify policies are listed as notified.

Two details are easy to miss. A gate that has never been evaluated shows Not evaluated, never Passed. And an Error beats a Warning, so a broken policy cannot hide behind a passing gate.

A policy is evaluated when it is first linked to a gate and again after new assessment data arrives for the product. Older policies created with a threshold above zero keep it and fail only when the number of matches reaches the threshold; new policies have no threshold, so any match fails them.

Which checkpoints

Step by step: from a policy to a pull request that fails and then passes

This walkthrough uses GitHub Actions. Commands and files are as Safeguard's docs show them; where the docs describe an outcome without a screen, so do the steps.

Before you start

• The repository connected as an integration, or public on github.com, gitlab.com or bitbucket.org (or use --local, below).
• Policy outcomes turned on for your workspace. If the Gates and Policies tables have no Outcome column, ask your Safeguard contact.
• Permission to add a repository secret in GitHub.

1. Draft and preview the rule in Search

Pick one sentence from your standard. For this walkthrough: "Pull requests must not introduce critical vulnerabilities that are on CISA's KEV list."

Type it into Search, scope it with an @ mention and read the results. If it matches issues on main today, decide whether they are accepted, being fixed or a reason to start with Warn. Star the conversation once the results match the sentence.

2. Create the policy

Go to Settings › Policies and click Create Policy. Define the condition with the visual builder or YAML, set severity and the Action, then save and enable. For a first rollout, set the Action to Warn (the observe mode section below explains why). If a template fits, such as No Critical Vulnerabilities, start from it and narrow it.

3. Create a gate and link the policy

Create a gate under Policies › Gates and link the policy to it. Give the gate a name you will type in CI, such as pr-gate. Linking triggers the first evaluation. Expand the gate to see each linked policy with its Action, outcome, effect on the gate, matches and when it was evaluated.

If the gate shows Error, read the reason first; the docs cite a missing or timed out starred search.

4. Create the CI secret key

In Safeguard, create a secret key under Settings › Developer with the scopes scans:trigger and scans:read. You can lock the key to one project, which is a sensible default for a gate key.

In GitHub, add it under Settings › Secrets and variables › Actions › New repository secret, named SAFEGUARD_API_KEY. An organisation secret works too.

5. Add the workflow

Save the docs template as .github/workflows/safeguard.yml:

name: Safeguard
on:
  push:
    branches: [main]
  pull_request:
    branches: [main]
jobs:
  scan:
    runs-on: ubuntu-latest
    steps:
      - name: Safeguard scan
        env:
          SAFEGUARD_API_KEY: ${{ secrets.SAFEGUARD_API_KEY }}
          SAFEGUARD_INSTALL_DIR: ${{ runner.temp }}/safeguard-bin
        run: |
          set -eu
          curl -fsSL https://cli.safeguard.sh/install | bash
          "$SAFEGUARD_INSTALL_DIR/safeguard" ci scan --wait --fail-on critical

Then apply the documented option to fail on a policy gate: add --fail-on-gate to the command. The docs' options table shows --fail-on-gate all; you can also name a single gate by its name or id. If you only want the gate to decide, drop --fail-on critical, which the docs list as the way to stop failing on severity. The two flags can be combined.

No checkout step is needed, because Safeguard clones the repository, and there is no plugin to install. Pin the CLI with SAFEGUARD_VERSION: "<version>" in env, as the docs recommend, so a new release does not change a gate under you.

6. Open a pull request that breaks the rule

Open a pull request that adds a dependency version your policy matches. The head branch is scanned and the version is named after its head commit. --wait makes the step wait for the scan to finish and for the gate's policies to be evaluated on the new data. With the policy set to Warn, the job exits 0 and prints the warning naming the policy. Flip the policy's Action to Block and rerun: the job exits non-zero and prints the Block policies that failed.

7. Fix and watch it pass

Upgrade to a fixed version and push to the same branch. The policy finds no matches, the gate is Passed and the job exits 0. For help with the fix, the CLI's interactive assistant (GA) edits and runs commands with your approval, and autonomous remediation (GA, ships switched off) can open the pull request once turned on.

8. Know the three ways a gate step can fail

The docs list exactly when safeguard ci scan --wait --fail-on-gate exits non-zero: the gate is Failed; the gate is Error or Not evaluated; or the gate's policies were not evaluated before --timeout (default 30m). Each case prints a message saying why. Only the first is "your code broke the rule". The fix for the other two is in the policy or configuration, not the pull request.

Other CI systems

In each, add --fail-on-gate to the documented safeguard ci scan command (the GitLab template's variables cover severity only). For any other CI, the docs show this form:

curl -fsSL https://cli.safeguard.sh/install | bash
SAFEGUARD_API_KEY=... safeguard ci scan --wait --fail-on critical \
  --repository-url "$REPO_URL" --branch "$BRANCH" --commit "$COMMIT"

On Safeguard or on the runner

By default safeguard ci scan runs on Safeguard against the connected repository and covers SAST (early access), SBOM and dependency vulnerabilities. With safeguard ci scan --local the scan runs on your runner from lockfiles and manifests such as package-lock.json, go.sum, requirements.txt and pom.xml, covers SBOM and dependency vulnerabilities, and only the results leave the runner, which suits self-hosted and firewalled Git servers. Gates are evaluated by the platform either way.

How do exceptions and approvals work without becoming a permanent bypass?

Every policy programme needs exceptions. The risk is the exception nobody remembers granting. Safeguard's docs give you the pieces to keep them honest:

• Scope. A request names the policy and the finding; the Guardrails docs say exceptions apply to a specific asset for a specific duration.
• Justification and expiry. Each request carries a business justification and an expiration date, and exceptions expire automatically.
• Approval. Approvers are notified and decide. The YAML format names approvers per rule, and allowed: false makes a rule unwaivable.
• Breakglass. The Guardrails docs describe emergency breakglass exceptions that need two-person approval and alert the security channel.
• Audit trail. The exception workflow records an audit trail, and the Policies & Gates docs list exception history among the compliance reports.

The process around them is yours; SSDF PO.1.2 example 7 asks for periodic reviews of approved exceptions. A workable pattern:

1. Default every exception to the shortest expiry that covers the fix plan, for example 30 days for a fixable dependency and 90 days for one waiting on upstream.
2. Never let the developer who requested an exception approve it.
3. Review the exception history monthly. Any exception renewed twice is a policy problem or a resourcing problem, and both deserve a conversation.
4. Mark rules you will never waive, such as KEV listed criticals in production, as not allowing exceptions, so the decision is made once in calm conditions rather than at 2am.

How do you roll out in observe mode first and measure override rates?

Switching a gate straight to Block and failing half the pull requests by lunch is the fastest way to lose engineers' trust. Warn and Notify let you measure first.

A four stage rollout

Stage 1 tells you whether the rule is realistic. If most projects fail it, narrow it, for example to reachable or KEV listed issues, before going further.

Measuring override rates

An override rate is the share of gate failures that end in an exception rather than a fix. Safeguard records the raw material:

• Outcomes. The Outcome column on Policies › Gates and Policies › Policies shows each outcome and when it was last evaluated.
• Evaluation history. Expanding a gate shows its evaluation history page by page.
• Exception history. The compliance reports in the Policies & Gates docs include exception history and violation trends.

Compare exceptions granted with gate failures per policy per month. A rising rate means the rule and reality have drifted: fix the rule, fund the remediation or accept the risk explicitly. To pull these numbers into an assistant, the docs say Safeguard's MCP server (GA) has read-only tools for gate outcomes, policy outcomes and evaluation history, when your MCP access settings allow them.

How do policy outcomes feed compliance evidence?

For an auditor, a gate turns "we have a policy" into "here is what the policy decided on each release". The records that serve as evidence:

• The policy definition, including its starred search or YAML, its Action and the gates it is linked to. This answers "what is the requirement" (SSDF PO.1, SAMM Policy and Standards).
• Gate evaluation history per project version, where each push is a version named after its branch and commit. This answers "was the requirement checked on this release" (SSDF PO.4.1 and PO.4.2).
• Exception records with justification, approver and expiry. This answers "how were deviations handled" (SSDF PO.1.2 example 7, PO.4.1 example 5).
• Compliance reports by policy: compliance status by policy, exception history, violation trends and audit documentation, as the Policies & Gates docs list them.

Those records land in the Compliance and GRC suite (GA), which has tabs for frameworks, controls, evidence, monitoring, tests and policies, and maps evidence to controls continuously. The suite supports EO 14028, NIST SSDF and SLSA among hundreds of frameworks. Map each gate to the controls it supports, for example a pull request gate to SSDF PO.4, and attach its evaluation history and exception report as evidence for the audit period. The ESSCM product page also describes using policy results as proof in customer security questionnaires.

Evidence that a gate ran shows the check happened, not that it was the right check. Auditors will still ask how the policy was chosen and who reviewed it.

Common mistakes

• Starting in Block. Without a Notify or Warn baseline you cannot tell a real failure from a backlog.
• Removing the step when it shows Error. Error is never a pass. Fix the missing or slow starred search instead.
• Forgetting fork pull requests. GitHub gives them no secrets. The docs suggest scanning pushes only, or pull_request_target with care, never running the fork's code in that job.
• Leaving the GitLab variable protected. Merge request pipelines then fail with AUTHENTICATION_REQUIRED.
• Not pinning the CLI. A new release can then change gate behaviour without a change in your repository.
• Exceptions with no expiry. The gate becomes a list of permanent waivers.
• Letting anyone edit the CI file. If a contributor can delete the gate step in the pull request it gates, it is not a control. Put code owners on CI configuration (SSDF PS.1.1).

FAQ

Can Safeguard create a security policy from plain English?

Yes, and it is GA. You write the rule as a sentence in Search, review what it matches, star it and use it in a policy. Have someone review it before it blocks anything.

What is the difference between a policy and a gate in Safeguard?

A policy runs a search and records whether anything matched, producing findings and an outcome of Passed, Failed, Error or Not evaluated. A gate is a checkpoint that combines the outcomes of its linked policies, using each policy's Action, into one decision that CI can act on.

How do I fail a GitHub Actions build on a Safeguard policy gate?

Create a secret key with scans:trigger and scans:read, store it as SAFEGUARD_API_KEY, add the documented workflow, and add --fail-on-gate with the gate's name, id or all to the safeguard ci scan --wait command. Policy outcomes must be turned on for your workspace.

What do Block, Warn and Notify do?

Block makes the gate fail when the policy fails. Warn lets the gate pass with a warning that names the policy. Notify lets the gate pass and sends a notification to your configured channels, only when the policy starts failing or finds new matches.

How do policy exceptions work in Safeguard?

A developer requests an exception for a specific policy and finding with a business justification and an expiration date. Approvers are notified and decide, and the decision is recorded in an audit trail. Exceptions expire automatically, and rules can be marked so they cannot be waived.

Can I run Safeguard policy gates without giving it access to my repository?

Yes, with safeguard ci scan --local. The scan runs on your CI runner from lockfiles and manifests, and only the results leave the runner. Gates are still evaluated by the platform on those results. SAST is not part of the local mode.

Does a Safeguard gate satisfy NIST SSDF?

No single tool does. Gates with recorded outcomes give strong evidence for parts of PO.1 and PO.4, but SSDF also covers training, environments, design and vulnerability response.

Can Safeguard block a Kubernetes deployment that violates policy?

Not today. The Guardrails & Enforcement docs say the admission controller is not published and warn against installing any chart that claims to be it.

What Safeguard does not do

1. A gate only enforces where it is wired in. Safeguard evaluates gates on the scans it runs, but a pipeline only fails if it runs the --fail-on-gate step. A repository without the step, a release built on a laptop or a fork pull request without secrets is not gated.
2. Plain English policies are drafts until a person reviews them. Search interprets a sentence with a model; someone accountable must read what it matches and sign off before a Block goes live.
3. Gates do not fix anything by themselves. A failed gate stops a release; it does not change the code. Autonomous remediation (GA) can open fix pull requests, but it ships switched off with every category set to Manual, and the CLI assistant asks before each command.
4. Policy outcomes are switched on per workspace by Safeguard. Until they are, there is no Outcome column and --fail-on-gate has nothing to evaluate. Ask before planning a rollout date.
5. SAST findings do not fail the build yet. safeguard ci scan runs SAST (early access) on the platform, but the CI docs say SAST findings are not part of --fail-on yet. Severity gating in CI covers dependency vulnerabilities.
6. No Kubernetes admission control today. The Guardrails docs say the admission controller is not published. Cluster enforcement is yours to build.
7. Runtime enforcement is early access. Guard runtime protection and its guardrails are early access, so do not plan production blocking on them yet.
8. Plain safeguard scan never fails on findings. It exits 0 when the scan ran; use safeguard ci scan for gates.
9. It does not write your standard or replace the human parts of PCI DSS 6.2 and SSDF. Choosing thresholds and what can be waived is a governance decision, and code review, training and secure design still need people.

The third limit is the one teams feel first. A gate tells you a release breaks a rule; it does not make the vulnerable dependency go away, so when a Block fires on a dependency with a fix, or on one with no fix yet, the options below are how teams get the gate back to green without an open-ended exception.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, open the interactive terminal with safeguard, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before each command, edit package.json to lodash 4.17.21, run npm install and npm test with your approval, print a summary and push nothing. It then shows /permissions, /model and /scan .. It is the fix you would make in step 7 of the walkthrough.

Click through it at your own pace, or open it full screen.

The second demo is a real Android session with the Safeguard mobile app, which is early access (beta). It sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. Like a gate exception, it is a named person's explicit decision scoped to one action.

Click through it at your own pace, or open it full screen.

The third demo connects Claude to the Safeguard MCP server with OAuth and shows how you choose which tools Claude can use. The Policy outcomes docs say the MCP server has read-only tools for gate outcomes, policy outcomes and evaluation history, so an assistant can report which policies failed this week without write access.

Click through it at your own pace, or open it full screen.

To try the flow on your own repositories, download the apps and CLI at safeguard.sh/download and follow the setup in the Safeguard docs.

For more on the same topic, see policies and gates step by step, how policy gates work in pull requests, how to set up a vulnerability policy gate, the policy evaluation engine architecture and why the Safeguard CLI never fails a build, and how to gate.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 (PDF)
• NIST CSRC: SP 800-218 publication page
• NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines (PDF)
• NIST CSRC: SP 800-204D publication page
• OWASP SAMM: Policy and Compliance
• CISA: Secure by Design
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• SLSA v1.0: Verifying artifacts
• Safeguard docs: Policies & Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: Guardrails & Enforcement
• Safeguard docs: Search
• Safeguard docs: CI/CD Integration
• Safeguard docs: GitHub Actions
• Safeguard docs: GitLab CI/CD
• Safeguard docs: Jenkins
• Safeguard docs: Azure Pipelines
• Safeguard docs: Bitbucket Pipelines
• Safeguard docs: AI Remediate (auto-fix)
• Safeguard docs: CLI usage
• Safeguard: ESSCM product page
• Safeguard: Use cases
• Safeguard: Download

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.