Switch to Auto first the categories where fixes are small, easy to check, and easy to undo, such as dependency updates with a cautious strategy. Leave categories that need judgment, such as license choices or large refactors, on Manual until your team trusts the process.
TL;DR: Score each category on size of change, ease of review, and ease of undo. Start with the highest scoring one, run it for several weeks, and move on only when the results are good. In Safeguard, every category begins on Manual.
Definition: A remediation category is a type of problem an automated tool can fix, such as a vulnerable dependency or a missing security control. Each category can be set to Manual, where a person decides, or Auto, where the tool prepares fixes by itself.
What categories can be set to Manual or Auto?
Safeguard's Autonomous Remediation has separate Manual or Auto settings for each category. They cover dependencies, licenses, security posture, findings, attestation, provenance, compliance, and code quality, along with a strategy for vulnerability fixes. Each category has its own strategies, which tell the tool how to approach that kind of problem.
The product ships with the master switch off and every category on Manual. Strategy choices are saved but not applied until the master switch is turned on. That gives you a clean start: you pick, you test, you widen.
Here is what each category is about, in plain words.
| Category | What it tries to fix | Example strategy options |
|---|---|---|
| Dependencies | Outdated or deeply nested dependencies | Safest, Balanced, Aggressive, Smart |
| License | Risky or unknown component licenses | Swap to an MIT or Apache 2.0 equivalent, drop the component, open a tracked item for legal sign off, Smart |
| Security posture | Gaps in security controls | Highest risk gaps first, every missing control, low effort and high impact first, Smart |
| Findings | Open security and compliance findings | Most severe first, low effort first, nearest to deadline first, Smart |
| Attestation | Coverage of build attestations and SLSA levels | Move up one level, aim for the highest, Smart |
| Provenance | Commit signing and build provenance | Signed commits in CI, build provenance for artifacts, both, Smart |
| Compliance | Gaps against compliance frameworks | Highest risk frameworks first, every failing requirement, Smart |
| Code quality | Technical debt and code smells | Blocker and critical issues first, refactor to pay down debt, add tests for under covered code |
A few terms need a word. Provenance is a record of where a piece of software came from and how it was built. Attestation is a signed statement about how software was made. SLSA is a set of levels that describe how well a build process is protected. If these are new to you, you do not need to turn them on first.
How do you decide the order?
Use three questions and give each category a score from 1 (hard) to 3 (easy).
- How small is a typical fix? A one line version change scores 3. A change across many files scores 1.
- How easy is it to review? If a reviewer can judge it in minutes with the tests as backup, score 3. If it needs legal, audit, or architecture judgment, score 1.
- How easy is it to undo? If a revert fully restores the old state, score 3. If the change affects the outside world, such as a signed record or a legal decision, score 1.
Add the three numbers. Higher is a better first candidate. This is a thinking tool, not a law, so adjust it for your situation.
What does a worked example look like?
This example uses invented scores to show the method. Your own scores will differ.
Worked example (invented numbers): A small team scores five categories.
| Category | Size of fix | Ease of review | Ease of undo | Total | Decision |
|---|---|---|---|---|---|
| Dependencies with Safest strategy | 3 | 3 | 3 | 9 | Auto first |
| Provenance (signed commits in CI) | 2 | 2 | 2 | 6 | Auto second, after week 4 |
| Findings (most severe first) | 2 | 2 | 2 | 6 | Auto second |
| License | 2 | 1 | 2 | 5 | Keep on Manual |
| Code quality (refactor) | 1 | 1 | 2 | 4 | Keep on Manual |
The team starts with dependencies on Safest. After four clean weeks, they review the results and switch provenance to Auto in a pilot repository. License stays on Manual because a person in legal needs to approve any swap. Code quality refactors stay on Manual because a change across many files needs a developer's eye.
Notice that "Manual" is not a failure. It is the right answer for work where a person's judgment is the whole point.
Why do dependency fixes usually go first?
Three reasons. Fixes are usually small. Reviewers can read the version change and the test results quickly. And a revert cleanly restores the old state. Semantic versioning also helps: its official text says the patch number must go up when only backward compatible bug fixes are introduced, so patch updates are a natural fit for a cautious first run.
Strategy matters as much as category. Safeguard describes Safest as applying backward compatible fixes that should not break existing functionality, Balanced as minor updates and patches with minimal breaking changes, Aggressive as all available fixes including major versions, and Smart as letting an AI model choose per item. For a deeper look, see what do Safest, Balanced, Aggressive and Smart fix strategies mean.
Why keep license and code quality on Manual longer?
A license fix can involve a legal decision. Swapping a component might change obligations that your lawyers care about. Safeguard's license strategies even include opening a tracked item for legal sign off, which shows that a person is expected in the loop. This post is not legal advice, so ask your own counsel how to handle license questions.
Code quality fixes can involve refactoring, which means restructuring code without changing what it does. Large refactors touch many files and depend on test strength. They are valuable, but they need a reviewer who understands the code.
When should you move the next category?
Use a simple gate. Move on when all four are true:
- At least four weeks of results on the current category.
- No merged fix caused a customer facing problem, or any that did was understood and addressed.
- Reviewers are still reading the pull requests, not rubber stamping them.
- The team has agreed on a stop rule for the next category.
If any answer is no, stay where you are. For the rollout steps in detail, read how to turn on automated fix pull requests safely. For a view of all the categories together, see autonomous remediation across the eight categories.
How does Safeguard support this?
Safeguard provides autonomous remediation with fix pull requests as a generally available capability, with a separate Manual or Auto setting for each category. It is off by default, and every category is on Manual. Compliance and evidence automation, policies, gates, and guardrails, and SBOM and dependency scanning are also available, and they help you see which categories matter most for your own project.
To see which of your dependencies have fixes available, run the free scan at gold.safeguard.sh/scan. Use that list to decide whether dependencies really is the right first category for you.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings are grouped and prioritized, then ask which kind of finding you would trust a tool to fix on its own.
Quick check
Do I have to turn on every category?
No. Each category has its own Manual or Auto setting. You can run some on Auto and keep others on Manual for as long as you like.
Is Manual a worse setting than Auto?
No. Manual means a person decides. For work that needs judgment, such as license choices, Manual is often the right long term setting.
Which category do most teams start with?
Dependencies, usually with the Safest strategy, because the fixes are small, easy to review, and easy to undo. Choose what fits your own project and test strength.
What happens if I save strategy choices but leave the master switch off?
Nothing is applied. Safeguard saves the choices, and they take effect only after you turn Autonomous Remediation on.
Sources
- Semantic Versioning 2.0.0, on what patch, minor, and major numbers signal.
Last reviewed: 19 October 2026.
