Safeguard Autonomous Remediation: Categories, Strategies, Off by Default

Autonomous remediation in Safeguard (GA) turns security findings into fix pull requests instead of tickets. Griffin, Safeguard's security model, analyses each finding, picks an upgrade path, checks for breaking changes, opens a pull request and runs your tests. It ships switched off, with every category set to Manual, so nothing changes in your code until your team turns it on and decides how much runs by itself.

This post explains why remediation timelines are hard to hit with ticket queues, what a Griffin fix pull request contains, which remediation categories exist, what the Safest, Balanced, Aggressive and Smart strategies mean, and how to roll the feature out one step at a time. It also covers how fixes interact with your policies and gates, how to preview a fix from the command line, and the limits you should plan around.

Key takeaways

• Autonomous remediation (GA, ships off). Griffin opens fix pull requests for a single finding or in bulk, one pull request per repository. Every category starts on Manual and nothing is applied until the master Autonomous Remediation toggle is enabled.
• Categories. Safeguard describes remediation as eight categories (Dependencies, License, Security Posture, Findings, Attestation, Provenance, Compliance and Code Quality). Its category matrix also lists Vulnerabilities (CVE remediation) as its own row, so you will see nine names in some places. Each one is set to Manual or Auto on its own.
• Strategies. For vulnerabilities and dependencies: Safest (backward compatible fixes only), Balanced (minor and patch updates), Aggressive (every available fix, including major versions) and Smart (the model chooses per item). Other categories have their own options.
• Reachability analysis and prioritisation (GA). Fixes for code paths your application actually calls can be ranked first. Some languages are marked Preview in the docs.
• Policies, gates and guardrails (GA). A fix pull request goes through the same gates as any other change. safeguard ci scan --wait --fail-on-gate fails a CI job when a gate fails.
• Safeguard CLI (GA). safeguard fix works on a manifest from your terminal, and its help lists a preview option so you can see changes before anything is written.
• Gold Open Source (GA) and Gold Registry (GA) supply safe versions and hardened builds. Fork and patch for packages with no upstream fix is early access.
• Your tests and reviewers still decide. Breaking change detection labels risk; it does not replace your test suite or a human review of major upgrades.

Why remediation timelines are hard to meet

Most security programmes do not fail at finding vulnerabilities. They fail in the weeks after. A scanner reports a vulnerable library, a ticket lands in a backlog, and the fix waits until someone has time to read the advisory, work out which version is safe, change the manifest and lockfile, run the tests and get a review. Each of those handoffs is small. Together they are why the gap between "we know" and "it is fixed in production" is often measured in months.

Standards and regulators have been explicit that this gap is the risk. They frame the requirement in slightly different ways, which matters when you decide how much of the work to automate.

What NIST SSDF RV.2 expects

NIST SP 800-218, the Secure Software Development Framework (SSDF) version 1.1, published in February 2022, has a practice called "Assess, Prioritize, and Remediate Vulnerabilities (RV.2)". Its stated purpose is to make sure vulnerabilities are remediated in line with risk, to shrink the window attackers have.

Two tasks sit under it:

• RV.2.1 asks you to analyse each vulnerability to gather enough information about risk to plan its remediation or another risk response. The notional examples include recording each vulnerability in issue tracking software and estimating exploitability and potential impact.
• RV.2.2 asks you to plan and implement risk responses. The examples include deciding whether to remediate or address the risk another way, applying a temporary mitigation when no permanent fix exists, and delivering remediations "via an automated and trusted delivery mechanism", with the note that one remediation can address several vulnerabilities.

Two points in that text matter for automation. First, the SSDF does not say "fix everything immediately". It says decide per vulnerability, based on risk, and record the decision. Second, it explicitly treats automated delivery of remediation as good practice, and it notes that a single change can close several issues. A fix pull request that bundles compatible upgrades for one repository fits that description well. A ticket that describes a problem does not deliver anything.

What NIST SP 800-40 Rev. 4 adds

NIST SP 800-40 Revision 4, "Guide to Enterprise Patch Management Planning: Preventive Maintenance for Technology", published in April 2022, frames patching as preventive maintenance. It lists four risk responses: accept, mitigate, transfer and avoid. It also states that installing a patch or upgrading to a version without the vulnerability are the only responses that remove the vulnerability without removing functionality.

The guide then describes a vulnerability management life cycle: know when a vulnerability affects your assets (down to packages and libraries), plan the response, then execute it in three parts: prepare (including validating and testing patches), implement, and verify that the fix took effect.

It is also blunt about why routine patching slips. Routine patching lacks urgency, so it is "often postponed and neglected", and each delay makes the next emergency patch harder because earlier patches must go in first. The guide asks organisations to define scenarios (routine patching, emergency patching, emergency mitigation, unpatchable assets) and maintenance plans for each.

That maps cleanly onto remediation settings. Routine dependency hygiene is the work most likely to rot in a backlog and the safest to automate with conservative rules. Emergency fixes for exploited vulnerabilities need speed, but also a human who knows the blast radius. Unpatchable assets need a different control entirely.

What PCI DSS 6.3.3 requires

PCI DSS v4.0.1 requirement 6.3.3 sets time frames for installing security patches and updates. According to the PCI Security Standards Council's own FAQ (article 1597), patches for critical vulnerabilities must be resolved within one month of release, and all other applicable patches installed within time frames the entity sets from its own risk assessment. Those time frames should follow the risk rankings assigned under requirement 6.3.1. The same FAQ separates "resolved" (the entity fixes the vulnerability) from "addressed" (the entity fixes it or mitigates it another way, such as a compensating control).

One month sounds generous until you count the steps: triage, fix, test, review, release and deploy. If the ticket waits a week for an owner and another for a sprint slot, half the window is gone before anyone touches a manifest.

What CISA BOD 22-01 shows about deadlines

For United States federal civilian agencies, CISA's Binding Operational Directive 22-01 (3 November 2021) requires remediation of vulnerabilities in the Known Exploited Vulnerabilities (KEV) catalog within the catalog's timelines: by default two weeks for CVEs assigned in 2021 or later, and six months for older CVEs. The directive applies to federal agencies, but many private teams now use KEV listing as their own "drop everything" trigger. Two weeks is a hard target for any process that depends on a human picking up a ticket.

What the EU Cyber Resilience Act changes

The EU Cyber Resilience Act (Regulation (EU) 2024/2847) requires manufacturers of products with digital elements to handle vulnerabilities across the product's life. According to the European Commission, the Act entered into force on 10 December 2024, reporting obligations apply from 11 September 2026, and the main obligations apply from 11 December 2027. Its vulnerability handling requirements sit in Annex I, Part II, and include remediating vulnerabilities without delay and providing security updates. If you sell software or connected products in the EU, "we had a ticket for it" will not be a satisfying answer to a market surveillance authority.

Secure by Design and OWASP put it in plain terms

CISA's Secure by Design guidance asks software makers to treat customer security as a core business requirement and says that "every technology provider must take ownership at the executive level". The OWASP Top 10 entry A06:2021, Vulnerable and Outdated Components, describes the same failure from the developer side: environments where patching is "a monthly or quarterly task" leave known flaws open for days or months without need. Its prevention advice is a patch management process that removes unused dependencies, keeps an inventory and applies updates in a risk based, timely way.

Why ticket queues miss these timelines

Put the standards side by side and a pattern appears. None of them asks for perfect security. All of them ask for a risk based decision, a timely fix, and evidence that the fix happened. Ticket queues struggle with all three:

1. The person who finds the issue is rarely the person who fixes it. A security engineer files the ticket; a developer on another team has to rebuild the context from the advisory.
2. The ticket describes the problem, not the change. Someone still has to work out the safe version, check transitive conflicts and update the lockfile.
3. Testing is the real cost. NIST SP 800-40 lists "acquiring, validating, and testing patches" as preparation. Most of a developer's time on a dependency fix goes there.
4. Volume hides priority. When every library with a CVE becomes a ticket, the exploitable ones sit beside the unreachable ones and get the same attention.
5. Evidence lives in many places. The decision is in the ticket, the change is in git, the test result is in CI and the deployment is somewhere else. An auditor asking "when was this fixed?" gets a scavenger hunt.

A fix pull request keeps the human decision but moves the human from writing the change to reviewing it, a much shorter job.

What a Griffin fix pull request contains

Safeguard's docs describe AI Remediate (the product name for the fix flow in ESSCM) as a five stage process. Griffin is the model that runs it.

1. Analysis. Griffin looks at the vulnerability and your codebase.
2. Solution generation. It works out the safest upgrade path to a fixed version.
3. Impact assessment. It checks for breaking changes and compatibility.
4. Pull request creation. It opens a pull request with all the changes.
5. Validation. Automated tests run to verify the fix.

The docs list what the generated pull request includes:

• a clear title with the CVE reference
• a detailed description of the vulnerability
• a summary of the changes made
• breaking change warnings, if any
• test results, if test integration is configured
• links to the relevant advisories

That list is the point of the feature. A reviewer opening the pull request sees why it exists, what changed, how risky the change is and whether tests passed, without opening the scanner or reading the advisory separately. The pull request becomes the record that NIST SP 800-40's "verify" step and an auditor's "show me" both need.

What Griffin can change

The AI Remediate docs group the changes into three kinds.

• Dependency upgrades. Upgrading vulnerable packages to fixed versions, handling transitive dependency conflicts, updating lock files, and keeping compatibility with existing code. This is the main use.
• Configuration fixes. For configuration based vulnerabilities: updating security headers, patching insecure defaults and applying recommended settings.
• Code modifications. "In some cases", in the docs' words: replacing deprecated function calls, updating API usage patterns and applying security patches to code.

Code changes are possible, not routine, and they are exactly the kind of change a person should review closely.

Supported ecosystems

The docs list full AI Remediate support for JavaScript (npm, yarn, pnpm), Python (pip, poetry, pipenv), Java (Maven, Gradle), Go (Go modules), Rust (Cargo), Ruby (Bundler), .NET (NuGet) and PHP (Composer). If your stack falls outside those package managers, plan on the manual route.

The remediation categories and what each one fixes

Safeguard's offering material describes Autonomous Remediation as covering eight categories, and the Gold block later in this post uses the same wording. The detailed category matrix in Safeguard's technical evaluation material lists nine rows, because CVE remediation (Vulnerabilities) appears as its own row next to the eight. The public AI Remediate docs page does not list categories at all. In practice, check the categories shown in your own tenant; the table below lists every row in the matrix.

Each category is set to Manual or Auto independently, and each has its own strategy.

A few notes on how to read this.

Vulnerabilities and Dependencies are the core. They are the categories the AI Remediate docs describe in detail, and the ones with the most field use. Vulnerabilities targets a specific CVE. Dependencies targets drift: libraries that are old or buried deep in the tree, which raise the cost of the next emergency patch. NIST SP 800-40's point about neglected routine patching making emergencies harder is exactly what the Dependencies category is for.

License is a policy decision, not a technical one. License compliance (GA) parses SPDX expressions and classifies licenses. The remediation options range from swapping a component for a permissively licensed equivalent to simply opening a tracked item for your legal team. If your counsel has not written down which licenses are acceptable for which products, start with the tracked item option. See the companion post on open source license obligations.

Attestation and Provenance raise supply chain evidence. Attestation and signing (GA) covers SLSA, Sigstore and in-toto. The SLSA v1.0 specification defines build levels from L1 (provenance exists) to L3 (hardened builds). The "move up one level" option is the sensible default: going from no provenance to L3 in one pull request usually means changing your build platform, which no bot should do alone. More on this in the post on attestation and provenance in Safeguard.

Security Posture, Findings and Compliance work on your controls. These connect to the Compliance and GRC suite (GA). Their options are about ordering: which gap to close first. "SLA driven" under Findings is the option that lines up with time bound requirements such as PCI DSS 6.3.3.

Code Quality has no Smart option in the matrix. Its three options are about technical debt, and the "add tests for under covered code" option is worth noting: better tests make every other category safer to automate.

Safest, Balanced, Aggressive and Smart: what they mean

For Vulnerabilities and Dependencies, Safeguard defines four strategies:

• Safest: backward compatible fixes only. It will not break existing functionality.
• Balanced: minor version updates and patches, with minimal breaking changes.
• Aggressive: all available fixes, including major version updates.
• Smart: the model picks per item, based on context, risk and impact.

These map closely onto Semantic Versioning, the convention most package ecosystems follow. Under SemVer 2.0.0, a MAJOR version signals incompatible API changes, a MINOR version adds backward compatible functionality, and a PATCH version is for backward compatible bug fixes. So in a well behaved ecosystem, Safest stays roughly within patch and compatible releases, Balanced adds minor releases, and Aggressive accepts majors.

The phrase "well behaved" is doing work there. Not every maintainer follows SemVer strictly, and a minor release can still break you. That is why the strategy is a starting rule, not a guarantee, and why breaking change detection and tests sit on top of it.

When to pick each strategy

A practical pattern: use Safest with Auto for Dependencies on most repositories, Balanced with Manual for Vulnerabilities so a person approves each CVE fix, and Aggressive only inside a planned upgrade sprint. Move a repository to a less conservative setting when its tests have earned it.

Why it ships switched off

Autonomous remediation ships off. Every category defaults to Manual, and nothing is applied until the master Autonomous Remediation toggle is enabled. Strategy selections you make are saved, but they are not applied until that toggle is on.

A careful team would choose this default on its own, for four reasons.

• Changes to your code need consent. A security tool that edits repositories on day one, before anyone has looked at its settings, would be a supply chain risk of its own.
• Your tests decide what is safe. Safeguard cannot know, before you tell it, whether a repository has tests worth trusting.
• Review capacity is finite. Turning everything on at once can produce more pull requests than your reviewers can read. NIST SP 800-40's advice to plan maintenance by scenario applies to automation too.
• Different categories carry different risk. A patch bump and a license swap are not the same kind of change. Per category control lets you go fast where the risk is low.

The flip side: if you evaluate Safeguard and never turn the toggle on, the platform will find and rank issues but will not open fix pull requests on its own, so it will feel like the scan and alert tools it is meant to replace. Plan a deliberate rollout instead.

Step by step: turning on autonomous remediation

The steps below follow the flows in Safeguard's AI Remediate docs. Where the docs name a screen, the step names it. Where they do not, the step describes the outcome rather than inventing a path.

Before you start

1. Connect the repositories you want fixed. Fix pull requests need a source control integration (GitHub, GitLab, Bitbucket or Azure DevOps cards under Integrations, Source Control) so Safeguard can open branches and pull requests.
2. Make sure CI runs on pull requests. Safeguard's CI templates scan pushes to main and pull requests into it, so every fix pull request is scanned and gated like any other change.
3. Check your tests run in CI. Validation is only as good as the suite it runs.

Step 1: Review the AI Remediate settings

The docs list these settings under Settings, AI Remediate:

For a first rollout, turn Require Approval and Test Integration on, keep changes flagged Major or Critical out of automatic pull requests, and use a branch name your branch protection rules recognise.

Step 2: Turn on the master toggle

Enable the master Autonomous Remediation toggle in your tenant settings. On its own this does not apply anything new: every category is still Manual. It means saved strategies can now take effect for categories you move to Auto.

Step 3: Set one category to Auto

Pick one category and one strategy. Dependencies with Safest is the usual first choice, because it targets routine upgrades that NIST SP 800-40 says are most often neglected, and because backward compatible fixes are least likely to break anything. Leave every other category on Manual. Watch the pull requests it opens for a week or two: how many, how often tests pass, how long reviews take.

Step 4: Run a single fix by hand

For a specific vulnerability, use the single fix flow from the docs:

1. Navigate to the vulnerability.
2. Click AI Remediate.
3. Review the proposed changes.
4. Click Create Pull Request.

Use this for an urgent CVE, ideally one ranked high by reachability analysis (GA). Read the pull request description, the breaking change warning and the test result. This is the fastest way for reviewers to learn what Griffin's pull requests look like.

Step 5: Run a bulk fix

When you are comfortable with single fixes, use bulk remediation:

1. Select the vulnerabilities to fix.
2. Click AI Remediate Selected.
3. Griffin batches compatible fixes.
4. Review all changes.
5. Create pull requests, one per repository.

One pull request per repository keeps review manageable: a team reviews its own repository's changes in one place instead of a stream of single bumps. It also matches the SSDF note that one remediation can address several vulnerabilities.

Step 6: Try a page level plan

From the Vulnerabilities page, the docs describe a page level option: click the AI Remediate button at the top, Griffin analyses all fixable vulnerabilities, you review the remediation plan and then approve and create the pull requests. This is useful for a backlog clean up, but the plan can be large. Review it with the owning teams rather than approving it alone.

Step 7: Widen gradually

Add categories one at a time. A reasonable order is Dependencies, then Vulnerabilities on Manual with Balanced, then Attestation and Provenance with their recommended options, then License once legal has written its rules. Track fix success rate, as the docs recommend, and move repositories to less conservative strategies only when the numbers support it.

How breaking change detection works, and what it does not do

Griffin rates each proposed change on a four level scale, according to the docs:

• Safe: no breaking changes expected.
• Minor: minor API changes, low risk.
• Major: significant changes, review recommended.
• Critical: high risk of breaking, manual review required.

The rating feeds the Breaking Change Policy setting and appears as a warning in the pull request. It is useful for routing: Safe changes can flow with light review, Major and Critical ones go to someone who knows the service.

What it does not do is prove your application still works. A version can be labelled Safe and still break you through behaviour the maintainer did not consider an API change: a default timeout, a stricter parser, a dropped platform. That is why the docs list validation through your own automated tests as a separate stage, and why their best practice advice is plain: enable tests, start with safe fixes, review major changes, do not auto merge breaking changes, and monitor the success rate.

What still needs you:

• Test coverage. If the code path that uses the library has no tests, a green build means little.
• Integration and contract tests. A library upgrade that changes a wire format can pass unit tests and break a consumer.
• Performance. Most suites do not catch a slower serializer.
• Runtime configuration. A fix that changes defaults may need a configuration change in your deployment, outside the repository.
• Release and deploy. Merging a pull request is not the same as running the fix in production. NIST SP 800-40's "verify" step means confirming the fix took effect where it matters.

How policies and gates interact with fix pull requests

Policies, gates and guardrails (GA) are how Safeguard enforces rules across the organisation. The docs separate them clearly: policies evaluate your SBOMs and generate findings; gates are checkpoints that enforce policies, block deployments when policies fail, integrate with CI and require approval for exceptions.

Each policy has one Action that decides what a failure does to the gate:

A gate's outcome follows from its policies in a fixed order: if any Block policy failed, the gate fails; an Error is never counted as a pass; and a gate that has never been evaluated shows Not evaluated, never Passed. (Per the docs, policy outcomes are turned on per workspace; if you do not see an Outcome column, ask your Safeguard contact.)

This matters for remediation in three ways.

Fix pull requests are gated like any other change. The CI templates scan pull requests into main, so a fix branch gets scanned. With a step like this in your pipeline:

safeguard ci scan --wait --fail-on-gate <gate>

the job waits for the scan and for the gate's policies to be evaluated on the new data. It exits 0 when the gate is Passed or Warning, and non-zero when the gate is Failed, Error or Not evaluated, printing the Block policies that failed. If an upgrade pulls in a new dependency with a license your policy blocks, or a version with a different vulnerability, the fix pull request fails the same gate a human change would.

Gates define "fixed". A policy such as "no critical CVEs" or "require SLSA Level 2 attestations" (both appear among the docs' examples) turns the remediation goal into a check. When the fix pull request makes the gate pass, the evidence of remediation is the gate's outcome history, not a closed ticket.

Exceptions stay human. When a fix is not possible yet, the docs describe an exception workflow: request an exception, select the policy and finding, give a business justification, set an expiry date and submit for approval. The approval and the audit trail are recorded. This is the SSDF RV.2.2 "risk acceptance" path and the PCI "addressed" path, made explicit.

For more on writing policies in plain English and linking them to release gates, see plain English security policies to release gates.

Preview a fix first with the CLI

Not every team wants the platform opening pull requests while they are still evaluating. The Safeguard CLI (GA) lets a developer work on a fix locally first.

The CLI usage docs list the fix command and tell you to check its flags in your build:

# Update vulnerable dependencies
safeguard fix --help

The docs also note that if the page and --help ever disagree, --help is right. In current builds, safeguard fix --help lists a --dry-run flag that previews changes without applying them, along with flags to point at a manifest, set a minimum severity, restrict to patch upgrades, and create a pull request (optionally as a draft). A preview against a single manifest looks like this:

safeguard fix --manifest package.json --dry-run

Read the proposed upgrades, then rerun without the preview flag when you are happy, or go straight to a draft pull request. Always confirm the exact flags with --help on your installed version. Two companion posts cover this in more depth: preview dependency fixes with the CLI dry run and dry run and create a pull request from a pipeline.

There is also a conversational route. Run safeguard with no arguments to open the interactive terminal, sign in with /login, and ask in plain language, for example "fix the lodash CVE in this repo". The interactive terminal docs say your code stays on the machine and only SBOMs and findings are uploaded. The assistant asks before it runs commands, so you see each step. In CI, safeguard exec runs one agent turn non-interactively and defaults to a strict permission mode where anything not pre-approved is denied.

The preview route suits owners who want to see Griffin's choices before allowing automation, monorepos fixed one package at a time, and pipelines that should propose but not apply.

Where reachability fits

A fix programme needs an order. Reachability analysis and prioritisation (GA) supplies it. Safeguard's docs describe four signals: reachability (static, dynamic and configuration), exploitability through EPSS and KEV, runtime context such as environment and exposure, and business context you declare through policy. FIRST describes EPSS as a daily probability that a CVE will be exploited in the next 30 days; KEV, as above, lists vulnerabilities known to be exploited.

Safeguard's docs say reachability filtering typically removes 60 to 80% of findings from the urgent queue. Treat that as Safeguard's stated figure, not a promise for your codebase. The docs also mark language support: static reachability is GA for JVM languages, Python, JavaScript and TypeScript, Go, Rust, C and C++, and C#, while Ruby and PHP static analysis and Swift and Objective-C are marked Preview.

For remediation, the practical effect is simple. When you run a bulk fix, start with the reachable, exploited findings in production services. The first pull requests your reviewers see should be the ones that close real exposure. The companion post on prioritising with reachability, EPSS and KEV goes deeper.

What Safeguard does not do

Honest limits matter more for a feature that changes code than for one that only reports. Plan around these.

1. It does not run until you turn it on. Autonomous remediation ships off, every category on Manual. If nobody enables the master toggle and sets a category to Auto, no automatic fix pull requests are opened. That is deliberate, and it is your team's job to own the rollout.
2. It cannot upgrade to a version that does not exist. A fix pull request needs a fixed version upstream or a hardened Gold build. When neither exists, the options are mitigation, an exception, or a custom Gold request through fork and patch, which is early access and covers specific packages only.
3. It does not decide that a fix is safe for your business. Breaking change detection labels risk and tests run where you configure them, but your test suite and your reviewers decide. Safeguard does not know your uncovered code paths, your downstream consumers or your performance budget.
4. It does not fix what you do not build. Vendor appliances, hosted services and operating system packages on hosts you do not build are outside its reach. The fix for those comes from the vendor or distribution, through your normal patch management.
5. Smart is not hands off. Smart strategy decisions still need review, especially when the model picks a major upgrade or a code change. Read its reasoning in the pull request.
6. It does not deploy. Merging a fix pull request is not the same as running the fix in production. Release, deployment and verification stay in your pipeline.
7. It does not cover every package manager. The docs list full support for npm, yarn, pnpm, pip, poetry, pipenv, Maven, Gradle, Go modules, Cargo, Bundler, NuGet and Composer. Other ecosystems need manual fixes.
8. It does not replace your compliance process. Categories such as Compliance and Security Posture order and propose work, but control owners, policies and auditors remain yours. Safeguard records the evidence; it does not certify you.

Common mistakes

Turning everything on at once. Every category opening pull requests on day one will swamp reviewers, and they will start rubber stamping or ignoring them. Start with one category on one strategy.

Choosing Aggressive to "clear the backlog". Major upgrades across dozens of repositories in one bulk run is a migration project, not a fix. Use Aggressive inside a planned window with owners present.

Auto merging on a green build in repositories with thin tests. A passing build only proves the tests that exist passed. The docs say not to auto merge breaking changes; extend that caution to any repository where you do not trust coverage.

Forgetting to gate fix branches. If your CI only scans main, a fix pull request that introduces a newly vulnerable transitive dependency will not be caught until after merge. Make sure pull requests run safeguard ci scan with the gate.

Ignoring findings that Safest cannot close. Safest will not cross into an incompatible version, so some CVEs remain open under it. Review those on a regular cadence, decide on Balanced or Aggressive for them case by case, or file an exception with an expiry date.

Treating a merged pull request as "remediated". For PCI DSS 6.3.3 or a KEV deadline, the relevant date is when the fix is running, not when the code merged. Track deployment too.

Skipping the legal conversation for License. Swapping a component to an MIT or Apache-2.0 equivalent changes your product. Agree the rules with counsel before you move that category off Manual.

FAQ

Is Safeguard autonomous remediation on by default?

No. It ships switched off. Every category defaults to Manual, and saved strategies are not applied until the master Autonomous Remediation toggle is enabled. You can still run single and bulk fixes by hand from a vulnerability or the Vulnerabilities page.

What does a Safeguard fix pull request include?

According to the docs: a title with the CVE reference, a description of the vulnerability, a summary of the changes, breaking change warnings if any, test results if test integration is configured, and links to the relevant advisories.

How many remediation categories does Safeguard have?

Safeguard describes remediation as eight categories: Dependencies, License, Security Posture, Findings, Attestation, Provenance, Compliance and Code Quality. Its detailed matrix also lists Vulnerabilities (CVE remediation) as its own row, so some views show nine. Each is set to Manual or Auto independently.

What is the difference between the Safest and Balanced strategies?

Safest applies backward compatible fixes only, so it should not break existing functionality. Balanced also takes minor version updates and patches, accepting minimal breaking changes. Balanced closes more vulnerabilities; Safest is lower risk.

When should I use the Smart strategy?

When your tests are good and you want the model to choose per item based on context, risk and impact. Smart decisions still need review, particularly major upgrades.

Does Safeguard auto merge fix pull requests?

The docs describe settings for auto creating pull requests for safe fixes and for requiring approval, and they advise against auto merging breaking changes. Whether a pull request merges is governed by your settings, your branch protection and your reviewers.

Can I fix vulnerabilities across many repositories at once?

Yes. Bulk AI Remediate lets you select vulnerabilities, batches compatible fixes and creates one pull request per repository.

How do I preview a fix without changing my code?

Use the Safeguard CLI. Run safeguard fix --help to see the flags in your build; current builds list a --dry-run flag that previews changes without applying them, for example against a single manifest.

Will a fix pull request pass my security gates?

It is evaluated like any other change. If your CI runs safeguard ci scan --wait --fail-on-gate on pull requests, a fix that introduces a blocked license or another vulnerability fails the gate.

What happens when there is no fixed version?

Autonomous remediation needs a fixed version or a Gold build. Without one, use a mitigation or a time bound exception, or request a custom Gold build; fork and patch is early access.

The rest of this post shows the wider remediation path, including what to do when no upstream fix exists. If you want to try the flow yourself, download Safeguard at https://safeguard.sh/download and read the setup guides at https://docs.safeguard.sh/docs .

Autonomous remediation is one of three ways Safeguard closes the gap between a published fix and your production builds. The section below, shared across our posts, explains how it works alongside Gold Open Source and Gold Registry when upstream is slow or silent.

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. After installing, running safeguard opens the interactive terminal, and the user asks it to "fix the lodash CVE in this repo". It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, prints a summary and pushes nothing. It ends with /permissions, /model and /scan .. That is the same analyse, change, test and review loop a fix pull request follows, run locally where you approve every step.

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

The second demo is a real Android session with the Safeguard mobile app (early access, beta). The user sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. For remediation, this is the human approval step in your pocket: a fix can wait for your yes instead of waiting for you to get back to a laptop.

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

For more background, see how Safeguard auto fix works, Griffin AI and autonomous remediation and why your scanner files tickets and Safeguard files pull requests.

Quick check

Sources

• NIST SP 800-218, Secure Software Development Framework (SSDF) Version 1.1 (PDF)
• NIST CSRC: SP 800-218 publication page
• NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning (PDF)
• NIST CSRC: SP 800-40 Rev. 4 publication page
• PCI Security Standards Council FAQ 1597: vulnerability management time frames
• CISA BOD 22-01: Reducing the Significant Risk of Known Exploited Vulnerabilities
• CISA Secure by Design
• European Commission: Cyber Resilience Act
• FIRST: Exploit Prediction Scoring System (EPSS)
• OWASP Top 10 2021, A06 Vulnerable and Outdated Components
• Semantic Versioning 2.0.0
• SLSA v1.0: Security levels
• Safeguard docs: AI Remediate
• Safeguard docs: Griffin AI
• Safeguard docs: Policies and Gates
• Safeguard docs: Policy outcomes and actions
• Safeguard docs: CLI usage
• Safeguard docs: Interactive terminal
• Safeguard docs: CI/CD Integration
• Safeguard docs: Vulnerability Prioritization (Reachability Analysis)
• Safeguard platform overview
• Gold Open Source

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