A fix strategy is a rule for how bold an automated fix may be. Safest applies backward compatible fixes only. Balanced allows minor updates and patches. Aggressive allows every available fix, including major version jumps. Smart lets an AI model choose for each item based on context, risk, and impact.
TL;DR: Bigger version jumps fix more but break more. Start with Safest, move to Balanced when your tests are strong, use Aggressive for planned upgrade work, and treat Smart as a choice that still needs review.
Definition: A fix strategy is a setting that tells an automated remediation tool how large a change it is allowed to propose when it repairs a vulnerable dependency.
Why does a tool need a strategy at all?
Imagine your software uses a library called pretty-dates at version 2.4.1, and a flaw is found. The maintainers fix it in version 2.4.2. They also have a newer version 2.6.0 with new features, and a brand new version 3.0.0 that changes how the library works.
Which one should the fix use? There is no single right answer. The smallest jump is the safest for your code but may not exist if the flaw is only repaired in a newer line. The largest jump gets you the most up to date library but may force you to rewrite parts of your app.
A strategy lets you tell the tool how to make that trade. It turns a risky judgment call into a setting you can read, discuss, and change.
How do version numbers connect to strategies?
Most libraries use semantic versioning, a naming habit with three numbers in the form major, minor, patch. The official text says the patch number must go up when only backward compatible bug fixes are introduced. The minor number must go up when new backward compatible functionality is introduced or something is marked as deprecated. The major number goes up when incompatible changes are made to the public interface.
Here is the idea in plain terms:
2.4.1 -> 2.4.2 patch: bug fix, should not break you
2.4.1 -> 2.5.0 minor: new features, should still work with your code
2.4.1 -> 3.0.0 major: may break things, expect work
The key word is "should." Semantic versioning is a promise from the maintainers. It helps you predict risk, but it cannot prove that a given update is harmless for your particular code. Some maintainers do not follow the rules closely, and a fix for one flaw can still change behavior that your app relied on. For more background, see what is semantic versioning.
What does each strategy do?
Safeguard describes the four strategies for vulnerability and dependency fixes like this.
| Strategy | What it will apply | Typical size of change | Good fit |
|---|---|---|---|
| Safest | Backward compatible fixes that should not break existing functionality | Patch steps | First rollout, weak tests, critical systems |
| Balanced | Minor version updates and patches with minimal breaking changes | Patch and minor steps | Teams with solid tests who want to stay current |
| Aggressive | All available fixes, including major version updates | Any step, including major | Planned upgrade projects with time to test |
| Smart | The AI picks a fix for each item based on context, risk, and impact | Varies per item | Teams that want a recommendation and will review it |
Other categories, such as license, security posture, and findings, have their own strategy options. For example, a license strategy might swap a risky license for an equivalent one, drop the component, or open a tracked item for legal review. This post focuses on the vulnerability and dependency strategies because they are the most common starting point. For the full list of categories, see autonomous remediation across the eight categories.
How do you pick the right one?
Ask four questions.
- How strong are your tests? If a failing test is how you would find out about a break, weak tests mean you should stay with Safest.
- How hard is it to undo a release? If you can roll back in minutes, you can afford to try Balanced sooner.
- How serious is the flaw? A severe flaw that is being actively attacked may justify a bigger jump with extra review. A low risk flaw can wait for a planned upgrade.
- Does your code reach the flawed part? Reachability analysis checks whether your code actually calls the risky function. If it does not, there is less pressure to rush a major upgrade.
A simple rule of thumb: begin with Safest, move to Balanced after a few clean weeks, and use Aggressive only for work you have scheduled and staffed.
What does a worked example look like?
This example uses invented names and invented numbers. It is only meant to show the reasoning.
Worked example (invented numbers): A team has a flaw in pretty-dates 2.4.1. The available versions are 2.4.2, 2.5.0, and 3.0.0. The flaw is fixed in 2.4.2 and in everything after it. The team owns three apps.
| App | Test strength | Strategy chosen | Version the fix proposes | Why |
|---|---|---|---|---|
| Billing | Strong | Safest | 2.4.2 | Critical system, smallest change wins |
| Website | Medium | Balanced | 2.5.0 | The team wants to stay close to current |
| Internal tool | Weak | Safest | 2.4.2 | Weak tests mean small steps |
Under Safest, all three apps would get 2.4.2. Under Balanced, the website gets 2.5.0 because minor updates are allowed. Nobody gets 3.0.0 because that would need Aggressive, and in this invented story the team has no time scheduled for a major upgrade.
Now suppose a different flaw is found, and this time the maintainers only repaired it in the 3.x line. Safest and Balanced cannot reach 3.0.0, so no fix pull request appears for that item. That is not a failure of the tool. It is a signal that the team needs a planned upgrade or a workaround. Aggressive could propose the major jump, and a person would then review it with care. The related post breaking change aware remediation goes further into how major jumps are handled.
What about Smart?
Smart lets an AI model choose a fix for each item, based on context, risk, and impact. That can be useful when your estate is large and different items call for different choices. One might get a patch, another a minor update, and a third a flag for human attention.
Two cautions apply. First, a smart choice is still a proposal. Review it the way you would review any other fix pull request. Second, if you need predictable behavior for audit or change control reasons, a fixed strategy such as Safest is easier to explain. Pick the one your team can describe in one sentence.
Are strategies the same as turning automation on?
No, and this surprises people. In Safeguard, Autonomous Remediation ships off, and every category is set to Manual. Strategy selections are saved but are not applied until the master switch is turned on. You can think of the strategy as how bold, and the master switch plus Manual or Auto as whether. For the reasoning behind that default, read why are automated vulnerability fixes off by default.
How does Safeguard use these strategies?
Safeguard offers autonomous remediation with fix pull requests as a generally available capability. You choose Manual or Auto for each category and pick a strategy for it. It is off by default, and fixes arrive as pull requests that your review rules apply to.
Safeguard also includes reachability analysis, which helps you see which flaws your code actually reaches, along with policies, gates, and guardrails for setting rules on what can ship. The Safeguard CLI can also write code, in addition to scanning.
To see how many of your dependencies have available fixes, try the free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen. Switch between strategies and watch how the size of the proposed change grows from Safest to Aggressive.
Quick check
Which strategy should I start with?
Start with Safest. It applies backward compatible fixes that should not break existing functionality. Move up only after a few weeks of clean results and with strong tests.
Does Aggressive mean it merges major upgrades on its own?
No. Aggressive allows all available fixes, including major versions, but a fix still arrives as a pull request for review. A major jump deserves a careful look.
Why did no fix appear for one of my findings?
The repair may exist only in a newer major version that your strategy does not allow, or no fixed version may exist yet. Check the finding, then plan an upgrade or a workaround.
Is a patch update always safe?
No. Semantic versioning says a patch should contain only backward compatible bug fixes, but that is a promise by the maintainers. Your tests are the real check.
Sources
- Semantic Versioning 2.0.0, on the meaning of major, minor, and patch numbers.
Last reviewed: 19 October 2026.
