Often yes, within limits. Fixing a small security issue in a file you are already editing costs less than a separate ticket, because the context is loaded and the tests are running. Keep the fix small, put it in its own commit, and never let it hide inside a large feature change.
Why it is cheap
Most of the cost of a fix is not the edit. It is finding the code, understanding it, setting up the test and waiting for review. When an engineer is already in the file for another reason, much of that cost is already paid. The marginal cost of a one line fix can be a few minutes.
This is the same idea as leaving a campsite cleaner than you found it, applied to risk. Done steadily, it chips away at the backlog without a planning meeting.
What qualifies
Good candidates are small, local and well understood.
| Good candidate | Poor candidate |
|---|---|
| Add a missing input length check in the function you are editing | Redesign the authorization layer |
| Replace a deprecated crypto call with the supported one | Migrate to a new auth library |
| Parameterize a query next to your change | Rewrite the data access module |
| Bump a patch version in a manifest you are already editing | Jump a dependency across a major version |
A useful test: could a reviewer understand the security change in under two minutes, without reading the rest of the pull request? If not, it needs its own ticket.
Rules that keep it safe
- Separate commit. Message it as a security change, so it can be reviewed, reverted or cherry picked alone.
- Same test standard. Add or update a test that fails before the fix and passes after. See write the failing test before the vulnerability fix.
- Tell the reviewer. Put a note in the description pointing to the change, so it does not slip past.
- Stay in the blast radius. If the fix touches code outside the area your feature already changes, split it out.
- Link the finding. Reference the ticket or finding so it closes automatically and the backlog count drops.
When to avoid it
Do not mix security fixes into a risky release, such as a large migration, where a failure would force a rollback that also removes the fix. Also avoid it when the fix changes behavior that customers depend on, since that needs a communication plan. For the broader question see should security fixes ship separately from feature changes.
Make it visible to the team
Opportunistic fixes are easy to lose. Count them. Add a label such as "security-fix" to the pull request and report the count each sprint next to planned work. That also helps in the case for investing in capacity, because it shows how much risk reduction happens outside the plan. It pairs with making invisible security work visible in sprint reviews.
Let tools point the way
Engineers cannot fix what they do not see. Surfacing findings in the editor or on the pull request, near the file being edited, turns "someone should fix that" into "I will fix that now." Safeguard provides VS Code, JetBrains and CLI integrations alongside dependency scanning, so findings for the file you are in can appear while you work. Its policies and gates can also stop new issues entering in the same pull request.
Quick check
Does this replace planned security work?
No. It trims small items cheaply. Large issues still need tickets, owners and dates, since they will not be fixed by accident.
What if the reviewer objects to the extra change?
Offer to split it into a second pull request. A separate commit usually makes the objection moot, and the discussion shows the reviewer which risk you fixed.
Last reviewed: 19 October 2026.
