Home / Knowledge hub / Regression
Knowledge hub
Regression
A bug that was fixed and has come back, usually undone by a later change.
What it means
A regression is a bug somebody fixed that has come back. Nobody reintroduces one on purpose. A later change touched the same code, a refactor moved the check, or a merge quietly dropped a line.
In security terms, a vulnerability you already paid to close is open again. The ticket that closed it is months old and archived.
Why it matters
Fixing the same flaw twice wastes money, and the second time usually costs more. Everyone had assumed that area was settled.
Regressions also wear down trust in the process. If the list never shrinks, people stop reading it. A quieter cost sits underneath. Somebody has to work out whether a finding is genuinely new or something the team already closed last year. That question takes longer than reading the finding itself. Customers notice as well. A buyer who watched you close a finding last year will ask why it is back, and the honest answer is uncomfortable.
How it shows up
You spot a regression only by comparison. A tool that hands you a fresh list every run cannot tell you that finding twelve is the one you closed in March. It arrives as new, and somebody triages it from scratch.
Security regression tests behave like any other test. Once somebody writes an exploit, keeping it and running it again costs almost nothing, and NIST treats retesting after remediation as part of the assessment cycle. Cyberlop compares each run against the previous one and labels findings new, fixed or regressed. See how runs compare, or read what remediation costs when it happens twice.
Questions people ask
Regression, answered
What is security regression testing?
It means retesting to confirm that a flaw you already fixed is still fixed. You keep the exploit or the test case from the first time, then run it again after later changes.
NIST treats retesting after remediation as part of the assessment cycle rather than an optional extra.
Why did a vulnerability we already fixed come back?
Almost always because a later change touched the same code. A refactor moves a check, a merge drops a line, or somebody restores an older file during a rollback.
Nobody does it deliberately, which is exactly why a kept test guards it better than a kept memory.
Do penetration testing providers retest fixes for free?
Some do and some charge. A common arrangement is one retest inside 90 days, with the cost already folded into the price of the original test. Others give you a longer window or several retests.
Ask before you sign. A report you cannot close is half a job.
How soon should we retest after shipping a fix?
As soon as the fix reaches an environment you can test, while the detail is still fresh in somebody's head.
After that, the useful rhythm is every release, automatically, rather than once a year by hand.
Does Cyberlop confirm that a fix actually worked?
Today it compares each run against the previous one, so a returning finding arrives labelled as a regression rather than as something new.
Replaying the original proof against the fixed code is a separate feature, prove-the-fix, and it ships on 16 November 2026. We would rather give you the date than imply we already do it.
Sources
Where this comes from
Related
Terms that sit next to this one
Remediation
The actual work of fixing a finding: the change, the review, the release.
Vulnerability management
The loop of finding, prioritising, fixing and checking the fix held.
CI/CD
The pipeline that builds, tests and ships code on every merge.
False negative
A real vulnerability that a test failed to find.
Has a fix you paid for come back?
Cyberlop compares every run against the one before it, so findings arrive labelled new, fixed or regressed instead of as a fresh list each time. Ask us how two runs line up.
Or start with a $199 pilot on one application: thirty days, success criteria agreed before day one, credited against the annual if you convert.