How to Prove Every Production Release Passed a Security Gate

To prove every production release passed a security gate, keep one decision record per release that names the exact commit or artifact, the policy set and version the gate applied, what it found, what it decided, and who approved any exception, with timestamps. Then show the auditor that the list of releases you deployed and the list of gate records match, and that nobody changed the gate's rules during the audit period without review. If those three things hold, a sampled release takes minutes to evidence instead of an afternoon of screenshots.

This guide works through what SOC 2 and ISO/IEC 27001 actually ask about testing and approving changes, what an auditor does with a sample of releases, what the record must contain, how to choose between blocking and warning, how to handle emergency releases without breaking the chain, and how to prove the gate itself stayed put. The first two thirds apply whatever tools you use. Safeguard appears near the end, with maturity labels on every capability.

Key takeaways

• The gate's output is the evidence. Design the gate so each run writes a record an auditor can read without your help: release identifier, policy and version, findings, per policy outcome, gate decision, approver for any exception, and time.
• Auditors test the population, not your best day. Any release in the period can be sampled, including hotfixes and rollbacks.
• Pick actions for the evidence they leave. Block for findings you never ship with; warn for findings you accept but want visible; notify for trends; route real exceptions through a named approver with an expiry date.
• Emergency releases are allowed; silent ones are not. A break glass release still needs the failed gate result on file, a retrospective approval, and a follow up to close the gap.
• The gate's configuration is in scope. Keep policies under change control, pin the scanner version, and keep a log of who changed which policy and when.
• Some evidence must come from elsewhere. Code review approvals, deployment logs and pipeline access control live in your source control, deploy tooling and identity systems.
• Safeguard capabilities covered, with labels: policies, gates and guardrails (GA); plain English policy creation (GA); the Safeguard CLI and CI integration (GA); MCP server (GA); Portal audit trails with export (GA); bulk data export (GA); Compliance and GRC suite (GA, roughly 50 evidence connectors live today, more on request); SCA and vulnerability management (GA); SAST (early access); autonomous remediation (GA, ships switched off with every category set to Manual); fork and patch (early access).

What the standards ask for about testing and approving changes

Nobody's audit criteria say "run a security gate in CI." They say something broader about changes: that you test them, approve them, and can show both. A security gate is one of the cleanest ways to meet the testing half for the security part of a change, because it runs the same checks every time and can write down what happened. Before designing the record, it helps to read what the criteria ask for in their own terms.

What SOC 2 CC8.1 asks for

SOC 2 reports are built on the AICPA's 2017 Trust Services Criteria, which the AICPA republished with revised points of focus in 2022. Change management sits in a single criterion, CC8.1. In substance it requires that the entity authorizes, designs, develops or acquires, configures, documents, tests, approves and implements changes to infrastructure, data, software and procedures to meet its objectives.

Read that list as a chain. A release is a change to software. The criterion expects each change to be authorized, tested and approved before it is implemented, and expects documentation that shows it. The points of focus that sit under CC8.1 spell out the pieces auditors look for: managing changes through the system life cycle, authorizing changes, documenting changes, tracking system changes, testing system changes, approving system changes, deploying system changes, creating baseline configurations, and providing for changes needed in emergency situations. The 2022 revision added points of focus on managing patch changes among others.

Two points matter for this post. First, "tests" in CC8.1 is not limited to functional tests. If your control description says security checks run on every release, the auditor will test that claim against your evidence. Second, the emergency point of focus means an auditor expects an emergency path to exist, and expects it to be controlled. An emergency release that bypassed your gate is not automatically a finding. An emergency release with no record of why, and no later approval, usually is.

Points of focus describe characteristics relevant to the criterion; they are not a checklist. You design your own controls, which is why the wording matters: write "all production releases pass the security gate before deployment" and you have set the bar the auditor will test. Write what you actually do.

What ISO/IEC 27001:2022 Annex A 8.29 and 8.32 ask for

ISO/IEC 27001:2022 lists its reference controls in Annex A, and two of them sit directly on this topic. Control 8.29 is titled "Security testing in development and acceptance." Control 8.32 is titled "Change management." In short, 8.29 expects security testing processes to be defined and carried out within the development life cycle, and 8.32 expects changes to information processing facilities and systems to go through change management procedures. ISO/IEC 27002:2022 gives the implementation guidance for both.

Controls 8.25 (secure development life cycle) and 8.15 (logging) usually join the same conversation. An ISO auditor asks for the procedure, then traces sampled changes through it, so the gate's documented criteria and its records are both in scope.

Where NIST SSDF and SP 800-204D fit

Neither SOC 2 nor ISO 27001 tells you what a security check should look like. NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, published in February 2022, comes closer, and many teams use it to write the criteria their gate enforces.

Four SSDF tasks map onto a release gate almost one to one:

• PO.4.1 asks you to define criteria for software security checks and track them throughout the SDLC. Its examples include vulnerability severity scores and other measures. Your gate's policy set is that criteria, written down.
• PO.4.2 asks for processes and mechanisms to gather and safeguard the information that supports the criteria, with the example of using the toolchain to gather it automatically. The gate's decision record is that information.
• PO.3.3 asks you to configure tools to generate artifacts that show support for secure development practices. Its first example is using existing tooling to create an audit trail of secure development related actions. The SSDF defines an artifact as a piece of evidence.
• PW.8.2 asks you to scope and perform testing of executable code and document the results, including recording and triaging all discovered issues. PW.7.2 asks the same for code review and code analysis.

Add PS.3.1, which asks you to securely archive the files and supporting data to be retained for each software release, and you have a fair description of the gate record's lifecycle: define criteria, apply them automatically, write down the result, keep it with the release.

NIST SP 800-204D, "Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines," published in February 2024, sits one level down. It treats the CI/CD pipeline as the place where supply chain controls get applied and recommends, among baseline measures, that artifacts be scanned for defects with the ability to stop their use in builds based on criticality, and that CI/CD processes be audited regularly. It also lists audit and monitoring among the mitigations that apply across the SDLC. A gate that can stop a build and that writes an auditable record is the practical form of both recommendations.

Where SLSA provenance fits

A gate record proves a check ran against something. The next question is whether that something is what shipped, and SLSA is the common vocabulary for that. SLSA v1.0 defines build levels up to Build L3: L1 means provenance exists, L2 adds signed provenance from a hosted build platform (against tampering after the build), and L3 requires a hardened build platform (against tampering during the build). No SOC 2 or ISO audit requires a SLSA level, but if your gate records an artifact digest and your build produces provenance for the same digest, you can draw a straight line from "the gate passed this" to "this is what we deployed."

What an auditor's sample of releases looks like

Auditors do not inspect every release. They test a sample and extrapolate. How they pick the sample, and what they ask per item, tells you exactly what your evidence needs to support.

The population comes first

Before sampling, the auditor asks for the population: the full list of production changes in the audit period. A SOC 2 Type 2 report covers a period of time rather than a single date, so the population is every release in that period.

Many teams fail here before the first sample is pulled. If the population comes from change tickets and some releases shipped without one, the population is incomplete, and a sharp auditor will reconcile it against deploy logs. Build it from the record of what actually ran in production.

The auditor's methodology sets the sample size from how often the control runs and the risk assigned to it. A per release control is high frequency, so expect a larger sample than for a quarterly review. Plan for any release to be picked.

What they ask for per sampled release

For each release in the sample, the questions are predictable:

The gate answers only rows four to six. The rest come from other systems, so the gate record must carry identifiers that join it to the pull request and the deploy log.

What a gate decision record must contain

Think of the gate record as a receipt. It should make sense to someone who was not in the room, months later, without access to the pipeline that produced it.

The minimum fields

Two fields are often missing and matter most. Without the policy version, "passed" cannot be checked against the rules in force that day. And the record must separate "passed" from "could not evaluate": a scan that timed out and let the build through produces a record that looks like a pass. Record errors as errors and fail the pipeline on them.

A worked example record

The following is an illustrative record, written for this guide to show the shape. It is not the output format of any particular product.

{
  "release": {
    "repository": "git.example.com/payments/api",
    "branch": "main",
    "commit": "4f9c2e1b7a03d5c8e6f1a2b3c4d5e6f708192a3b",
    "tag": "v2026.10.21",
    "artifact_digest": "sha256:3b1f9e..."
  },
  "pipeline_run": "ci-run-88123",
  "gate": { "name": "production-release", "id": "gate-17" },
  "policies": [
    { "name": "no-critical-vulns", "version": "2026-09-30", "action": "block", "outcome": "passed", "matches": 0 },
    { "name": "license-allowlist", "version": "2026-08-12", "action": "block", "outcome": "passed", "matches": 0 },
    { "name": "high-vulns-visible", "version": "2026-09-30", "action": "warn", "outcome": "failed", "matches": 2 }
  ],
  "decision": "warning",
  "exception": null,
  "inputs": { "scan_id": "scan-55120", "scanner_version": "x.y.z" },
  "evaluated_at": "2026-10-21T14:02:11Z",
  "triggered_by": "ci-service-account"
}

Every field in that record answers one of the auditor's questions. The warn policy shows that two high severity findings were present and accepted under the rules in force, which is a defensible decision as long as your policy says high severity findings warn rather than block.

Where to keep it

Keep the record where it cannot be quietly edited and where it outlives CI log retention, which is often shorter than an audit period: an append only bucket with object lock, a log platform with long retention, or the gate system's own history. SSDF PS.3.1 frames this as archiving supporting data for each release. The record belongs with the release, not with the job.

Block, warn, notify or require approval: choosing the action

Every gate needs a rule for what happens when a policy fails. The choice matters for security, but it also shapes what your evidence looks like. A gate that blocks on everything produces clean records and a stream of exceptions. A gate that warns on everything produces no exceptions and records that prove nothing.

What each action leaves behind

A rule of thumb for each kind of finding

Start from your written vulnerability management policy. If it says critical vulnerabilities are fixed before release, the gate must block. If it allows high severity findings a remediation window, warn on release and track age separately; a block would force an exception on every release inside the window.

Known exploited vulnerabilities deserve their own policy. CISA maintains the Known Exploited Vulnerabilities catalog of vulnerabilities with evidence of exploitation in the wild, and many teams block on any component in it regardless of CVSS score. FIRST's Exploit Prediction Scoring System (EPSS) publishes a daily probability that a CVE will be exploited in the next 30 days, which suits a warn rule that surfaces likely targets early.

License findings are usually binary: a forbidden license blocks, a license that needs review warns. Keep approval steps for real exceptions. Approvals that happen many times a day turn into rubber stamps, and an auditor reading a log of approvals made within seconds will notice.

Emergency releases past a failing gate

Production is down, the fix is one line, and the gate fails on an unrelated finding. You will ship. The question is whether the evidence chain survives.

What a controlled emergency path looks like

The CC8.1 point of focus on emergency changes expects a process for changes that must happen in a critical time frame. It does not forbid shipping past a failing check. It expects control. A workable emergency path has five parts:

1. The gate still runs, and its failure is recorded. Never disable the check to ship. Let it run, let it fail, keep the record. The failed record is the evidence that you knew.
2. The override is a distinct, logged action. Use a separate pipeline path, a break glass role, or an exception request, so that the override leaves its own trace with an identity attached.
3. A named approver signs off, before or soon after. If time does not allow approval first, your procedure should require retrospective approval within a defined window. Pick a window you will actually meet and write it into the procedure.
4. The exception has an expiry. An emergency exception that never ends becomes a permanent hole in the gate. Set an expiry date and a follow up item to fix the finding.
5. The next normal release passes the gate. That closes the loop, and it is what an auditor looks for when they follow an emergency change forward.

Keep emergency releases in the population

Emergency releases are the easiest to miss from the population and the ones auditors like to sample. Make sure a break glass deploy still appears in the deploy log and still has a gate record, even a failed one.

Never rerun the job with the security step commented out, or flip a policy to non blocking, ship, and flip it back. Both look worse in an audit than the finding you were avoiding, because they also change the gate's configuration without review.

Proving the gate itself was not changed during the audit period

An auditor who accepts your gate records will next ask how they know the gate in March applied the same rules as the gate in September, or that any change to it was itself controlled. This is the question teams prepare for least.

Put the gate's rules under change control

The simplest answer is to treat gate policies like code. Keep them in a repository, change them through pull requests with review, and tag versions. Then the history of the policy repository is the evidence. If your tool stores policies in its own database, you need its audit log of policy modifications instead, with who changed what and when.

Pin the pieces that can change under you

A gate can change without anyone editing a policy. New vulnerability data is welcome; a scanner or installer that silently updates is not. Pin the scanner or CLI version, record it in the gate record, and upgrade it through a reviewed change. Pin third party CI actions to a full 40 character commit SHA rather than a tag, which Safeguard's own CI/CD security docs also recommend, so whoever controls a tag cannot change the code that runs your gate.

Make the gate a required check

A gate is only a control if the normal path cannot skip it. Make the gate job a required status check on the protected release branch, restrict who can change branch protection, and export those settings and their history as evidence.

Reconcile releases against gate records

The strongest evidence is a reconciliation: every production deployment in the period, joined to a gate record by commit or digest, with any unmatched release explained. Run it monthly, not the week before the audit. A reconciliation that shows every release matched, or every gap explained by an approved exception, answers the population question and the gate integrity question at once.

A reference design you can run with any tooling

Here is the whole pattern in tool neutral terms:

1. Write the criteria: which findings block, warn or notify, matched to your vulnerability and license policies. This is your SSDF PO.4.1 artifact.
2. Encode them as versioned policies, changed only through review.
3. Gate the release commit or artifact, not only pull requests.
4. Fail closed on errors, timeouts and unevaluated states.
5. Write and archive the decision record with the fields above.
6. Route exceptions through a named approver with justification and expiry.
7. Make the gate a required check on the release branch.
8. Reconcile monthly between deploys and gate records.
9. Hand the auditor a bundle per sampled release: gate record, any exception, pull request approval, deploy log line.

How Safeguard does this job, step by step

Safeguard's policies and gates (GA) cover the middle of the reference design: encoding criteria as policies, evaluating them at a gate, failing a CI job when a gate fails, routing exceptions to approvers, and keeping the evaluation history. The steps below follow Safeguard's docs. Where the docs do not show a screen or command, this guide describes the outcome instead of inventing one.

Step 1: Write the policies

In Safeguard, policies are rules that evaluate your SBOMs and generate findings; gates are checkpoints that enforce policies. To create one, the docs describe this flow:

1. Go to Settings → Policies.
2. Click Create Policy.
3. Define conditions using the visual builder or YAML.
4. Set severity and actions.
5. Save and enable.

The docs list condition types that map directly onto a release gate's criteria, with examples such as no critical CVEs, no vulnerabilities above a CVSS score of 7.0, EPSS based conditions, license conditions such as no GPL licenses, component age, abandoned packages, and a required SLSA level for attestations. Pre built templates include no critical vulnerabilities, license compliance, EO 14028 compliance, a SLSA Level 2 template and no abandoned packages.

Safeguard also creates policies and findings from plain English prompts (GA). However a policy is written, read it back against your criteria document before linking it to a release gate.

Step 2: Link policies to a gate and set each policy's action

Each policy carries one Action, which decides what a failed policy does to the gate it is linked to. Per Safeguard's policy outcomes docs:

• Block: the gate fails.
• Warn: the gate still passes, with a warning that names the policy.
• Notify: the gate still passes, and Safeguard sends a notification to the workspace's configured channels, which the docs list as the in app bell, connected chat integrations and email according to each person's preferences. Notify fires when a policy goes from passing (or never evaluated) to failing, and again when a failing policy finds new matching issues, rather than on every evaluation.

Safeguard's offering material also lists "require approval" among gate actions. In the docs pages this guide follows, approval appears through the exception workflow in Step 6 rather than as a fourth policy Action, so plan your approvals around exceptions.

One setup detail matters for evidence: Safeguard's docs say policy outcomes are turned on per workspace by Safeguard. If your workspace does not show an Outcome column on the Gates and Policies tables, ask your Safeguard contact to turn it on. While it is off, policies and gates behave as they did before, and the outcome history described below is not there to export.

Step 3: Know what each outcome means

Safeguard records an outcome every time it evaluates a policy on a gate: when the policy is linked to the gate, and again after new assessment data arrives for the product. A policy's outcome is one of four:

The docs state plainly that an Error is never counted as a pass. That is the fail closed behaviour the reference design asks for.

The gate's own outcome follows from its policies in a fixed order. With no policies linked, it is Not evaluated. If any Block policy failed, it is Failed. Otherwise, if any policy could not be evaluated, it is Error. Otherwise, if any policy has not been evaluated yet, Not evaluated. Otherwise, if any Warn policy failed, Warning, and the gate passes with the policy named. Otherwise, Passed, with failed Notify policies listed as notified. A gate that has never been evaluated shows Not evaluated, never Passed.

Quote that ordering in your control description; it answers "what does pass mean" with a documented rule.

New policies have no threshold, so any match fails them. Older policies created with a threshold above zero keep it, per the docs, so check inherited policies before the audit period starts.

Step 4: Create a CI secret key

The CI integration runs the Safeguard CLI (GA) in a plain shell step. There is no plugin to install. Per the docs:

1. Create a secret key under Settings → Developer with the scopes scans:trigger and scans:read. You can lock it to one project.
2. Store it in your CI as a secret named SAFEGUARD_API_KEY.

Locking the key to one project also gives you a clean line in your access evidence.

Step 5: Add the gate to the release pipeline

Safeguard's docs give templates for GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins and Azure Pipelines, plus a pattern for any other CI that runs a shell step. The GitHub Actions workflow in the docs is:

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

To make the job fail on a policy gate rather than only on a severity threshold, the docs' options table says to add --fail-on-gate all, or name a specific gate by name or id:

safeguard ci scan --wait --fail-on-gate <gate name or id | all>

Per the policy outcomes docs, that command waits for the scan to finish and for the gate's policies to be evaluated on the new data, then:

• exits 0 when the gate is Passed or Warning, printing warnings and notified policies;
• exits non zero when the gate is Failed, printing the Block policies that failed;
• exits non zero when the gate is Error or Not evaluated, or when its policies were not evaluated before the timeout, with a message that says why.

The last point is the one auditors care about. The CI job cannot pass on a gate that did not finish evaluating. The --fail-on <severity> flag keeps working and can be combined with --fail-on-gate.

Three details in the docs help the evidence chain:

• Each push becomes a new version of the Safeguard project, named after branch and commit, for example main-a1b2c3d. That name is your join key to the release commit in your deploy log.
• Branch filters accept wildcards, such as release/**. On a pull request the head commit names the version, so make sure the release commit itself is scanned too.
• Pin the CLI version with SAFEGUARD_VERSION in the step's environment, so a CLI release does not change a build under you.

By default, Safeguard clones the connected repository and scans it on the platform (SBOM, dependency vulnerabilities, and SAST, which is early access). With --local, the scan runs on the runner from lockfiles and manifests and only results leave it. The docs note SAST findings are not part of --fail-on yet. Safeguard's offering also lists SARIF (the OASIS static analysis results format) and JUnit output for CI; the setup pages followed here do not show that flag, so check the CLI reference for your version.

Step 6: Route exceptions through the documented workflow

When a release must ship with a finding the gate blocks, the Policies and Gates docs describe an exception flow:

1. Click Request Exception.
2. Select the policy and finding.
3. Provide a business justification.
4. Set an expiration date.
5. Submit for approval.

The workflow then runs: the request is created by the developer, a notification goes to approvers, an approver reviews and decides, the exception is granted or denied, and an audit trail is recorded. That sequence covers the parts of an emergency path that are hardest to evidence: a named approver, a written reason, and an expiry.

For emergency releases, pair this with your break glass procedure: the exception shows the approval, the deploy log the release, and the gate history the overridden failure.

Step 7: Read and export the evidence

Per the docs, outcomes appear under Policies → Gates and Policies → Policies, where an Outcome column shows Passed, Failed, Warning, Not evaluated or Error with the time of the last evaluation. Expanding a gate shows each linked policy's Action, outcome, effect on the gate, matches and evaluation time, and the gate's evaluation history, page by page. A policy linked to several gates shows Failed if it failed on any of them.

For changes to the gate itself, Portal audit trails (GA) log administrative activity, which the docs say includes settings changes, integration configurations and policy modifications. Each entry carries a UTC timestamp, actor, action, resource, details, source IP, user agent and result. Under Settings → Audit Logs you filter by date range, actor, action type and resource, then export as CSV, JSON or PDF, or schedule delivery. Logs can also go to a SIEM under Settings → Integrations → SIEM. The docs give default retention of seven years for administrative logs. The same page shows a /v1 REST call under a banner saying those endpoints are not yet available, so use the in app export or SIEM route.

Bulk export (GA) helps when an auditor wants the full population of evaluations as a spreadsheet.

Step 8: Pull outcomes into an assistant or your evidence store

Safeguard's MCP server (GA) has read only tools for gate outcomes, policy outcomes and evaluation history, when policy outcomes are on and your MCP access settings allow them. That lets you ask an assistant which gates ended on a Warning this quarter without a manual export.

The Compliance and GRC suite (GA) is where this evidence can sit beside your other SOC 2 or ISO 27001 controls. It has roughly 50 evidence connectors live today, more on request, so check that your code review and deploy systems are among them.

Step 9: Fix what the gate blocks

Safeguard's autonomous remediation (GA) can open fix pull requests for vulnerable dependencies. It ships switched off, with every category set to Manual, so your team decides what runs on its own and what needs approval. The fix pull request then passes through review and the same gate.

What evidence still has to come from other systems

A security gate answers whether the security check ran and what it decided. An auditor testing CC8.1 or ISO 8.32 also wants proof of authorization, review and controlled deployment, and those live elsewhere.

What Safeguard does not do

Be clear on the limits before you build an audit narrative around any tool.

1. Safeguard does not perform or replace the audit. It produces records that support your controls. Your auditor decides whether those controls are designed and operating effectively.
2. Gate evidence covers only what the gate checked. It does not show that code was peer reviewed, that a change was authorized, or that the deployment was performed by an authorized process. Those come from your source control, work tracking and deployment systems.
3. A gate only runs where the CI step is wired in. If a release path does not call safeguard ci scan, there is no evaluation for that release. Coverage of every release path is your responsibility, and the monthly reconciliation is how you prove it.
4. Policy outcomes must be turned on for your workspace. Safeguard's docs say this is done per workspace by Safeguard. Until it is, the Outcome column and evaluation history described above are not available.
5. SAST findings are not part of --fail-on yet, per the CI docs, and SAST itself is early access. A gate built only on --fail-on covers dependency vulnerabilities.
6. The /v1 REST endpoints are not yet available. Use the in app views, exports, SIEM integration and MCP tools.
7. Evidence connectors are roughly 50 live today. Others are available on request. Do not assume your deploy or ticketing system feeds the Compliance and GRC suite automatically until you have checked.
8. Safeguard does not decide your risk appetite. Which findings block, which warn, and how long exceptions last are your policy decisions. The tool enforces what you write.

Common mistakes

• Gating the pull request but not the release. The pull request head commit and the release commit often differ after a squash or rebase merge. Gate the commit or artifact that ships.
• Treating "scan failed to run" as "pass." If an error, timeout or missing evaluation lets the job through, the record will show a pass that never happened. Fail closed.
• No policy version in the record. "Passed" without the rule version cannot be checked against your criteria as they stood that day.
• Exceptions approved in chat. A message in a channel is not an exception record. Use a workflow that captures approver, justification and expiry.
• Exceptions without expiry. An open ended exception quietly turns a blocking policy into a warning forever.
• Editing policies mid period without review. Even a well intended relaxation looks like tampering if there is no change record.
• A control description that promises more than the gate does. If the description says "all findings are fixed before release" but the gate warns on high severity findings, you have written yourself a finding.

FAQ

How do I give auditors evidence that security checks ran on every release?

Give them one gate decision record per production release, joined to the deploy log by commit or artifact digest. Each record should show the policies and versions applied, the findings, the decision, any exception approval and the time. Add a reconciliation showing every deployment in the period has a matching record.

Does SOC 2 require a security gate in CI/CD?

No. SOC 2 CC8.1 requires that changes are tested, approved and documented before implementation. A CI security gate is a common way to evidence the security testing part, but the criteria do not prescribe the mechanism. What matters is that your control description matches what you do and that you can evidence it.

What does ISO 27001 Annex A 8.29 require for release testing?

Control 8.29, "Security testing in development and acceptance," expects security testing to be defined and carried out within the development life cycle, including acceptance testing against defined criteria. A release gate with written criteria and recorded results is one way to evidence it, alongside control 8.32 on change management.

How many releases will a SOC 2 auditor sample?

It depends on the auditor's methodology, the length of the period and how often the control runs. A control that runs on every release is high frequency, so expect a larger sample than for periodic controls. Plan for any release in the period to be selected, including emergency ones.

Should a security gate block or warn on high severity vulnerabilities?

Match the gate to your written vulnerability management policy. If the policy requires fixing before release, block. If it allows a remediation window, warn on release and track age separately. A gate that contradicts your written policy creates an audit finding either way.

How do I handle an emergency release that fails the security gate?

Let the gate run and fail, ship through a separate logged override path, get a named approver to sign off before or within a defined window after, set an expiry on the exception, and make sure the next normal release passes. Keep the failed record; it proves you knew.

How do I prove our security gate rules did not change during the audit period?

Keep policies under change control with review, export the audit log of policy modifications, pin scanner and CI action versions, and make the gate a required check on protected release branches. Any change in the period should have a review record you can show.

What should a security gate decision record contain?

At minimum: release identifier, repository and branch, pipeline run, gate name, policies with versions, inputs such as the scan ID, findings summary, per policy outcomes, gate decision, exception reference with approver and expiry, timestamps and the actor that triggered the run.

Can a passing pull request check serve as release evidence?

Only if the commit that was checked is the commit that shipped. After squash or rebase merges it often is not. Run the gate on the release commit or artifact and record that identifier.

From a blocked release to a fixed one

A gate that blocks well also creates pressure to fix quickly, and the fastest fix is often a dependency upgrade or a patched component. The block below describes how Safeguard helps close that gap, so a blocked release becomes a passing one without waiting on an upstream schedule.

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, run safeguard to open the interactive terminal, and ask it to "fix the lodash CVE in this repo." It reads the finding and the advisory, asks before any command that changes something, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan .. For this topic, it is what happens after a gate blocks: the fix is made with an approval at each step, and the change then goes back through review and the same gate.

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

The second demo sets up the local runner on your own machine, approves it with its device code, then scans from the terminal. The same CLI is what the CI step installs and runs, so this is a quick way to see what a scan produces before you wire safeguard ci scan into a release pipeline.

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

To try it on your own pipeline, download the CLI and apps at safeguard.sh/download, and read the policies, gates and CI setup guides at docs.safeguard.sh/docs.

Related reading: SSDF PO.4 security check criteria and gate evidence, an emergency exception to ship past a failing security gate, change management evidence from pull requests, SOC 2 CC8 change management control ideas and describing your security gate rule in a customer questionnaire.

Quick check

Sources

• AICPA & CIMA: 2017 Trust Services Criteria (With Revised Points of Focus, 2022)
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System (EPSS)
• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1
• NIST SP 800-218 full text (PDF)
• NIST SP 800-204D, Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines
• NIST SP 800-204D full text (PDF)
• SLSA v1.0: Security levels
• OASIS: SARIF Version 2.1.0
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: CI/CD Integration
• Safeguard docs: GitHub Actions
• Safeguard docs: CI/CD Security
• Safeguard docs: Portal Audit Trails

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