Set approval targets by urgency lane, not by who opened the PR. An exploited vulnerability needs a person within hours, a normal security fix within the working week, and routine bumps on your regular cadence. Write the targets down, name the approver, and define what happens when the target passes.
Why a single target does not work
If every bot PR must be approved "quickly", nothing is quick, because reviewers cannot tell which one matters. If none has a target, security fixes sit beside routine bumps. Lanes give reviewers a way to sort.
Define three lanes
| Lane | Typical trigger | Approver | Target |
|---|---|---|---|
| Emergency | Known exploitation or a critical issue in code you run and reach | Service owner plus security contact | Within hours, same day |
| Security | A vulnerability fix in a package you use, no known exploitation | Service owner | Within a few working days |
| Routine | Version updates with no security angle | Service owner or delegate | On the normal grooming cadence |
The words in the target column are choices for you to make. Pick actual times that your team can meet, and write them in your policy. A target nobody can meet teaches people to ignore targets.
What puts a PR in the emergency lane
Use evidence, not feeling. Two questions help: is the flaw being exploited, and can the vulnerable code be reached in your application? An exploitability check and reachability analysis answer these. A critical score on a package your code never calls is a different case from a medium issue that is under active attack. See emergency patch vs routine patch criteria and patch SLA design for 48 hour exploitation windows.
Who approves, and who covers
Name a primary and a backup for every service. Holidays and illness happen, and a fix PR waiting for one person's return is a process failure. For after hours, see who gets the vulnerability alert on Friday night.
Keep author and approver separate where your rules need it. If a person triggered a fix PR, whether they may also approve it is a policy decision covered in can the person who triggered a fix PR also approve it.
What happens when the target passes
Silence is the worst outcome. Pick an escalation step for each lane.
- A reminder to the approver and their backup.
- A message to the team lead.
- A written risk acceptance with an owner and a review date, if the fix will not be merged.
A missed target is information. If it happens often in one team, the cause is usually workload, unclear ownership or a test suite nobody trusts, and the fix is not a stronger reminder.
Make fast approval possible
Speed depends on what the reviewer sees. A PR that states the vulnerability, the version change, the test result and the rollback path can be approved in minutes. A bare title cannot. See evidence attached fix PRs reviewers trust and the five minute review checklist.
Try it yourself
Open the demo and look at how exploitability changes the priority of a finding. Think about which lane each result would land in.
Click through it at your own pace, or open it full screen.
Safeguard can open fix pull requests through autonomous remediation. It is off by default and every category starts on Manual, so a person approves each change. You can also run a free scan to see which dependencies have known fixes before you decide what to automate.
Quick check
Should emergency fixes skip the test gate?
No. Shorten the review, not the checks. See your emergency path for what to defer, such as non-urgent cleanups.
Can the same person approve in every lane?
They can, but give emergency a second person so one reviewer is not a single point of failure.
Last reviewed: 19 October 2026.
