Rolling Out Security Checks: A DevEx Lead's Measurement Plan

You own developer experience, and security wants new checks in every pipeline by next quarter. The plan that works is a written contract: a time budget and a noise budget agreed with security before anything ships, a short friction survey read next to your delivery metrics, and a rule that no check moves from Warn to Block until its own evidence says it is ready.

This post is that plan, written for the person who has to defend both the developers' week and the security team's risk register. It does not repeat the advice on making checks fast and quiet in the IDE, the pull request and CI; two earlier posts already cover that well, Shift-Left Without Friction and DevEx Meets DevSecOps, and Developer Friction Budget For Supply Chain Tools covers how to split attention across surfaces. Read those for the surface design. This one is about the rollout: who agrees what, what you measure, and when a check earns the right to stop a merge.

Key takeaways

• Agree budgets before rollout, in writing. A time budget (how much a check may add to a pipeline or a pull request) and a noise budget (how many findings a developer may be shown, and how many of those may turn out to be wrong) turn "security slows us down" into numbers both teams own.
• Measure friction and delivery together. A short, repeated survey of how developers experience the checks only means something next to delivery measures such as change lead time and deployment frequency, which the DORA research program defines and publishes.
• Use SPACE to stop a single number winning. The SPACE paper recommends a handful of metrics across at least three dimensions, with at least one perceptual measure such as survey data. A rollout scorecard should follow the same rule.
• Start every check at Warn. Promote it to Block per check, per repository group, when the evidence meets criteria written down in advance. Demote it the same way.
• Exceptions are the release valve, not a loophole. A time boxed, justified, approved exception is how a developer gets past a blocking check that is wrong for their case, and the exception log is one of your best friction signals.
• Safeguard capabilities in this post, all GA: Policies, Gates and Guardrails (GA) with Block, Warn and Notify actions and approval through exceptions; policy outcomes per gate and per policy (GA); CI integration with safeguard ci scan (GA); the Safeguard CLI and local runner (GA); IDE extensions (GA); plain English policy creation (GA); reachability analysis and prioritisation (GA); autonomous remediation (GA, ships switched off).

The situation

The request usually lands as a deadline. A security lead has a new standard to meet, an audit finding to close, or a board question to answer about what stops a known vulnerable dependency reaching production. Their proposal is a set of checks in CI with a hard fail on anything critical, switched on across every repository at once.

You have seen how that goes. On day one, a few dozen pipelines go red for findings nobody on the team introduced. On day two, someone with admin rights merges around the check. By the end of the week, the most senior engineers have learned to ignore the security job entirely, and the security lead has a report showing high coverage and almost no fixes.

A bad week has a specific shape:

• Pull requests that were mergeable on Friday are blocked on Monday by a rule nobody announced.
• The block message names a CVE and a package three levels down, with no hint of which direct dependency to change.
• Pipeline time goes up, and nobody agreed how much it was allowed to go up.
• Developers ask for exceptions in chat because there is no form, so the security team cannot see the pattern.
• Leadership asks whether the rollout is "working" and the only numbers available are scan counts.

You can prevent that week, because you already own what the rollout touches: pipeline time, developer surveys and the internal platform. What you need is a plan that security signs and that produces evidence rather than opinions.

The frameworks behind the plan

None of this needs a new methodology. Four published sources do most of the work, and each is worth reading at the source rather than through a summary.

DORA: the delivery side of the scorecard

DORA's metrics guide (last updated 5 January 2026) names five software delivery performance metrics in two groups. Throughput covers change lead time, deployment frequency and failed deployment recovery time. Instability covers change fail rate (the share of deployments that need immediate intervention) and deployment rework rate (the share of deployments that are unplanned and caused by a production incident).

Three points from that guide matter for a security rollout. The metrics are best suited to measuring one application or service at a time, so blending them across very different teams misleads. Turning a metric into a target invites gaming; the guide names Goodhart's law. And no single metric should rule: the guide advises several metrics, some with a healthy tension between them. The guide's suggested first step is to set a baseline before trying to improve anything.

For a security check rollout, that framing is exactly right. You are not asking whether developers are working hard. You are asking whether a new check changed how quickly and safely a service ships. If change lead time for a repository group rises after a check goes live and the friction survey says the check is the reason, you have a finding you can act on.

DORA also publishes a capability guide on pervasive security, which describes building security into daily development work and automating it into the deployment pipeline rather than testing for it at the end. Among its common pitfalls, it calls failing to collaborate with the InfoSec team the biggest mistake. That is a useful neutral reference when security and engineering disagree about where a check belongs.

SPACE: why one number is never enough

"The SPACE of Developer Productivity", by Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck and Jenna Butler (ACM Queue, and Communications of the ACM, June 2021), names five dimensions: satisfaction and well being; performance; activity; communication and collaboration; and efficiency and flow.

Its advice on use is specific. Capture several metrics across multiple dimensions, and the authors recommend at least three. Make at least one of them a perceptual measure such as survey data. Expect the metrics to pull against each other, which the authors say is by design. Keep the set to a handful, because too many metrics lower motivation. And report only anonymised, aggregate results at the team or group level.

That is the guard rail for your scorecard. Pipeline minutes alone (an efficiency measure) would tell you a check is cheap even when developers hate it. Survey scores alone would tell you developers are unhappy without saying whether delivery suffered. You want both, read together.

DevEx: what to ask in the survey

"DevEx: What Actually Drives Productivity", by Abi Noda, Margaret-Anne Storey, Nicole Forsgren and Michaela Greiler (ACM Queue, March and April 2023), names three core dimensions of developer experience: feedback loops, cognitive load and flow state. It recommends capturing developers' perceptions and their workflows across those dimensions, alongside a few top level KPIs.

Its survey advice is directly usable. Base questions on well defined constructs and test them in interviews. Break results down by team and persona rather than reading only the company average. Add transactional surveys, short prompts at a specific moment in the workflow, to complement periodic ones. And watch for survey fatigue.

Those three dimensions map cleanly onto security checks. A slow check is a feedback loop problem. A finding that needs twenty minutes of research to understand is a cognitive load problem. A blocking check that fires after the developer has moved on to the next task is a flow problem. Write your survey questions against those ideas, not against "how do you feel about security".

Error budgets: the model for time and noise budgets

Site reliability engineering already has a working model for an agreement between two teams with opposite instincts. The Google SRE workbook's example error budget policy is a short document with named authors, reviewers and approvers, a revisit date, goals, explicit non goals, the action taken when the budget is spent, and an escalation path for disagreements. Its non goals say the policy is not meant as a punishment. The point is not the number. The consequence is decided before anyone is angry.

A time budget and a noise budget for security checks follow the same pattern, and you can copy the structure section for section. Security agrees in advance how much pipeline time and developer attention a check may consume. Engineering agrees in advance that a check within budget will be promoted to Block when its evidence is ready. When a check overspends, the written policy says what happens.

The security side: NIST SSDF and what "criteria for checks" means

The security lead will want the plan anchored in a standard they can cite. NIST SP 800-218, the Secure Software Development Framework (version 1.1, February 2022), has a practice for exactly this: PO.4, define and use criteria for software security checks. Task PO.4.1 asks you to define criteria for software security checks and track them throughout the SDLC; its examples include defining KPIs and key risk indicators, adding security criteria to existing checks such as a Definition of Done, and recording security check approvals, rejections and exception requests in the workflow. Task PO.4.2 asks for processes and mechanisms that gather and safeguard the information behind those criteria, and its examples include automating decisions with the criteria and reviewing those processes periodically.

Your rollout plan is a direct way to meet PO.4: the criteria for promoting a check from Warn to Block are criteria for security checks, written down, with the data to decide them, and the exception log is the record PO.4.1 describes. That is a useful sentence to put in front of a security lead who worries that a phased rollout looks soft. It is the opposite.

NIST's SP 800-55 Volume 1 (December 2024) gives guidance on developing information security measures that show whether policies, procedures and controls are adequate, and on prioritising and evaluating those measures. Borrow its discipline: keep only the measures that show whether a control is working, and evaluate them before you rely on them.

This post interprets public frameworks; it is not legal, regulatory or audit advice.

Step by step: the rollout and measurement plan

These steps work with whatever scanner, CI system and survey tool you already have. Nothing here requires Safeguard.

1. Inventory the checks and the surfaces

List every security check that is running or proposed, and for each one, where a developer meets it: in the editor, on the local machine, in the pull request, in CI after merge, or at release. Note who owns its configuration and who owns its findings.

Most organisations find three things in this inventory. Some checks run twice in different places. Some have no owner for their false positives. Some fire at a point in the workflow where nobody can act on them. Fix those before measuring anything, because they will dominate your friction data otherwise.

2. Write the time budget

A time budget is a ceiling on how much a check may add to the developer's wait, at the surface where they wait for it. Agree it per surface, because the tolerance differs.

Use percentiles. An average hides the slow repository that makes one team miserable. The 90th percentile is a reasonable default for pull request checks because it captures the slow tail without being dominated by one pathological job.

Write down the timeout behaviour too. If a security check times out, does the pipeline pass, fail or wait? Agree this in advance; it is the single most common cause of an angry thread on rollout day.

3. Write the noise budget

The noise budget is harder and more important. It has two parts.

Volume. How many new findings may a developer be shown on one pull request before the check is considered too noisy? A common rule is that a pull request check should report only findings the change introduced or made worse, and leave existing findings to a separate backlog process. Write the rule down; the volume budget follows from it.

Precision. Of the findings a developer is shown, how many may turn out to be wrong, not applicable or not worth fixing? You measure this from the dispositions developers and reviewers record: fixed, accepted risk, false positive, not applicable. Agree the threshold above which a check goes back to Warn for tuning.

Both teams sign the noise budget. Security commits to tuning a check that overspends. Engineering commits to recording dispositions honestly, because without them precision cannot be measured.

4. Pick a small scorecard

Choose four to six measures and no more. A workable set:

Notice what is not on it: number of scans, number of repositories covered, total findings. Those measure the tool running, not the rollout working. Keep them for the security team's own reporting.

5. Run the friction survey

Keep it short enough that people finish it: six to eight questions, repeated on a fixed cadence (every four to six weeks during rollout, then quarterly), sent to the same population each time so the trend means something.

Write the questions against the DevEx dimensions. A template you can adapt:

Three rules make the survey work. Name the check, not "security tooling" in general, so the answer can be acted on. Report results by team and by persona (for example mobile, backend, data), never by individual. And close the loop in public: after each round, say what you changed because of it.

Add one transactional question too. When a security check fails a pull request, a single optional prompt in the job summary or the team's chat ("Was this finding useful? Yes, no, not sure") gives you per check, per event data between survey rounds without adding another form.

6. Establish a baseline before any check goes live

Measure for two to four weeks before switching anything on: pipeline times, change lead time, deployment frequency and one survey round. Without a baseline, every complaint after rollout is unfalsifiable, and so is every claim that the rollout did no harm.

7. Roll out in Warn, one check at a time

Switch on each new check in a mode that reports but does not fail the merge. Developers see the finding where they work; the pull request still merges. This is not a soft launch for its own sake. It is how you collect the volume and precision data the noise budget needs, on real code, before the check can hurt anyone.

Roll out to a small group of repositories first, ideally ones whose teams volunteered. Expand by group, not all at once.

8. Promote from Warn to Block on written criteria

Write the promotion criteria into the same document as the budgets, before rollout starts, so they cannot be invented after the fact. A template:

When every row has evidence, promote. When a row fails, the check stays in Warn and the failing row tells you what to fix.

9. Write the demotion rule

Promotion without a way back turns into permanent tension. Agree in advance what sends a blocking check back to Warn: for example, its precision falls below the agreed budget for two weeks in a row, its added time breaches the budget, or the exception rate for one check rises sharply. Demotion is not failure. It is the noise budget working.

10. Run the exception process as a measurement instrument

Every exception should carry a justification, a scope (one finding, not "all findings in this repo"), an expiry date and an approver. Read the log weekly during rollout. Clusters tell you where the check is wrong: the same rule excepted across many repositories is a rule problem, not a developer problem.

11. Publish the scorecard on a fixed cadence

Send the same one page every two weeks during rollout to the security lead, engineering managers and the people who sponsor both teams. Same measures, same order, with the state of each check (Warn, Block, demoted) and the reason. Consistency is what makes the page trusted.

12. Review the budgets themselves each quarter

Budgets are not permanent. As checks get faster and more precise, tighten them. When a new class of check arrives, write its budget before it ships. Treat the budget document as a living agreement owned jointly, with a named owner on each side.

How do we agree time and noise budgets with the security team?

Start from what each side needs to be true, not from numbers. Security needs confidence that a known class of risk cannot reach production without someone deciding it should. Engineering needs confidence that the checks will not eat the week. The budget is how both are written down.

A practical sequence for the meeting:

1. Bring the inventory from step 1 and the baseline data from step 6. Numbers about today's pipelines end arguments about hypothetical ones.
2. Ask security to rank the proposed checks by the risk they address. Agree that the top ranked checks get the most budget and the earliest promotion path.
3. Propose the time budget per surface and let security push back. Most security leads accept a pull request ceiling once they see that post merge and nightly checks have no ceiling at all, so nothing is being hidden, only moved.
4. Propose the noise budget as a precision floor and a volume ceiling, measured from dispositions. Security's main objection is usually that developers will mark real findings as false positives to stay within budget. The answer is sample review: a security engineer reviews a small sample of dispositions each week.
5. Write down what happens when a check overspends. This is the clause that makes the rest real.
6. Both leads sign. Put the document where everyone can read it.

The worked example below is illustrative only, with round invented numbers, to show the shape of the agreement.

Replace each value with your own. The structure is the point.

How do we run a friction survey alongside delivery metrics?

Run them on the same calendar and read them on the same page. The survey tells you how the check feels; the delivery measures tell you what it did to throughput and stability. Either one alone misleads.

Four patterns are worth knowing:

Keep the delivery measures at service level, as DORA intends, and never use either set of numbers to rank individuals. If your organisation already runs a broader developer experience survey, add the security questions to it rather than sending a separate one; survey fatigue is a friction source of its own.

How do we decide when a check moves from Warn to Block?

On evidence, per check, per repository group, against criteria written before rollout. The promotion table in step 8 is the template. Three further rules help.

Promote the narrowest useful rule first. "Block any newly introduced dependency with a critical vulnerability that has a fixed version available" is far easier to defend than "block anything critical". The narrower rule has a clear next step (upgrade to the fixed version) and rarely fires on code the developer did not touch.

Promote by repository group, not by organisation. Services that face the internet, handle payments or hold personal data may reach Block sooner, because the risk ranking from the budget meeting puts them first. Internal tools may stay in Warn longer. One size fits all thresholds are a known anti pattern.

Announce the date. A check that changes from Warn to Block without notice turns a planned change into a surprise outage for the teams it hits. A one week notice, with a list of repositories that would fail today, gives teams time to clear existing findings first.

What should we do with findings that already exist?

Separate them from the pull request flow. A blocking check that fails a pull request for a vulnerability the developer did not introduce is the fastest way to lose the room. Track existing findings as a backlog with its own owner, its own service level and its own scorecard line, and keep the blocking checks focused on what each change adds or makes worse.

What about Notify?

Some checks should never block and should not clutter the pull request either: for example, a licence policy the legal team wants to know about, or a component age rule that informs planning rather than gating a merge. A notification to the owning team's channel, sent when the rule starts failing rather than on every run, keeps that information flowing without adding to a developer's wait or noise budget.

How Safeguard does this

Safeguard's policy and gate model maps directly onto the plan above. Everything in this section comes from the Safeguard offering and docs.safeguard.sh; where the docs show a command or screen, it is named exactly.

1. Connect repositories and CI. CI integration (GA) runs Safeguard scans from GitHub Actions, GitLab CI/CD, Bitbucket Pipelines, Jenkins, Azure Pipelines or any CI. For GitHub Actions, the docs have you create a secret key under Settings → Developer with the scans:trigger and scans:read scopes, store it as the SAFEGUARD_API_KEY repository or organisation secret, and add this workflow, shown exactly as the docs give it (we have not run it for this post):

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

For the baseline weeks (step 6), the docs' "Report only" option is to drop --fail-on critical, so the job reports results without failing.

2. Write policies, with conditions you can explain. Policies, Gates and Guardrails (GA) are created under Settings → Policies with a visual builder or YAML. The docs list conditions such as vulnerability severity, CVSS score, EPSS score, licence, component age and maintenance status, and pre built templates such as "No Critical Vulnerabilities" and "No Abandoned Packages". Policy creation from plain English prompts is also GA, which helps when the security lead's rule starts life as a sentence in the budget document.

3. Give each policy an Action that matches its rollout stage. Per the docs, each policy has one Action that decides what a failed policy does to its gate:

   Action	What happens when the policy fails
   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: the in app bell, connected chat integrations, and email according to each person's preferences

   That is the Warn to Block path in product form: a new check starts as a Warn policy on the gate, and promotion is a change of Action from Warn to Block once your criteria are met. Demotion is the reverse. Notify suits the never block checks above, and the docs say it notifies when a policy goes from passing to failing, and again when a failing policy finds new matching issues, rather than on every evaluation.

4. Fail CI on the gate, not on a raw severity. With policy outcomes on for the workspace, safeguard ci scan --wait --fail-on-gate all (or a named gate) waits for the scan and the gate's policies, then exits 0 when the gate is Passed or Warning, printing the warnings and notified policies, and exits non zero when the gate is Failed, printing the Block policies that failed. It also exits non zero when the gate is in Error or Not evaluated, or its policies were not evaluated before the timeout. The docs' GitHub Actions options table adds --fail-on-gate all to the same command. Agree in your budget document that an Error is a fail; the docs say an Error is never counted as a pass.

5. Read outcomes as rollout evidence. Policy outcomes record Passed, Failed, Warning, Not evaluated or Error for each policy and gate, with when it was last evaluated, under Policies → Gates and Policies → Policies. Expanding a gate shows each linked policy's Action, outcome, effect on the gate and matches, plus the gate's evaluation history. A Warn policy's history is the evidence for promotion: how often it would have blocked, and on what. The docs note that policy outcomes are turned on per workspace by Safeguard, so ask your Safeguard contact if the Outcome column is not showing yet.

6. Route the release valve through exceptions. Approval is handled through policy exceptions, not a separate gate action. The docs' exception flow is: request an exception, select the policy and finding, provide a business justification, set an expiration date and submit for approval; approvers are notified, decide, and the audit trail is recorded. The exception history is part of compliance reporting, which gives you the exception log from step 10 without a spreadsheet.

7. Shorten the feedback loop where developers work. IDE extensions (GA) for VS Code, Cursor and JetBrains IDEs scan dependency manifests as you work and show vulnerabilities inline. The Safeguard CLI and local runner (GA) let a developer run safeguard scan --dir . before pushing; per the docs, that command does not fail on findings (it exits 0 whenever the scan ran) and leaves gating to policy gates in the platform, which is the right split for a feedback surface. Scanning with /scan . from the interactive terminal while signed in uploads the SBOM and findings, never the source. A finding a developer has already seen locally is less likely to be a surprise in the pull request.

8. Keep the precision budget honest. Reachability analysis and prioritisation (GA) ranks findings by whether vulnerable code paths are actually called, alongside EPSS and KEV, which is the kind of signal that helps a narrow Block rule fire on the findings that matter. We do not quote a noise reduction figure; measure your own precision from dispositions.

9. Make the next step a pull request. Autonomous remediation (GA) can open a tested, policy gated pull request that moves an affected dependency to a fixed version. It ships switched off, with every category set to Manual, so your team decides how much it does on its own. For a DevEx lead, its value is in the finding message: "here is the pull request" is the clearest possible next step.

10. Let assistants read the gate state. The docs say Safeguard's MCP server (GA) has read only tools for gate outcomes, policy outcomes and evaluation history, when outcomes are on and MCP access settings allow it. That lets a developer ask an assistant why a gate is warning without opening another screen.

What Safeguard does not do

• It does not set your budgets. The time budget, noise budget, promotion criteria and demotion rule are agreements between your teams. Safeguard enforces the Action you choose; it does not decide when a check is ready for Block.
• It does not run your friction survey or compute DORA metrics. Survey design, delivery metrics and the scorecard come from your own survey tool and delivery data. Safeguard supplies policy outcomes, findings and the exception log as inputs.
• It does not measure developer sentiment. No scanner can tell you whether a check feels fair. Only asking developers can.
• It does not approve exceptions for you. The exception workflow records justification, expiry and approval, but a person on the security side still decides each one.
• Policy outcomes are switched on per workspace by Safeguard. Until they are on, the Outcome column and --fail-on-gate behaviour described above are not available, and gates behave as they did before.
• It does not fix CI platform limits. The docs note, for example, that pull requests from forks do not get secrets in GitHub Actions; you still design around your CI platform's own rules.
• It does not promise a noise reduction number. Reachability ranking helps precision, but your precision budget must be measured on your own code.

Common mistakes

• Switching on Block everywhere on day one. It produces the bad week described above and spends trust you will need for every later check.
• Measuring the tool instead of the rollout. Scan counts and coverage percentages say the tool is running, not that developers can work with it.
• Averages instead of percentiles. The average pipeline time can look fine while one team's builds double.
• Ranking people with the data. DORA measures are for services; survey results are for groups. Used on individuals, both stop being honest.
• No demotion rule. If a check can only ever move towards Block, every disagreement becomes an escalation.
• Exceptions in chat. An exception without scope, expiry and an approver is an invisible permanent waiver, and you lose your best friction signal.
• Blocking on existing findings. Pull request checks that fail for problems the developer did not introduce teach people to route around the check.

FAQ

What is a time budget for security checks?

It is a written ceiling, agreed between the DevEx and security leads, on how much time a security check may add at the point where a developer waits for it, usually measured at the 90th percentile of added time to required pull request checks. It says nothing about checks that run after merge, where nobody waits.

What is a noise budget?

A noise budget limits how many findings a check may show a developer on one change (volume) and how many of those may turn out to be false positives or not applicable (precision), measured from the dispositions developers and reviewers record.

Which DORA metrics should a DevEx lead track during a security rollout?

Change lead time and deployment frequency show whether throughput changed; change fail rate shows whether stability changed. Track them for the services where a check is live and compare against the baseline. DORA's guide says the metrics are best applied to one application or service at a time and warns against turning them into targets or competitions.

How does the SPACE framework apply to security tooling?

SPACE recommends several measures across at least three of its five dimensions, including a perception measure. For a security rollout that means pairing system measures such as added pipeline time with a survey of how developers experience each check.

How many questions should a developer friction survey have?

Six to eight, repeated on a fixed cadence, about named checks, with one open text question. Short and repeated beats long and occasional, because the trend is what you act on.

How long should a check stay in Warn before moving to Block?

Long enough to meet the promotion criteria you wrote in advance: enough pull requests to measure volume and precision, two survey rounds, and stable delivery measures. That is a matter of weeks for most checks, not days.

Should every check eventually block?

No. Some checks inform planning or another team, such as licence or component age rules, and are better as notifications. Blocking is for rules with a clear, fast next step and a risk both teams agreed is worth stopping a merge for.

How do we stop developers marking real findings as false positives?

Sample review. A security engineer reviews a small sample of dispositions each week, and disagreements are discussed openly. Pair it with a noise budget so a check that genuinely overspends goes back to Warn rather than training people to dismiss it.

What does NIST SSDF say about security check criteria?

Practice PO.4 of NIST SP 800-218 asks organisations to define criteria for software security checks and to gather the information needed to decide on them. Written promotion criteria from Warn to Block, with the data to support them, are one direct way to meet it.

Can Safeguard warn without failing the build?

Yes. A policy with the Warn action lets the gate pass with a warning that names the policy, and safeguard ci scan --wait --fail-on-gate exits 0 on a Warning while printing it. Changing that policy's Action to Block makes the gate fail.

Make every blocking check point at a fix

A Block rule is easiest to defend when the developer's next step is obvious and fast, and when the fix exists before the check fires. The section below covers how Safeguard closes that gap for open source dependencies, so a blocking check points at a fix rather than a dead end.

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

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

Gold Registry provides hardened, drop in replacements for upstream packages and container images. 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, compatibility tested 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

The first demo is a real Safeguard CLI session: install, run safeguard to open the interactive terminal, ask it to fix the lodash CVE in a repository, and watch it read the finding and advisory, ask before any command that changes something, edit package.json to lodash 4.17.21, run npm install and npm test with approval, print a summary and push nothing. It then shows /permissions, /model and /scan . For a DevEx lead, it shows the kind of local, before push feedback loop that keeps pull request checks inside their time budget.

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. It is the earliest surface in the time budget table: a developer can see findings before the pull request ever opens.

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 chooses which tools Claude can use. The same connection is how an assistant can read gate and policy outcomes, so a developer can ask why a check is warning without leaving their conversation.

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

Quick check

Related reading

• Shift-Left Without Friction: Dev Experience 2026
• DevEx Meets DevSecOps: Why Developer Experience Determines Security Outcomes
• Developer Friction Budget For Supply Chain Tools
• PR-Time Policy Gates Developers Accept
• How to set up a CI/CD pipeline security gate
• How to reduce alert fatigue from vulnerability scanners

Sources

• DORA: software delivery performance metrics
• DORA capability: pervasive security
• Forsgren, Storey, Maddila, Zimmermann, Houck, Butler: The SPACE of Developer Productivity, ACM Queue (also Communications of the ACM, June 2021)
• Noda, Storey, Forsgren, Greiler: DevEx: What Actually Drives Productivity, ACM Queue, March and April 2023
• Google SRE workbook: example error budget policy
• NIST SP 800-218, Secure Software Development Framework version 1.1
• NIST SP 800-218 full text (PDF)
• NIST SP 800-55 Volume 1, Measurement Guide for Information Security
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: GitHub Actions
• Safeguard docs: IDE support
• Safeguard docs: CLI usage

Start with the Safeguard download page and the Safeguard docs.

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