Automated vulnerability fixes are off by default because a fix changes your code, and only your team knows how much test coverage, release process, and risk appetite stand behind that code. Starting in Manual lets you see proposed fixes, build trust, and then choose where automation is safe.
TL;DR: A tool that edits your software without being asked has taken a decision that belongs to you. Safeguard ships Autonomous Remediation switched off, with every category set to Manual. You turn it on, one category at a time, when your team is ready.
Definition: Autonomous remediation means a system that prepares fixes for security problems on its own, usually as pull requests, without a person asking for each one. Manual means a person decides.
What does "off by default" actually mean here?
In Safeguard, Autonomous Remediation has a master switch and a set of categories. The categories cover areas such as dependencies, licenses, security posture, findings, attestation, provenance, compliance, and code quality. Each category can be set to Manual or Auto, and each one has its own strategy, which is a rule for how bold the fixes should be.
Out of the box, the master switch is off and every category is on Manual. The product also tells you plainly that strategy choices are saved but not applied. In other words, you can look around, pick settings, and nothing will change in your code until you turn the master switch on.
That wording matters. It means that a new account cannot wake up to a surprise pull request. It also means a careful team can prepare its choices ahead of time and flip the switch on a day when someone is watching.
Why would a security product slow itself down on purpose?
It can sound odd. A security tool exists to reduce risk, so why hold back its most helpful feature?
There are four good reasons.
1. Fixes change behavior. Even a small update can alter how software acts. The rules of semantic versioning say that a patch number should go up only for backward compatible bug fixes, but those rules are a promise made by a library's maintainers, not a guarantee. Mistakes happen, and some changes that are meant to be safe still affect a particular app.
2. Your tests are your own. A fix is only as safe as the checks that run on it. One team might have thousands of automated tests. Another might have a few. The tool cannot know which team it is serving until someone tells it.
3. Release habits differ. Some teams ship ten times a day and can undo a change in a minute. Others ship quarterly and need a long approval chain. A default that suits one will hurt the other.
4. Trust is earned in steps. People accept new automation when they have watched it work. A default of Manual lets a team watch first and decide second.
Think of a learner's permit for driving. The point is not that the learner is bad. The point is that a supervised start is how skill and trust get built.
What could go wrong if fixes were on by default?
Here are the problems that a default of Auto could cause, and how Manual prevents each one.
| Risk | What it looks like | How Manual helps |
|---|---|---|
| Surprise changes | Pull requests appear in repositories that nobody expected | No pull requests until the team opts in |
| Weak tests | A fix merges and breaks a feature the tests never covered | The team can check test strength first |
| Noisy queues | Dozens of pull requests land in one week | The team picks the pace and the scope |
| Ownership gaps | A fix touches code that no one feels responsible for | The team can assign owners before turning it on |
| Policy mismatch | A fix uses a version your policy forbids | The team can set policies and gates first |
None of these risks is a reason to avoid automation forever. They are reasons to switch it on deliberately.
How do teams move from Manual to Auto?
Teams usually follow the same pattern, from low risk to higher risk:
- Leave everything on Manual and read what the tool would suggest.
- Check that branch protection, required reviews, and automatic tests are in place on the repositories you care about.
- Choose the most cautious strategy. For vulnerability and dependency fixes, Safeguard's Safest strategy applies backward compatible fixes that should not break existing functionality.
- Turn on the master switch and set a single category to Auto for a small group of repositories.
- Review every pull request by hand for a few weeks.
- Widen the scope only if the results are good.
For a longer walkthrough of this path, see how to turn on automated fix pull requests safely.
Notice that Auto does not mean "no humans." Even in Auto, the fix arrives as a pull request. Your review rules still apply. GitHub documents that administrators can require approving reviews and passing status checks before a merge into a protected branch, and those rules treat a tool-made pull request the same as a human-made one. Read more in how to configure GitHub branch protection rules.
What does a worked example look like?
This example uses invented numbers to show the thinking. It does not describe a real company.
Worked example (invented numbers): A team owns 12 repositories. They score each one on two simple questions: do automatic tests cover the main features, and can a bad release be undone within an hour?
| Group | Repositories | Test coverage | Undo in under an hour? | Decision |
|---|---|---|---|---|
| A | 4 | Strong | Yes | Pilot first |
| B | 5 | Medium | Yes | Wait for week 4 |
| C | 3 | Weak | No | Stay on Manual |
The team turns the master switch on, sets the dependencies category to Auto with the Safest strategy, and limits the first run to the four group A repositories. They review every pull request by hand for four weeks. In this invented story, the group A repositories produce 18 pull requests, 16 merge without trouble, and 2 are closed because they touched code a reviewer wanted to check more carefully. The team decides that is acceptable and moves group B in.
Group C stays on Manual until the team writes more tests. That is a good outcome, not a failure. The default gave them room to make that choice.
Does a default of Manual make Safeguard less useful?
No, and the reason is simple. The value of a fix pull request is that the hard thinking is done for you: which version to use, which files to edit, and what the change might affect. In Manual, you still get that value. A person chooses when to act on it. Safeguard also reports on reachability, which shows whether your code actually reaches the flawed part of a library. That helps a reviewer decide which fixes to approve first.
The default is also honest about what Auto is. It is a power tool. You can pick it up whenever you like, but it should not start itself.
How does Safeguard help you decide?
Safeguard offers autonomous remediation with fix pull requests as a generally available capability. It is off by default, every category is Manual, and you control the switch. It works alongside policies, gates, and guardrails, which let your team set rules for what can and cannot ship. It also provides SBOM and dependency scanning so you can see what you have before changing anything. An SBOM, or software bill of materials, is a list of every part inside your software.
If you want to see your own exposure first, run the free scan at gold.safeguard.sh/scan. It needs no change to your code. For the settings behind each category, see autonomous remediation across the eight categories and the autonomous remediation FAQ.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how each strategy describes the size of change it is willing to make, and notice that choosing a strategy is separate from switching automation on.
Quick check
Are fix pull requests really off when I first sign up?
Yes. Autonomous Remediation ships switched off and every category is set to Manual. Strategy choices you make are saved, but nothing is applied until you turn the master switch on.
If I turn it on, will code change without anyone seeing it?
No. Fixes arrive as pull requests, so your review rules, required checks, and code owners still apply. You decide what merges.
Can I turn on only some categories?
Yes. Each category has its own Manual or Auto setting, so you can start with one and leave the rest alone.
Does Manual mean I lose the benefit of fix suggestions?
No. You still get the analysis. The difference is that a person decides when to act on it instead of the tool acting on its own.
Sources
- Semantic Versioning 2.0.0, on what patch, minor, and major numbers are meant to signal.
- About protected branches, GitHub Docs, on required reviews and status checks.
Last reviewed: 19 October 2026.
