Remediation automation is the operational layer that turns individual fixes into a repeatable, policy-driven program — deciding which vulnerabilities get fixed automatically, which need a human, and how the whole thing scales across an organization. Detection tells you what is wrong; remediation automation gets it fixed at scale. Safeguard runs this through Griffin AI, which authors fix pull requests, validates them in CI, and can auto-merge on an opt-in basis governed by the automation strategies you set. This FAQ is aimed at the person responsible for making it work day to day.
Frequently Asked Questions
What is remediation automation, operationally? It is the set of policies and workflows that move a finding to a merged fix without a human doing the manual work at each step. In practice it means configuring which repositories participate, which severities are eligible for autonomous merge, how fixes are validated, and where a human must sign off. The output is a running program, not a one-off script — Auto Fix provides the mechanics and you provide the policy.
How do automation strategies work? An automation strategy is a rule set that says, for a given scope, what the system is allowed to do — open a PR only, open and auto-merge on passing CI, or hold for human review. You can define different strategies per repository, per team, or per severity, so critical application code stays human-reviewed while routine dependency patches flow automatically. Strategies are adjustable as your confidence grows.
Should I turn on auto-merge everywhere at once? No — that is the fastest way to lose the team's trust. Start with fixes opened as review-required pull requests, watch the quality for a few weeks, then promote one low-risk class at a time (patch-level dependency bumps are the usual first step) to gated auto-merge. Autonomy is earned per category, and the platform supports that gradual expansion rather than an all-or-nothing switch.
How does automation decide what to fix first? By risk, not by finding count. Reachability-aware SCA filters to vulnerabilities whose code paths are actually reachable, and EPSS exploit-likelihood plus CVE severity sequence the queue so the most dangerous, most exploitable issues are remediated first. This keeps automation aimed at risk reduction instead of generating noise for unreachable code.
How do I set and enforce remediation SLAs? Define SLAs by severity — for example, critical reachable findings remediated within days, high within a couple of weeks — and let automation do the heavy lifting to meet them. Because fixes are authored and validated automatically, the practical bottleneck becomes review time rather than engineering time, which is what makes aggressive SLAs achievable. The Safeguard CLI can enforce the floor in CI so new violations do not accumulate while you burn down the backlog.
What metrics should I track for a remediation program? Three that reflect risk reduction: median age of open reachable findings, mean time to remediate a critical finding from detection to merged fix, and the share of repositories with automated remediation and CI gating enabled. Avoid making "total findings fixed" the headline metric — it rewards volume over impact. A falling median age of reachable findings is the signal that automation is working.
How does a small team scale this across hundreds of repositories? Automation is what makes the ratio work. When the system authors the fix, validates it, and only escalates the exceptions, a handful of engineers can oversee remediation across the whole portfolio instead of hand-patching each repo. The team's job shifts from writing fixes to setting policy and reviewing the changes that genuinely need judgment.
Where does the human stay in the loop? Wherever you decide. The common pattern is human review required for high-severity and application-code changes, and gated auto-merge for routine dependency updates that pass CI. You can also require a human whenever a fix touches specified sensitive paths. The point is that human-in-the-loop is a configurable dial, not a fixed setting — you tune it to your risk tolerance.
What happens when automation cannot safely fix something? It escalates rather than guesses. If no patched upstream version exists, or a proposed fix fails CI, the finding stays open and is routed to a human with the context needed to act — the advisory, the failed build, and any suggested mitigation. Automation handling the routine cases is precisely what frees your team to focus on the hard exceptions.
How does remediation automation support compliance? Every automated action is a pull request with a durable audit trail: the CVE, the change, the validation evidence, and who or what approved it. That makes it straightforward to demonstrate to a SOC 2 or similar auditor that vulnerabilities are being remediated within policy and that the process is consistent and traceable — often more so than manual remediation.
Can I combine automated remediation with pre-merge gating? Yes, and you should. Run Auto Fix to clear the existing backlog while the Safeguard CLI blocks new vulnerable dependencies from merging. Backlog burn-down plus a pre-merge gate is what turns a one-time cleanup into a durable posture where the vulnerability count trends down and stays down.
How does this compare to running a scanner plus manual triage? A scanner-plus-triage model stalls at the finding: someone still has to write, test, and merge every fix, and that queue rarely gets shorter. Remediation automation collapses that work into reviewable, validated PRs, so the backlog actually trends down instead of holding steady while new findings arrive.
Keep Reading
Configure the engine on the Griffin AI page, see the fixes it produces in Auto Fix, and understand prioritization via reachability-aware SCA. Enforce a pre-merge floor with the Safeguard CLI, review plan options on pricing, or read the Safeguard documentation to set up automation strategies and SLAs for your organization.