How to compare scans in Cyberlop with the Diff tab

To compare scans in Cyberlop, open a finished scan from Recent Scans and click the Diff tab. It lists the findings that are New, Fixed or Regressed against the previous completed scan of the target. A scan comparison is a diff: it shows what changed between two runs, not the whole list again.

What is a scan comparison in Cyberlop?

A scan comparison is the Diff tab on the scan detail page. It sets one scan against the previous completed scan and sorts the difference into three columns. Cyberlop keeps issues per target across scans, so each re-scan can answer one question: did the last round of fixes work, and did anything new or old turn up?

The Diff tab sits beside Overview, Findings and Sitemap. The header reads “Compared to previous completed scan”. If you want the other tabs explained first, read Scan detail page.

What do New, Fixed and Regressed mean?

Each column holds findings shown as a severity badge and a title. Long columns are cut short with a note such as “+46 more”, so open the Findings tab or the Issues list when you need the full set.

What does a New finding mean?

It is a weakness this scan found that the previous completed scan did not. It may come from fresh code, a new endpoint, or a path the earlier scan never reached. A new finding is not proof that your last release broke something, so check the Sitemap and the commit before you decide.

What does a Fixed finding mean?

It was reported before and was not found again. The in-app documentation says a finding is only marked fixed automatically when the scan genuinely did not re-detect it. That is a good sign, but read the finding once to confirm the fix is the reason, not a gap in coverage.

What does a Regressed finding mean?

It was fixed, and a later scan found it again. Cyberlop flags it as a regression instead of a fresh finding, so the history stays honest. Typical causes are a revert, a merge that restored old code, or a second code path that was never patched.

How do you compare two scans, step by step?

You do not pick two scans by hand. Run the same profile again after your fix, then open the new scan; Cyberlop does the comparison for you.

1. Open Recent Scans and confirm the earlier scan shows Completed. Failed and cancelled scans are not a baseline.
2. Fix the issues in your code and push the change to the branch that the target uses. White-box scans clone the latest code at launch.
3. Click ▷ Scan on the same profile. Our Run a scan guide has the details.
4. Wait for the result badge to read Completed. Use ⟳ Refresh if you left the page.
5. Open the new scan and click the Diff tab.
6. Read the three columns in this order: Regressed, New, then Fixed.
7. Open each finding from the Findings tab, set its disposition and click Update status.

What do you need before the Diff is useful?

You need at least two completed scans of the same target. The first scan has nothing to compare with, so the tab says “No previous scan to compare against.” That is expected, not an error. Keep the profile the same between runs: if you change vulnerability classes, rules or roles, a finding can vanish because you stopped looking for it.

Why does a finding show as Fixed or Regressed?

Because Cyberlop keeps one issue per real weakness per target and tracks it across scans. The in-app documentation describes the lifecycle in four rules: issues persist per target; a re-scan that no longer finds an issue marks it fixed; if it reappears it is flagged a regression; and your own dispositions are respected on later scans.

How does a finding move between states?

Why do counts differ from what you expected?

Several specialists analyse the same code, so Cyberlop merges findings that describe the same vulnerability and keeps the version with the most evidence. If agents grade one issue differently, the merged issue takes the highest severity. This is finding deduplication, and it is why one weakness is one row. Genuinely different issues that share a file stay separate.

Can a severity change show up in the Diff?

The captured screens list findings by severity badge and title only. If a finding changes severity between scans, read the finding itself for the current rating, and see Severity and confidence for how severity and confidence are kept apart.

How do you use the Diff to prove remediation?

Use it as a gate between “we fixed it” and “it is closed”. A fix is a claim until a later scan agrees with it. Cyberlop is built around a closed loop. A fix is proven by re-running the exploit against the new code, and the Diff then shows whether the re-scan still found each issue. The idea is covered in closed-loop retest and fix verification.

What routine works after each release?

1. Re-run the same profile on the branch you released.
2. Open Diff and clear Regressed first. A reopened fix usually means a revert or a second code path.
3. Triage everything in New and assign an owner. The disposition dialog also takes notes.
4. For each item in Fixed, open the finding and check the cause is your change.
5. Download a report with Fixed issues only as evidence for the work you closed. Steps are in Download PDF reports.

Where else does the comparison show up?

The Diff is one view of the same lifecycle. These pages show the result from other angles.

The API reference describes this endpoint as a diff against the target’s history, while the app labels the tab as a comparison with the previous completed scan. For a first look, trust the tab; if you build on the endpoint, test it on a staging app first.

Why do fixed findings coming back matter?

Because unpatched software flaws are now a leading way in, and remediation is slow. Verizon’s 2026 Data Breach Investigations Report says 31% of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in. A fix that quietly reverts puts you back in that group.

Speed matters too. In Verizon’s 2025 report, as reported by Infosecurity Magazine, only 54% of edge-device vulnerabilities were fully remediated, within a median of 32 days. That figure covers edge devices, not web apps. The lesson still carries over: you need a fast, repeatable way to see what is still open, and a comparison after each release is one.

How do you get a comparison on every release?

Run the profile on a schedule or from your pipeline, so every release has a fresh scan to compare. In Scheduled Scans you can run a profile Once, Daily, Weekly, Monthly, Quarterly or Yearly; see Schedule scans. From your CI/CD pipeline, the generated job starts a scan and prints the findings without failing the build. Setup is in CI/CD integration.

The scan then appears in Recent Scans with its trigger shown, and its Diff tab works like any other. Only scan applications you own or are authorised to test.

What if the Diff looks wrong?

Most surprises come from what changed between the two runs, not from the tab itself. Start with this table.

What mistakes should you avoid?

• Calling a finding closed because it left New. Look under Fixed and read the evidence.
• Changing the profile and the code in the same round, which makes the Diff hard to trust.
• Ignoring Regressed because the count is small. One reopened critical issue outweighs ten new low ones.
• Marking issues Fixed by hand before a scan agrees. Let the re-scan show it.

What should you do next?

Set up regular runs so there is always something to compare: Schedule scans is the next step. To see how Fixed and Regression states work in the triage list, read Fixed and regressed issues, and to read a single finding, Read a finding. The full path from first sign-in is in Getting started, and how it works explains the five phases behind each scan. For how we evidence findings, see evidence. Related terms: retest, finding triage and remediation.