Home / Knowledge hub / Security regression test
Knowledge hub
Security regression test
An automated test that fails if a fixed vulnerability ever returns.
What it means
A security regression test is an automated test written to prove that a specific vulnerability stays fixed. It repeats the original abuse, such as requesting another customer's invoice, and passes only if the application refuses. It stays in the codebase as a permanent check.
It is a normal regression test with a security purpose. Instead of checking that a feature still works, it checks that a hole stays closed. When someone changes the code later and reopens the flaw, the test fails and the change does not ship.
Why it matters
Fixed flaws have a habit of coming back. A refactor removes an ownership check, a merge restores old code, a new endpoint copies the unsafe pattern. Without a test, nobody notices until the same bug is reported again, or exploited.
It also turns a pentest report into something lasting. A finding closed by a one-off fix is only closed until the next change. With a test attached, the fix keeps being proved on every build, and you can show an auditor that repeat findings are caught automatically.
How it shows up
Write the test from the proof of the finding. If the report shows that account A could read account B's order by changing the number in the URL, the test uses account A to request B's order and expects a refusal. Put it in your normal test suite so it runs in CI/CD.
The mistakes repeat. The test checks the symptom but not the cause, so a variation of the same flaw slips past. It runs against mocked code instead of the real behaviour. Or it is skipped when the build is slow. Aim for tests of the behaviour that matters, and keep them quick. See also regression and retest.
Questions people ask
Security regression test, answered
Is a security regression test the same as a retest?
They are close. A retest is a one-off check after a fix, usually by the tester. A regression test is automated and runs on every build, so it protects against the flaw returning later.
Who should write the tests?
The developer who fixes the flaw, using the evidence from the finding as the starting point. They know the code best, and the proof of the exploit tells them exactly what to check.
Will a regression test catch variations of the same flaw?
Only if you write it broadly. A test for one URL will miss a sibling endpoint with the same flaw. Test the rule, such as ownership checks on all order endpoints, not just the one that was reported.
Do security regression tests slow the build?
They can if they are heavy. Keep them small and run the slow ones on a schedule. A few focused checks add very little time, and they are far cheaper than a repeat incident.
Do we need one for every finding?
Not necessarily. Prioritise serious findings and those that are easy to reintroduce, such as missing authorisation checks. Low-risk items may be covered by a general rule, or by a periodic retest.
Sources
Where this comes from
Related
Terms that sit next to this one
Regression
A bug that was fixed and has come back, usually undone by a later change.
Retest
Running the test again to confirm that a reported flaw has really been fixed.
Closed-loop retest
Re-running the exact exploit after a fix, so the finding closes only on proof.
Fix verification
Proving a fix works by repeating the original exploit against the new code.
Mutation testing
Deliberately changing code to check whether your tests notice the change.
How do you know it stays fixed?
We prove a fix by re-running the exact exploit against the new code, and the same proof makes a good regression test. Run it on a schedule or in CI/CD and gate a build. Book a pilot on one app.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.