Auto-fixing a vulnerability means the platform generates the actual change that resolves it — a dependency upgrade, a code patch, or a rebuilt container image — rather than handing you a finding to fix yourself. Safeguard's Auto Fix works in two directions: "Fix Left" remediates vulnerabilities in your source code before they ship, and "Fix Right" replaces vulnerable container images with patched, zero-CVE alternatives at deploy time. Griffin AI authors these fixes as pull requests, runs your CI to prove they are safe, and can auto-merge on an opt-in basis. Here is how it works in practice.
Frequently Asked Questions
What does "auto-fix" actually produce? It produces a mergeable change, not just an alert. For source code, that is a pull request containing the dependency upgrade or code patch that resolves the CVE. For containers, it is a rebuilt image on a patched base. In both cases the change is validated against your tests before it is proposed for merge, so what you review is a candidate fix with evidence attached, not a suggestion.
What is the difference between "Fix Left" and "Fix Right"? Fix Left addresses vulnerabilities in source code during development — bumping a vulnerable library, patching a risky pattern, and opening the PR so the fix lands before release. Fix Right addresses what is already running: it swaps vulnerable container images for hardened, zero-CVE equivalents drawn from a catalog of 500K+ pre-scanned images. Together they cover the vulnerability before and after it reaches production.
Can auto-fix handle transitive dependencies, not just the ones I imported? Yes, and this is where most of the real exposure lives. Griffin performs deep transitive dependency analysis, so when a vulnerability sits three or four layers down in your dependency tree, the fix targets the correct package and resolves the version constraints that pull it in. A tool that only bumps your direct dependencies leaves the majority of transitive CVEs untouched.
How does auto-fix avoid introducing breaking changes? Every proposed fix runs through your existing test suite and compatibility checks in CI before it is eligible to merge. If the upgrade breaks a test, the pull request stays open for a human instead of merging automatically. Griffin also prefers the smallest safe version bump that clears the vulnerability — a patch or minor upgrade over a major one — to minimize behavioral change.
Which ecosystems and languages are supported? Auto-fix covers the major package ecosystems — npm, PyPI, Maven, Go modules, RubyGems, and more — plus container images. Coverage is strongest for known-CVE dependency vulnerabilities, where a defined safe upgrade target exists. For the current, detailed support matrix, the Auto Fix product page and the docs are the source of truth.
Do I have to let it merge automatically? No. The default is a pull request that a human reviews and merges. Auto-merge is opt-in and gated behind passing CI, and you scope it to the repositories and severities you trust. Many teams keep review-required for application code and enable auto-merge only for routine patch-level dependency updates.
How are fixes prioritized when I have hundreds of findings? By exploitability, not by count. Reachability-aware SCA determines whether the vulnerable code path is actually invoked, and findings are scored with EPSS exploit-likelihood, so the fixes that reduce real risk are generated first. This keeps the pull-request queue focused instead of flooding your team with bumps for unreachable code.
What if there is no fixed version available upstream? Then auto-fix will not invent one. Griffin surfaces the finding, notes that no safe upgrade exists yet, and can recommend a mitigation or track the advisory until a patched release ships. Fabricating a nonexistent version would break your build and erode trust, so the system is deliberately honest about the limits of what can be auto-fixed.
How does container auto-fix ("Fix Right") work without me rebuilding everything? Fix Right maps your vulnerable image to a patched, pre-scanned equivalent that has been screened for known CVEs and malware, so you deploy the hardened image instead of the vulnerable one. It also supports automatic image patching and updates, and pairs with continuous runtime scanning so newly disclosed CVEs in running images get flagged for remediation.
Can I run auto-fix enforcement in CI? Yes. The Safeguard CLI runs the same checks in your pipeline and can block a merge that would introduce a new vulnerable dependency. Using the CLI as a pre-merge gate while Auto Fix opens remediation PRs means you both stop new risk from landing and clear the existing backlog.
How is this different from a plain dependency-bump bot? A bump bot upgrades on a schedule without knowing whether the change matters, whether the vulnerable path is reachable, or whether the upgrade is safe. Auto Fix is risk-driven and validated: it fixes reachable, exploitable issues, resolves transitive constraints, runs your tests, and extends to container images. Validation and container remediation are where the results diverge from a scheduled bump.
How do I trust the fixes before turning on more automation? Start by keeping every fix as a review-required pull request and watch a few weeks of results — the diffs, the CI outcomes, the false-positive rate. As specific fix classes prove reliable, promote them to auto-merge one at a time. Trust is earned per category, and the platform lets you tighten or expand automation without an all-or-nothing switch.
Keep Reading
Explore the full Auto Fix workflow, the Griffin AI engine that authors the changes, and reachability-aware SCA that decides what to fix first. Enforce fixes pre-merge with the Safeguard CLI, see where validation and container remediation land against a dependency-only scanner in our Snyk comparison, or read the Safeguard documentation for the current ecosystem support matrix.