An automated fix pull request is the unit of work behind autonomous remediation: instead of assigning a vulnerability to an engineer, the platform opens a real PR containing the change that resolves it. Safeguard's Griffin AI authors these pull requests, runs your CI against them, and — when you opt in — merges them automatically once the build is green. The pull request is deliberate: it slots into the review, CI, and branch-protection workflow your team already uses, so automation adds fixes without bypassing your controls. This FAQ covers what those PRs contain and how they land.
Frequently Asked Questions
What does an automated fix pull request contain? A focused change plus its justification. The diff is the dependency upgrade, code patch, or manifest update that resolves the vulnerability; the description explains which CVE it addresses, why this version or change was chosen, and what the reachability and severity context is. The CI results are attached, so a reviewer sees at a glance that the fix builds and passes tests before deciding to merge.
How does the PR get validated before it can merge? Your existing CI runs against the branch exactly as it would for a human contributor. Auto Fix treats a passing build as a hard precondition — the pull request is only eligible for merge when your test suite and compatibility checks are green. A failing build leaves the PR open and routed to a human, never merged automatically.
Can these PRs merge themselves, or does a human review them? Both are supported, and you choose per scope. The default is human review: Griffin opens the PR and a person merges it. Auto-merge is opt-in, enabled per repository and severity, and always gated behind passing CI. A common configuration is review-required for application-code changes and auto-merge for patch-level dependency bumps that pass tests.
Which source control platforms are supported? Safeguard integrates with the major SCM providers — GitHub, GitLab, Bitbucket, and Azure DevOps — and opens fix pull requests (or merge requests) natively in each. The automated PRs respect your branch protection rules, required reviewers, and status checks, so nothing about your governance is bypassed by automation.
How do you keep me from drowning in pull requests? Prioritization and scoping. Reachability-aware SCA means PRs are opened for exploitable, reachable findings first rather than every package with an advisory, and EPSS scoring sequences the most likely-to-be-exploited issues ahead of the rest. You also control which repositories and severities generate PRs, so the flow matches your team's capacity.
Do automated fixes respect my branch protection and required reviewers? Yes. The whole point of using pull requests is that your existing rules still apply. If a branch requires two approvals and a passing security check, an automated fix PR must satisfy those same conditions. Auto-merge only completes when every required gate — including your own status checks — is satisfied.
What happens when a fix breaks the build? The pull request stays open and is not merged. A red build is useful signal: it usually means the safe-looking upgrade has a real incompatibility with your code. A human can then adjust the surrounding code, choose a different version, or defer the fix. The automation never overrides a failing gate to force a merge.
Can it fix transitive dependencies in the pull request? Yes. Deep transitive analysis lets the fix target a vulnerable package several layers below your direct dependencies and adjust the version constraints needed to resolve it. The PR then reflects the correct lockfile or manifest changes, not just a surface-level bump that leaves the transitive CVE in place.
How are multiple related fixes grouped? Fixes can be batched sensibly — for example, related dependency updates in a single ecosystem grouped into one pull request to reduce review overhead, while riskier or unrelated changes stay isolated so a problem in one does not block the others. The goal is to minimize the number of reviews without bundling changes whose blast radius should be kept separate.
Can I enforce the same checks in CI myself? Yes. The Safeguard CLI runs the identical vulnerability checks in your pipeline and can block a merge that would introduce a new vulnerable dependency. Pairing the CLI as a pre-merge gate with automated fix PRs means new risk is stopped at the door while the existing backlog is cleared by the PRs.
Is the pull-request approach auditable for compliance? Highly. Each fix is a permanent record linking a finding to its resolution: the CVE, the change, the CI evidence, and the approver (human or gated auto-merge). That trail is often cleaner than manual remediation, where the connection between a scanner finding and the commit that fixed it can be hard to reconstruct after the fact.
How is this better than a scheduled dependency-update bot? Scheduled bots open bumps blindly, without knowing whether the change reduces risk or whether the vulnerable path is reachable, and they stop at the finding. Automated fix PRs are risk-driven and validated end to end — reachability decides which PRs are worth opening, and your CI decides which are safe to merge.
Keep Reading
See how fix pull requests are authored by Griffin AI, how Auto Fix validates and merges them, and how reachability-aware SCA decides which to open first. Add a pre-merge gate with the Safeguard CLI, compare validated fix PRs to a dependency-only scanner in our Snyk comparison, or read the Safeguard documentation to connect your SCM and configure auto-merge.