Run a 30 day Safeguard proof of value: scope and exit criteria

A good 30 day Safeguard proof of value connects a few representative repositories and one pipeline in week one, produces SBOMs and findings in week two, runs policy gates in warn mode in week three, and ends in week four with a written yes, extend or no. Success is a set of questions you answer from your own data, not a target number.

This post is the plan we would hand to the person who owns the evaluation: usually a head of application security, a security architect or a procurement lead, with a VP of Engineering close behind. It is an illustrative scenario. It does not describe any customer, and it contains no results, because the only results that matter are the ones your own repositories produce. Every product step below was checked against the public pages on docs.safeguard.sh before publishing, and the commands shown are the ones those pages show.

Key takeaways

• Write the exit decision before day one. A trial with no agreed decision rule drifts into a free extension and then into nothing.
• Scope small and representative: a few repositories that cover your main languages and package managers, one container image and one CI pipeline.
• Decide in week one where scans run: on a connected integration, on your own machine through the local runner, or inside CI so only results leave the build machine. Private VPC, on-prem and air-gapped deployments are also available.
• Phrase success criteria as questions your own data answers, not target numbers.
• Run enforcement in warn mode first, and prove a block with a deliberate failure on a test branch.
• Autonomous remediation ships switched off, with every category set to Manual. Test fix pull requests manually unless you choose otherwise.
• Close with a scorecard and an evidence pack the budget holder can read in ten minutes.

What a proof of value is for

A demo shows what a product does on the vendor's data. A proof of concept asks whether it can work in your environment at all. A proof of value asks the budget holder's question: if we bought this, would it change how we find, prioritise and fix supply chain risk enough to justify the cost and the change to how developers work? The longer version of that distinction is in pilot vs proof of value vs proof of concept.

So the output has to be useful to the people who will live with it: the AppSec engineer triaging findings, the developer receiving a pull request, the platform engineer who owns the pipeline, and the auditor who later asks for evidence. Thirty days covers a couple of sprint boundaries, which is long enough for normal trial friction to surface (a key that needs rotating, a lockfile format you forgot, a self hosted runner behind a proxy) and short enough to keep attention.

Before day one: agree the decision, the owners and the boundaries

Most evaluations that stall do so because nobody wrote down, at the start, who decides and on what basis. Spend an hour on this before anything is connected.

Write the problem statement in one paragraph

State the problem in your own words and keep it specific. For example:

• "We cannot say which open source components and versions a given release contains, and audits keep asking."
• "Our dependency scanner produces more findings than we can triage, and we cannot tell which ones matter."
• "We know what to fix, but fixes sit in a ticket queue for weeks."
• "We need to stop new critical vulnerabilities reaching production without blocking every build."

Each one shifts the emphasis: inventory and SBOM quality, prioritisation and reachability, remediation pull requests, or policy gates. Rank them. A trial that tries to prove all four equally proves none of them well.

Name the people

Keep the developer panel small and real. Their reaction in week three is one of the strongest signals you will get, and it is hard to fake with a survey of people who never saw the output.

Set the boundaries in writing

Agree what the trial will not touch: usually no production deployment changes, no automatic merging, and no blocking gates on shared pipelines until the evaluation owner says so. Also agree what data the trial may see. If security review has not yet cleared a vendor to clone private repositories, start with the local runner or with scans inside CI, both described below. The plan works either way.

Choosing the scope

Picking repositories

Choose the smallest set that covers every shape you care about, one repository per category where you have one:

1. Your most important service, so you see findings on code that matters.
2. Your main language and package manager. The CI integration reads dependencies from lockfiles and manifests such as package-lock.json, go.sum, requirements.txt and pom.xml, so include one repository that commits its lockfile and, if you have one, one that does not.
3. A second ecosystem, for example a JavaScript front end next to a Java or Go back end.
4. A service that ships as a container image, to see how image scanning fits your registry.
5. An older repository, where version drift and abandoned components show up.

Five is a convenient ceiling for a small team in four weeks. Fewer is fine.

Picking one pipeline

Choose a CI pipeline you can edit without a change board: ideally the one for your most important service. The CI integration supports GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins and Azure Pipelines through documented templates, and any other CI that can run a shell step on a Linux or macOS runner with bash and curl. There is no plugin, Action or Pipe to install; every system runs the CLI in a plain shell step.

Deciding where scans run

Security reviewers ask this first, so settle it in week one. You can mix options in one trial.

For hosted SaaS, Safeguard's regions are the US, the EU (hosted in Frankfurt, Germany) and Gov. If your trial needs data to stay in the EU, say so at account creation.

For air-gapped evaluations, the Air-Gapped Deployment page notes that a scaled down single node setup works and that Safeguard ships a single virtual machine appliance image for that case. The weekly plan and scorecard still apply.

We go deeper on each deployment model in where your code and data go with Safeguard.

Success criteria written as questions

A target such as "reduce findings by some percentage" sounds rigorous but measures somebody else's environment and invites gaming. Write questions instead, and answer each from your own data with evidence the budget holder can see.

Resist a numeric target for noise reduction from reachability. The effect depends on the codebase (the language, how the application loads code, how much of a library it calls), so measure it on your repositories and record what you saw. And notice that several questions are answered by people, not the tool: the engineer who reviews a fix pull request, the developers who live with the output. Plan their time.

Week 1: account, access and connections

Week one is about getting the plumbing right and agreeing the deployment shape. Do not judge findings yet.

Day 1 and 2: create the account and the organisation

The Create an Account page describes sign up: go to safeguard.sh and choose Try for Free, or the enterprise route if you are evaluating under an enterprise agreement. Enter a work email, name, organisation and password, verify the email, then complete the profile and organisation setup, including which products to enable: Enterprise Software Supply Chain Manager (ESSCM), Portal, Third Party Risk Manager and Open Source Manager. For this plan ESSCM is the one that matters; add Portal if publishing and sharing SBOMs is part of your problem statement.

Invite the team under Settings → Members with + Invite Member. The documented roles are Tenant_Admin (full administrative access), Manager (manage projects, users and security configurations) and User (view and work with projects). A sensible split: Tenant_Admin for the evaluation owner and technical lead, Manager for the AppSec engineer, User for the developer panel.

If single sign on is in scope, set it up now rather than in week four. Safeguard supports SSO through SAML 2.0, Google, OpenID, Microsoft and GitHub.

Day 2 and 3: connect source control, or set up the runner

If your review allows a connected integration, follow the Onboarding Workflow page: Settings → Integrations, choose Connect next to your provider (GitHub, GitLab, Bitbucket, Azure Repos or AWS CodeCommit), authorise access and select the in-scope repositories. For container registries, the same page lists Docker Hub, AWS ECR, Google GCR and Azure ACR, with credentials and a connection test.

If your review does not allow it yet, use the local runner, which is part of the CLI rather than a separate product. Install it with the documented one line installer (our walkthrough on how to install the Safeguard CLI and scan a repo in five minutes goes step by step):

# macOS and Linux
curl -fsSL https://cli.safeguard.sh/install | bash

# Windows
irm https://cli.safeguard.sh/install.ps1 | iex

Then open the interactive terminal and sign in:

safeguard

Type /login, approve the session in the browser that opens, and the runner starts. The first run also downloads the scanner tools and the vulnerability database. From then on the machine polls the platform for jobs assigned to it, runs each job locally and uploads only the resulting SBOM and findings. All traffic is outbound HTTPS that the runner opens; nothing connects to it.

For a shared build box or a long running evaluation machine, the runner also has a headless mode:

# Start without the terminal UI and serve assistant turns for this workspace
safeguard runner start --workspace ./path/to/repo

# Is it running, and what is it doing
safeguard runner status

# Drain in-flight work and stop
safeguard runner stop

On networks that forbid held connections, --poll-wait 0 switches the runner to polling at a fixed interval. The CLI is a single static binary with no runtime to install alongside it, which helps on locked down laptops.

Day 4 and 5: add the projects

With an integration connected, add each repository under Projects → + Add Project: choose the integration source, the repository or image, the branch and version. Each project appears in the Projects table with a findings summary by severity and a vulnerability count. With the runner, /scan . in the interactive terminal scans the folder you are in. For more detail on this step, see onboard a new repository to Safeguard.

By the end of week one, every in-scope repository should be a project and the deployment decision should be written down with its reasons. If not, extend week one rather than compressing week two. Findings on half configured projects mislead, and misleading findings poison the rest of the trial.

Week 2: first scans, SBOMs and findings

Week two is where you start answering the inventory and prioritisation questions. The work is mostly reading, with the developer panel joining for a short session at the end of the week.

Read the project overview

Open each project. The Info tab shows how it was generated (SCM, container or manual), the repository and branch, and charts for findings and vulnerabilities by severity, supply chain risk by component and findings by gate. The other tabs answer the evaluation questions:

Check the SBOM against what you need

If your problem statement is about inventory, this is the centre of week two. Export the SBOM for each project. Safeguard supports CycloneDX and SPDX: CycloneDX is now published as the Ecma standard ECMA-424, and SPDX is available as the international standard ISO/IEC 5962. If your customers ask for one format, check that one.

Then check fields. The reference point today is CISA's 2026 Minimum Elements for a Software Bill of Materials, published on 29 July 2026 as joint guidance with the NSA, the FBI and international partners. CISA says it updates and replaces the minimum elements the NTIA published in 2021. Check each exported SBOM against its field list, and record whether any gap comes from the tool or from your own build.

If your build already produces SBOMs, the CLI page lists safeguard validate for CycloneDX, SPDX and VEX documents. VEX, which CISA describes as a form of security advisory indicating whether a product is affected by a known vulnerability, matters later when you tell customers a CVE does not affect your product.

Read findings with reachability in mind

Reachability is the question most teams care about, and the easiest one to fool yourself on. The Vulnerability Prioritization page classifies each vulnerability as:

• Reachable: a real call path exists from your code to the vulnerable code.
• Conditionally reachable: a path exists but needs a feature flag, route or configuration that is not currently enabled.
• Unreachable: no call path exists in your compiled code.
• Unknown: the analyser could not decide, for example because of reflection, dynamic dispatch or native code. These are marked conservatively as potentially reachable.

Priority combines reachability with exploitability and context. Two of those signals are public. CISA's Known Exploited Vulnerabilities catalog lists vulnerabilities exploited in the wild. FIRST's Exploit Prediction Scoring System publishes a daily probability, between 0 and 1, that a published CVE will be exploited in the next 30 days. Safeguard ingests both.

To test reachability honestly:

1. Take findings from the top and the bottom of the priority list on a repository an engineer on your panel knows well.
2. Ask the engineer, without showing the classification, whether the application calls the vulnerable function.
3. Compare, and look at every disagreement. Often it is a code path the engineer forgot. Sometimes it is a limit of static analysis that the docs openly describe.
4. Write down what you found, including the disagreements.

A finding marked Unknown is not suppressed. A tool that is honest about what it cannot decide is easier to trust than one that hides uncertainty.

Look at deduplication

When more than one engine scans the same code, one issue can appear twice. AutoTriage deduplicates across scanners into a single correlated finding. Compare raw and triaged views on one project, check nothing you care about disappeared, and note the reduction AutoTriage reports for your own data.

Add the CI scan in report only mode

Late in week two, add the scan to your chosen pipeline, without failing the build. Setup is three steps on the CI/CD Integration page:

1. Create a secret key under Settings → Developer with the scopes scans:trigger and scans:read. You can lock it to one project, which is a good habit for a trial.
2. Store it in your CI as a secret named SAFEGUARD_API_KEY.
3. Add the step from your CI's guide and push.

For GitHub Actions, the documented workflow is short. Here it is with the --fail-on flag dropped, which the GitHub Actions page lists as the report only option:

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

No checkout step is needed, because Safeguard clones the repository. Each push becomes a new version of the project named after the branch and commit, so you can watch findings change across the trial.

If the repository is not connected as an integration, add actions/checkout@v4 before the step and --local to the command, and only results leave the runner. The CI docs note that SAST findings are shown in Safeguard but are not part of --fail-on yet. Two warnings from the GitHub Actions page: fork pull requests receive no secrets, so scan pushes only or treat pull_request_target with great care; and pin the CLI with SAFEGUARD_VERSION so a release does not change a build mid trial.

End of week two: the first developer session

Spend a short session with the developer panel. Show them the top of the priority list for their repository and ask three questions: is this right, is this useful, and what would you do next? Write the answers down verbatim. Feedback in week two can still change the trial; in week four it cannot.

Week 3: enforcement in warn mode, exceptions and a fix pull request

Week three tests whether Safeguard can change behaviour without breaking it. The rule is simple: nothing blocks until the evaluation owner says so, and that decision is made with evidence from this week.

We wrote a separate guide on this sequence for developer experience leads, with time budgets and friction surveys: rollout and measurement plan for security checks, from warn to block. The short version for a proof of value follows.

Understand where gates are evaluated

The Guardrails and Enforcement page is explicit: gates are evaluated by the platform on the scans it runs for your connected repositories, not by the CLI, and safeguard scan reports findings without failing the build.

Guardrails are written in YAML. Each policy has a target, one or more rules and an effect. The Policies and Gates page lists three actions for a failed policy: Block fails the gate, Warn lets the gate pass with a warning that names the policy, and Notify lets it pass and sends a notification to your configured channels. Rules evaluate against a document that combines SBOM, vulnerability, license, signature, provenance and reachability data. A warn mode rule for a trial, adapted from the docs example on the Guardrails page (same keys and condition, with the Warn effect instead of Block), looks like this:

apiVersion: safeguard.sh/v1
kind: Policy
metadata:
  name: warn-known-exploited-critical
spec:
  targets:
    - kind: Image
      labels:
        env: production
  rules:
    - id: no-known-exploited-critical
      description: Warn on production images containing KEV-listed critical CVEs.
      condition: |
        any(
          vulnerabilities,
          severity == "critical" AND kev == true
        )
      effect: WARN

Starting with WARN lets you see how often the rule would fire, on which projects, and for what, without stopping anyone. Our longer post on policy gates in CI with Safeguard covers the block, warn and notify patterns in more depth.

Step the pipeline up one notch at a time

Move the CI step through three settings across the week, and record what happens at each:

1. Report only (from week two): safeguard ci scan --wait. The step fails only if the scan itself fails or times out.
2. Gate with warnings allowed: add --fail-on-gate all. The CI docs say this fails the step when a policy gate is not Passed or Warning, so a gate that only warns lets the build through while still recording the warning.
3. Severity threshold, on a branch: on a test branch, add --fail-on critical and introduce a known vulnerable dependency on purpose. Confirm the build fails, read the output, and then revert. A deliberate failure on a branch is the cheapest way to prove the gate works before anyone depends on it.

At each step, note the time the scan adds to the pipeline and whether anyone on the developer panel noticed. Do not convert that into a target; just record it.

Grant and expire one exception

Every real gate eventually needs an exception, so test the process now. The Guardrails page describes time boxed exceptions: an approver with the right role grants an exception for a specific asset for a specific duration, the exception appears in the audit log, and it expires automatically. Emergency break glass exceptions need two person approval and trigger alerts in the security channel.

Grant one exception for a real finding, with a short duration and a written reason, then check that it shows in the audit record and that it expires. Your auditor will ask about exactly this.

Open one fix pull request

If remediation is part of your problem statement, this is the week to test it. The onboarding docs describe the manual path: open the Vulnerabilities tab of a project, choose AI Remediate, review the proposed fix and choose Create Pull Request. Griffin, Safeguard's security model, generates the remediation: upgrade recommendations, dependency conflict resolution and breaking change analysis.

Pick a finding where a fixed version exists, on a repository with tests, and send the pull request to an engineer on the panel. Ask them to review it as they would a colleague's change, and record whether it built, whether tests passed, whether it was the change they would have made, and whether they merged it. A rejection with a clear reason is useful evidence too.

Autonomous remediation, where Safeguard opens pull requests on its own, ships switched off with every category set to Manual. If you want to test it, enable it for one repository and one category, and keep merging manual. Leaving it off for the whole trial and deciding later is a perfectly good outcome.

Week 4: review, evidence and the exit decision

Week four is for deciding, not for new features. Freeze the scope on day one of the week.

Build the evidence pack

Collect, in one folder:

• The exported SBOM for each in-scope project, and your field check against the 2026 minimum elements.
• A sample of triaged findings with their reachability class and the engineer's view on each.
• Any fix pull requests, with the reviewer's notes and the outcome.
• CI run results at each enforcement step, including the deliberate failure on a test branch.
• The exception you granted and its audit record.
• The developer panel's written feedback from week two and week four.
• The security reviewer's notes on deployment, data handling and AI mode.

Safeguard can export data in many formats, including CSV, Excel, PDF, HTML, JSON and Markdown, so most of this pack comes straight from the platform.

Fill in the scorecard

Score each success criterion with one of three answers. Keep the reasoning to a sentence or two, with a pointer to the evidence.

Make the decision

Agree the decision rule in week zero and apply it now. A simple and honest rule:

• Yes when the criteria tied to your top ranked problem score Yes and nothing scores No.
• Extend when the top criteria score Extend for a reason you can name, such as an untested repository shape, and a short, scoped extension would settle it. Write the extension's scope and end date before you start it.
• No when a top criterion scores No, or the security review has a blocking concern without a path.

An extension is a real outcome, but one without a written scope is how evaluations die quietly.

Whatever the answer, write a one page summary for the budget holder: the problem statement, the scope, the scorecard, the decision and the next step. If the answer is yes, the next step is usually a rollout plan; our post on building a complete software asset inventory in a week is a good template for the first stage of that.

For security reviewers: data, deployment and AI

Security review often decides a trial before week one ends, so here are the usual answers up front, describing what is available today.

Where code goes

• With a connected integration, Safeguard clones the in-scope repositories to scan them.
• With the local runner, the scan runs on your machine and only the SBOM and findings are uploaded; source stays where it is. All runner traffic is outbound HTTPS that the runner opens.
• With CI in local mode, only results leave the CI runner.
• With private VPC, on-prem or air-gapped deployment, the platform runs in dedicated tenancy, in your data centre, or entirely inside your perimeter. The air-gapped stack receives signed snapshot bundles and no component inside the perimeter calls outbound.

Safeguard's hosted regions are the US, the EU (Frankfurt, Germany) and Gov.

How the platform connects

Safeguard does not hold open or persistent connections to your environment; the architecture polls, and request communication is encrypted. Enterprise customers get a tenant based structure with data isolation. Customer code, SBOMs and telemetry are not used to train shared models.

What the AI does, and how to turn it off

The AI mode is configurable per tenant:

• Full AI: Safeguard's own models in the loop, including Griffin, Safeguard's security model.
• Zero AI: the platform runs deterministically with no LLM anywhere in the loop, and the scanners still work.
• Bring your own model: use a model provider your organisation has already approved.
• Local and on-prem models: Safeguard's models running inside your own environment, including in air-gapped deployments.

For a trial under a strict AI policy, start in Zero AI and note which evaluation questions still get answered. Inventory, SBOMs, vulnerability matching and gates do not depend on an LLM. You can then decide whether to switch AI on for the remediation questions.

Certifications, stated precisely

Safeguard is SOC 2 Type II compliant. Safeguard's architecture is designed for FedRAMP High; that is a design target, not an authorisation. If your review needs a completed report or an authorisation, record that as an open item in the scorecard rather than a blocker you discover in procurement.

Mapping the trial to NIST SSDF

Many buyers tie a tooling evaluation to NIST's Secure Software Development Framework. SSDF version 1.1 is defined in NIST SP 800-218, published in February 2022, and NIST has since finalised SP 800-218A, a community profile for generative AI and dual use foundation models. The table is general information about the evidence a proof of value can produce for each SSDF practice group. It is not a compliance claim: using a tool does not make a programme conform to SSDF.

Two other public references help as context. SLSA defines build levels from Build L0 (no guarantees) through Build L1 (provenance exists) and Build L2 (hosted build platform) to Build L3 (hardened builds); note which level your in-scope builds reach today. OpenSSF Scorecard runs automated checks on open source repositories, a quick health check for a dependency you are unsure about. NIST SP 800-161 Revision 1 is the broader frame for supply chain risk management if procurement wants one. Some questionnaires still reference CISA's Secure Software Development Attestation Form from March 2024; CISA's page for it is now marked as archived, so answer in terms of the SSDF practices instead.

Starting at no cost

You do not need a contract for the first two weeks. The main platform has a free plan that includes scanning, reached through Try for Free on safeguard.sh. That is enough to connect a repository, produce an SBOM and read findings.

Do not confuse it with Portal's free entry. The Portal docs page is explicit that Portal is the product for publishing, sharing and redistributing SBOMs, with the Trust Center in front of it, and that its free entry covers publishing, not scanning. The later weeks of this plan (organisation roles, SSO, shared policies and gates, enterprise deployment models) belong to paid tiers, so plan the move from a free start to a scoped evaluation before week three. This post does not quote prices.

What this plan does not tell you

• It is an illustrative scenario. The weeks, roles and examples are a template to adapt.
• It contains no results. No noise reduction figures, time savings or customer outcomes. Use only figures from your own repositories.
• It does not replace your security review. The reviewer section lists what is available; the decision is still yours.
• It covers code and images you build. If most of your exposure is in vendor appliances, hosted services or operating system runtimes you do not build, a dependency focused trial will not tell you much about it.
• Reachability has limits with reflection, dynamic dispatch, native code and configuration dependent paths, and the docs say so.

Common mistakes

Starting without a decision rule. If yes, extend and no are not defined before week one, the trial ends in an argument rather than a decision.

Scoping for volume. Connecting every repository in week one looks impressive and makes the trial impossible to read.

Leaving security review to the end. A trial can fail in week four on a question that had a good answer in week one. Decide connected integration, local runner or CI local mode early.

Blocking builds on day one of week three. Go report only, then warn, then a deliberate failure on a branch. A surprise red build on a shared pipeline can end a trial for reasons unrelated to the product.

Using a number you did not measure. A noise reduction figure from somebody else's codebase is not evidence about yours.

Testing remediation on a repository without tests. A fix pull request on untested code tells you little.

Forgetting fork pull requests and version pinning. Fork builds usually get no secrets, and an unpinned CLI can change behaviour mid trial.

Ignoring the developer panel until the end, and letting an extension run without its own scope and end date.

FAQ

How long should a software supply chain security proof of value take?

Thirty days is a practical default. It covers setup, first scans, a week of enforcement in warn mode and a week to review and decide, across at least one or two sprint boundaries. Shorter trials tend to skip enforcement, and longer ones tend to lose attention.

How many repositories should we include in a proof of value?

Enough to cover each language, package manager and build shape you care about, plus one container image and one pipeline. For most teams that is a handful. More repositories add noise without adding new information.

Can we evaluate Safeguard without giving it access to our source code?

Yes. The local runner built into the Safeguard CLI runs scans on your own machine and uploads only the SBOM and findings. In CI, safeguard ci scan --local scans a checkout inside the job so only results leave the runner. Private VPC, on-prem and air-gapped deployments are also available.

What success criteria should we use for an SCA or SBOM tool trial?

Write questions your own data answers: can we see every component, do the SBOMs carry the fields we need, can we tell what is reachable, does a fix pull request land cleanly, does a gate behave as expected, can we grant and expire an exception, and do developers accept it. Avoid target numbers you have not measured.

Should policy gates block builds during the trial?

Not at first. Start in report only mode, move to gating with warnings allowed, and prove a block with a deliberate failure on a test branch. Decide whether to block shared pipelines only after you have seen how often each rule fires.

Does Safeguard's autonomous remediation run during a trial?

Only if you turn it on. It ships switched off, with every category set to Manual. You can test fix pull requests manually with AI Remediate on a single vulnerability, and decide later whether any category should run on its own.

Can we run the evaluation with no AI in the loop?

Yes. Zero AI mode runs the platform deterministically with no LLM, and the scanners still work. Start there if your AI policy requires it, and switch AI on later for the remediation questions if your review allows.

Is there a free way to start?

Yes. The main platform has a free plan that includes scanning, reached through Try for Free on safeguard.sh. Portal, the product for publishing and sharing SBOMs, has its own free entry, which is a different thing. Enterprise features used later in this plan belong to paid tiers.

Which regions does Safeguard's hosted service run in?

The US, the EU (hosted in Frankfurt, Germany) and Gov. Private VPC, on-prem and air-gapped deployments are available when a hosted region does not fit.

Why remediation belongs in the trial

A proof of value is a good time to see what happens after a finding, not only how it is found, because the long tail of supply chain risk lives in the gap between knowing and fixing. The section below is the remediation story you would be evaluating in week three, written the same way we describe it everywhere.

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, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. 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. Auto-merge is a separate switch and stays off by default, so your team decides what merges 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.

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

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) 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 build of a specific package. 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

These three demos are recorded product sessions, not your data. Treat them as a look ahead at what your technical lead will do in weeks one and three.

The first is a real Safeguard CLI session. It installs the CLI, opens the interactive terminal with safeguard, asks it to fix the lodash CVE in a repository, and shows it reading the finding and the advisory, asking before any command that changes something, editing package.json to lodash 4.17.21, and running npm install and npm test with approval. It prints a summary and pushes nothing, then shows /permissions, /model and /scan .. In this plan, it is the week three remediation test on a developer's machine.

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

The second sets up the local runner on your own machine, approves it with its device code, and scans from the terminal. It is the week one path for teams whose security review will not yet allow a connected integration, because the scan runs locally and only results leave the machine.

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

The third connects Claude to the Safeguard MCP server with OAuth and chooses which tools Claude can use. If your evaluators already work with an assistant, it shows how they can ask about trial results in plain language while controlling what the assistant may touch.

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

When you are ready to start week one, get the desktop app or the CLI from safeguard.sh/download, and keep the CLI documentation open alongside this plan.

Quick check

Sources

• Safeguard Docs: Getting Started
• Safeguard Docs: Create an Account
• Safeguard Docs: Onboarding Workflow
• Safeguard Docs: Safeguard CLI
• Safeguard Docs: Local Runner
• Safeguard Docs: CI/CD Integration
• Safeguard Docs: GitHub Actions
• Safeguard Docs: Guardrails and Enforcement
• Safeguard Docs: Policies and Gates
• Safeguard Docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard Docs: AutoTriage
• Safeguard Docs: Griffin AI
• Safeguard Docs: Portal
• Safeguard Docs: Air-Gapped Deployment
• NIST SP 800-218, Secure Software Development Framework Version 1.1
• NIST CSRC: Secure Software Development Framework project
• NIST SP 800-161 Rev. 1, Cybersecurity Supply Chain Risk Management Practices
• CISA: Software Bill of Materials
• CISA: 2026 Minimum Elements for a Software Bill of Materials
• CISA: Secure Software Development Attestation Form (archived)
• CISA: Known Exploited Vulnerabilities Catalog
• FIRST: Exploit Prediction Scoring System
• SLSA v1.0: Security levels
• OpenSSF Scorecard
• CycloneDX specification overview
• SPDX overview

Last reviewed: 27 October 2026. Product steps were checked against docs.safeguard.sh on that date; check the linked pages for changes before you start.