Use a fix PR when the change is small, mechanical and testable, such as a dependency bump with a known fixed version. Use a ticket when the fix needs design decisions, coordination across teams, downtime or a business call. Many findings need a PR plus a short note, not one or the other.
Why PRs usually win
A ticket describes work. A pull request is the work. When a scanner files a ticket, someone must read it, find the code, work out the fix, make the change, test it and open a PR. A fix PR skips the first steps. For routine dependency fixes, that saves most of the effort, and it keeps the time between discovery and fix short.
When a ticket is still right
The fix requires a decision. Replacing a library with a different one, dropping a feature or changing an API contract belongs on a roadmap, not in an automated PR.
Multiple teams are involved. A shared library used by twelve services needs a rollout plan: who upgrades first, how to coordinate. A ticket or a short project is the right container.
There is no fixed version. If the maintainer has not shipped a fix, the options are mitigation, replacement, or acceptance of risk. A person must choose and document it.
The change needs downtime or data migration. Anything with an irreversible step needs scheduling.
The finding is a false positive or accepted risk. Closing it needs a recorded reason, not a code change. Exploitability statements such as VEX can capture that decision. See the exploitability demo.
The code is unowned. A PR to an abandoned repository sits unreviewed. A ticket to find an owner comes first.
A quick decision table
- Patch or minor bump with a fixed version: Fix PR
- Major bump with a migration guide: Fix PR plus a human owner, higher tier
- No upstream fix yet: Ticket, with mitigation options
- Cross team shared library: Ticket or project plan, then PRs
- Accepted or not exploitable: Recorded decision, no PR
- Unowned repository: Ticket to assign an owner
Do both when helpful
A fix PR can link to a ticket that tracks the wider effort. For example, a ticket "retire library X" with fix PRs as interim patches. Keep the ticket short and the PR evidence-rich, as described in what a good fix PR description contains.
Do not let tickets pile up
If most of your backlog is tickets that could have been PRs, check the pipeline. The aged backlog may be a candidate for bulk remediation, reviewed under tiers.
Click through it at your own pace, or open it full screen.
Quick check
Is a PR always faster than a ticket?
For routine mechanical fixes, usually. For fixes needing a decision or coordination, a PR just moves the thinking into the review, so a ticket may be clearer.
Safeguard's pitch is pull requests instead of tickets for the mechanical cases, with approval left to you.
Last reviewed: 19 October 2026.
