Verify a security fix by replaying the original reproduction steps on the fixed build, trying nearby variations, and confirming that a regression test now exists and fails without the fix. Only then close the ticket, and record what you checked so the closure can be audited later.
Why a quick retest is not enough
A fix often blocks the exact input from the report and nothing else. The same flaw may survive through another parameter, another endpoint or another encoding. QA is the last check before the ticket closes, so the retest should be wider than the original proof of concept.
The checklist
- Confirm you are testing the right build. Note the version or commit, and check that the fix is really in it.
- Replay the original steps exactly. The attack should now fail in a clear way.
- Check the failure mode. A refusal with a clean error is good. A crash, a hang or a different leak is not.
- Try variations: other parameters, other HTTP methods, different encodings, different roles.
- Try the same pattern elsewhere. If one endpoint missed an ownership check, look at its siblings.
- Test normal behavior. The fix should not break legitimate use.
- Check the regression test. It should exist, run in CI, and fail when the fix is reverted.
- Check logs and monitoring where relevant. Rejected attempts should be recorded.
- Update the ticket with evidence and close it.
What counts as evidence
| Evidence | Why it helps |
|---|---|
| Build or commit ID tested | Proves the fix was in what you ran |
| Before and after request and response | Shows the change in behavior |
| Link to the regression test and a passing CI run | Shows it will stay fixed |
| List of variations tried | Shows the retest was not narrow |
| Date and tester | Gives an audit trail |
Redact real data from anything you attach.
Reverting to prove the test
The most useful step is the one people skip. Temporarily revert the fix in a branch and run the new test. It should fail. If it passes, the test does not exercise the bug, and the ticket is not really covered. This takes minutes and removes the most common false sense of safety.
When the fix is a dependency upgrade
If the fix is a newer version of a library, check that the new version is the one actually installed and shipped, not just listed in a manifest. Check the lock file and the built artifact. Then run your normal tests plus any test written for the original issue. Also check that the upgrade did not pull in unrelated behavior changes.
When you cannot fully verify
Sometimes a fix depends on production configuration or a third party. Do not close the ticket silently. Mark it as fixed pending verification, name who will confirm and by when, and keep a reminder.
Closing the loop
After closing, tell the reporter, especially if it came from a customer or researcher, using whatever disclosure process you follow. Keep the ticket private until the team decides how and when to publish details.
Finally, add the lesson to the team notes: what class of bug this was, and which general test or review step would have caught it earlier.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how a fix is linked to the finding it addresses, then think about what proof you would attach.
Safeguard's autonomous remediation can open fix pull requests for dependency findings. It is off by default and every category starts on Manual. A free scan shows what it would flag.
Quick check
Is replaying the original steps enough?
No. Also try variations and sibling endpoints, and confirm a regression test exists.
What if the regression test passes without the fix?
Then it does not test the bug. Rewrite it until it fails on the unfixed code.
Last reviewed: 19 October 2026.
