How to verify a vulnerability fix with fixed and regressed issues

Cyberlop marks a finding Fixed when a later scan of the same target no longer detects it, and flags it Regression if it comes back. To verify a vulnerability fix, ship the change, run the same scan profile again, then check the Diff tab and the Triage column on Issues. A Fixed or Regressed state is a result of a re-scan, so it is evidence rather than a claim.

What are fixed and regressed issues in Cyberlop?

A fixed issue is a finding that an earlier scan reported and a later scan did not detect again. A regressed issue is a fixed finding that reappeared. Both are triage states on a finding, shown beside New, False Positive and Accepted Risk.

They work because findings are not tied to one scan. Issues persist per target, so the same weakness keeps one history across every scan you run. A regression is therefore a returning problem with a past, not a fresh finding with no context.

Most teams stop at "the ticket is closed". Closed only says someone believes the code changed; Fixed says the scan looked again and found nothing. That is the idea behind fix verification, and it is why the retest is the step that finishes vulnerability management.

Speed matters. The Verizon Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in (Verizon DBIR, 2026). A flaw you think you closed, but never re-checked, is still a way in.

What are the triage states and what do they mean?

Cyberlop shows five triage states on the Triage column of Issues and of a scan's Findings tab. Two are set by scans and three are set by people.

The dialog's Disposition list offers Open (reopen), Fixed, False Positive and Accepted Risk. Regression is not in that list: only a scan can raise it. See key terms for the rest of the vocabulary.

Who decides a finding is fixed: you or the scan?

Both can, and they should agree. The product documentation states that a re-scan that no longer finds a previously reported issue marks it fixed, and that a finding is only auto-marked fixed when the scan genuinely did not re-detect it. You can also set Fixed by hand with Update status, which is useful for a change you want to track before the next scan.

A manual Fixed is a note of intent

If you mark Fixed yourself, the next scan still has the last word. Documentation says dispositions are respected across future scans and that a fixed issue that reappears becomes a regression rather than a fresh finding.

A scan-set Fixed is a result

When the scan sets Fixed, treat it as test evidence. It is only as strong as the scan behind it, so use the same profile and a Completed scan.

How do you verify a fix by re-running the scan?

Re-run the same scan profile against the same target after you deploy the fix, wait for a Completed result, then read the Diff. Follow these steps in order.

1. Note the finding. On Issues, open the finding and record its ID (for example INJ-VULN-02), its title and its Location. A black-box finding shows a method and path; a white-box finding shows a source file and line range.
2. Fix and deploy. The scan tests the running app at its URL, so the change must be live there. For a white-box target the scan also reads the repository branch you set on the target, so the fix must be on that branch.
3. Re-run the same profile. Click ▷ Scan on the profile row, or Scan beside the old run in Recent Scans, which re-runs the same profile.
4. Wait for Completed. Open the scan from Recent Scans. A typical scan of a small app takes roughly an hour. Do not read results from a Failed or Cancelled run as a verdict (see the troubleshooting section below).
5. Open the Diff tab. Your finding should sit in the Fixed column. If it sits in Regressed or does not move, the fix did not hold.
6. Confirm on Issues. Search for the title, check that Triage reads Fixed, and add a note such as the ticket reference with Update status.

The scan did not detect your finding again, which is exactly what you want. For the wider idea, see closed-loop retest and how it works.

How do you read the Diff tab?

The Diff tab compares a scan with the previous completed scan and sorts findings into three columns: New (red), Fixed (green) and Regressed (amber). Each column lists findings as a severity badge and a title, and shows "+46 more"-style text when the list is long. Full detail lives in compare scans.

On the first scan of a profile the tab reads "No previous scan to compare against." That is normal: there is nothing to diff yet, so verification starts with your second completed scan.

Can you get the Diff from the API?

Yes. GET /api/scans/:id/diff returns findings against the target's history as new, fixed and regressed, and needs the scan:read permission. Issues can be listed with a triageStatus filter through GET /api/issues, which needs issue:read. The API reference guide lists every group.

What should you do when an issue regresses?

Treat a Regression as a stronger signal than a New finding, because the same weakness came back after a fix.

• The fix was never deployed. Someone merged the branch but never updated the running app, or patched a different environment.
• A later change undid it. A merge, rollback or copy of old code restored the vulnerable path.
• The fix covered one code path only. The same flaw exists in a second endpoint or file, so the fix was narrower than the weakness.
• The fix hides the symptom. Someone added a client-side check or a hand-picked filter, but the server still accepts the request.

Open the regressed finding and read the Evidence tab: the payload, request, response and reproduction steps show what worked this time. Put the finding back on someone's list by setting Assignee and adding a note about the earlier fix, then click Update status. The read a finding guide explains each evidence block.

The security regression test habit helps here: once you have closed a flaw, keep scanning that area so a reintroduction shows up in the next run. Scheduled scans and CI/CD runs do this without anyone remembering.

How do you track fixes across the whole team?

Use the dashboard for the headline and Issues for the detail. The dashboard has a Fixed issues stat card and a Remediation card showing Open, Fixed, Regressed and False positives counts, plus a fix rate percentage. Read it weekly to see whether fixes outpace new findings.

Filter Issues by triage state

The chip row on Issues starts with a mode switch that toggles between Hiding ▾ and Showing only ▾, followed by chips for New, Regression, Fixed, False Positive and Accepted Risk. The two modes give you different questions to ask.

Combine chips with the severity, confidence, class and target filters. The issues list guide covers the full toolbar. For a deeper look at people and process, read triage findings and the finding triage term.

Report and export what was fixed

On a scan page, Download report ▾ offers three PDF modes: Open issues only, Include fixed & accepted and Fixed issues only. Use Fixed issues only as a closure note and Open issues only as the work list.

For a spreadsheet or a tracker, use Export JSON or Export CSV on Issues. See download PDF reports and export findings. Each manual change also appears in Activity as a Triage · Issue entry with a chip such as "Status: new → fixed", the finding title and the assignee, which gives you a trail for audit questions. See activity feed.

Troubleshooting: why was my fix not marked Fixed?

Most surprises come from comparing two scans that did not test the same thing. Check this list before you doubt the result.

Keep the profile steady

A scan cannot re-detect what it is told not to test. If you narrow vulnerability classes, switch the exploitation phase off or add an avoid rule between runs, a finding can vanish for reasons unrelated to your fix. Change the profile only on purpose, using edit a scan profile, and re-verify after.

Why do similar findings merge?

Because several specialists examine the same code, Cyberlop collapses findings that describe the same weakness into one representative, keeping the version with the most evidence. This is finding deduplication. It keeps the Diff readable, so one fix is one line in the Fixed column.

Next step

Fixed and Regressed tell you what changed, not how urgent it is. Read severity and confidence to learn how to order the remaining work, and see how to read a finding for what good evidence looks like.