Describe an automated fix pull request as a proposed change that goes through the same path as any other: a named author identity, review by a person, tests, a recorded merge and a rescan. The tool proposes. People approve. Show the settings that prevent it from merging itself, and the log that proves it.
What worries the auditor
The concern is not that fixes are automated. It is separation of duties and traceability. Who wrote it, who approved it, what tested it, and can anyone merge to the main branch without a human seeing it?
If you can answer those four in one page, the conversation is short.
The flow, step by step
- Trigger. A finding with a fix available, ranked using reachability and exploitation signals.
- Proposal. The tool opens a pull request from its own identity, with the dependency change and a description of the finding.
- Checks. Your normal CI runs: build, tests, and any policy gate.
- Review. A code owner reads the change and approves or rejects it.
- Merge. Branch protection requires the review and passing checks.
- Rescan. The next scan confirms the finding is gone.
Every step leaves a record in a system you already audit: the source control history, the CI run and the scanner.
Controls to show
| Auditor question | What to show |
|---|---|
| Who authored the change? | The bot identity in commit history, distinct from human accounts |
| Who approved it? | Review record from a named person |
| Can the bot merge alone? | Branch protection settings that require review |
| Was it tested? | The CI run linked to the pull request |
| Can it be switched off? | The configuration, with a change log |
| What did it touch? | The diff, limited to dependency manifests or the stated files |
Keep the identity separate. A bot that shares a human's credentials makes the trail ambiguous.
Start conservative and say so
A sensible rollout begins with fix proposals disabled or set to manual for each category, then moves categories to automatic only after a period of reviewed pull requests. Document that decision, including who made it and when. NIST's Secure Software Development Framework describes updating records of design decisions, risk responses and approved exceptions, so a dated record of how you widened or limited automation fits the same habit.
Use prioritization, not volume
An auditor may ask why a given pull request was opened first. If the queue is ordered by reachability and exploitation signals, say so, and keep the ordering reason on the ticket. See should reachability decide which fixes get automated.
What to avoid claiming
Do not say the tool "fixes vulnerabilities automatically" without the review step. Do not say it never breaks builds. State that tests and a reviewer decide, and that rejected pull requests are recorded too.
Try it yourself
Click through it at your own pace, or open it full screen. Follow the path from a finding to a proposed change.
Quick check
Is an automated pull request a change that needs approval?
Treat it exactly like a human authored change. Your change management policy should not distinguish by author type.
What if we merge fix pull requests without review?
Then say so and explain the compensating controls, such as tests and a gate. Expect more questions, and consider requiring review.
Safeguard's autonomous remediation opens fix pull requests, is off by default and keeps every category on Manual until you change it. You can try the free scan.
Sources
Last reviewed: 19 October 2026.
