Severity vs confidence in Cyberlop: how to read and prioritise findings

Severity is how bad a finding would be if it is real. Confidence is how sure Cyberlop is that it is real. In Cyberlop, every finding carries both: one of six severities (Critical, High, Medium, Low, Informational, Best Practice) and one of three confidences (High, Medium, Low), plus a status of Confirmed, Likely or Unconfirmed that says how well it was proven. Read them together, then decide what to fix first.

What is the difference between severity and confidence?

Severity measures impact. Confidence measures proof. They answer two different questions, which is why Cyberlop shows them in separate columns instead of folding them into one score. The severity vs confidence term page gives the short definition; this guide shows how to use both in the app.

A finding can be serious and doubtful, or minor and certain. Treating the two as one number hides both cases. A Critical finding with Low confidence is a lead worth checking today. A Low finding with High confidence is a safe item to schedule.

Why not use one score?

A single score forces a trade-off that only your team can make. The standard scoring system, CVSS, is explicit about this: its user guide says Base scores measure severity and "should not be used alone to assess risk". Cyberlop follows the same idea. Severity is one input, proof is another, and your own context (which app, which data) is the third. See also CVSS and risk-based prioritisation.

The captured app does not show how Cyberlop derives a severity, so this guide does not claim a mapping to CVSS ranges. For reference only, CVSS v4.0 rates scores 9.0 to 10.0 as Critical, 7.0 to 8.9 as High, 4.0 to 6.9 as Medium and 0.1 to 3.9 as Low, per the FIRST specification.

What are the six severity levels in Cyberlop?

Cyberlop uses six severity levels, from Critical down to Best Practice. They appear as coloured badges in the Issues list, the scan Findings tab, the Dashboard and the report. The Issues list sorts Critical first.

The "typical first move" column is a suggested starting point, not a rule from the app. Your own service levels come first; the remediation SLA page explains how teams set them.

When agents disagree on severity

Cyberlop's documentation says that if its agents grade the same issue differently, the merged issue takes the highest severity of the group. That leans towards caution: you may see a finding graded higher than one agent's first view, but never lower than any of them.

What are the three confidence levels, and what do Confirmed, Likely and Unconfirmed mean?

Confidence has three levels, High, Medium and Low. Separately, each finding has a status that says how strongly it was proven. Per the in-app documentation, findings are graded confirmed, likely or unconfirmed based on how strongly they were proven.

Proof matters because it removes argument. When a finding carries the payload, the HTTP request, the HTTP response and a screenshot, an engineer does not have to decide whether to believe it. If a scan ran with the exploitation phase off, nothing can be demonstrated against the live app; the exploitation phase guide explains the trade-off. For the wider idea, see proof of exploit.

Where do you see severity, confidence and status?

1. Click Issues in the sidebar.
2. Read the Severity badge and the Confidence column on each row. Low confidence is shown dimmed.
3. Click a row to open the issue dialog.
4. On the Summary tab, read the severity badge, Confidence, Class, Status and the finding ID, for example INJ-VULN-02.
5. Open the Evidence tab to see what backs the status.

The same columns appear on the Findings tab of a scan, described in the scan detail page guide.

How do you prioritise findings using severity and confidence?

Read in this order: high severity with high confidence first, then high severity with low confidence, then the rest. This order puts proven, serious findings in front of an engineer before anything speculative.

A four-bucket reading order

Low-confidence Critical findings are not noise. In a typical list you may see business-logic findings graded Critical with Low confidence, because logic flaws such as a cron job without an idempotency guard are harder to prove from outside than an injection. Check them, but check them with a person who knows the workflow. The business-logic flaw page explains why.

How do you filter the list this way?

1. Open Issues.
2. Set the Severity filter to Critical, then read every row.
3. Change the Confidence filter to High to see the proven set, then to Low to see the set that needs checking.
4. Repeat with High severity.
5. Use the triage chips to hide statuses you have already decided, such as Fixed and Accepted Risk.

The issues list guide covers search, the four filters and the chips in full. The same filters exist in the API: GET /api/issues accepts severity, confidence, vulnClass and triageStatus, so a pipeline can pull the same views.

Pair the reading order with triage

After each pass, record a decision. Set the Disposition, choose an Assignee, add a note and click Update status, as shown in triage findings. A finding you mark Accepted Risk or False Positive keeps that state across later scans; see risk acceptance and false positive.

How can you set a minimum severity and confidence for reports?

Use the report filters in a scan profile. Under Reporting, Minimum severity offers No minimum, Critical, High, Medium, Low, Informational and Best Practice, and Minimum confidence offers No minimum, High, Medium and Low. The documentation says the final report is filtered by these values and any reporting guidance.

Start with No minimum while a target is new, so you see everything and learn what your app produces. Tighten later for executive reports. Filtering is a reporting choice, not a verdict: a finding below your threshold is simply left out of that report. Read reporting rules for the other fields on that section.

Where else do severity counts appear?

Severity drives four other places in the app, so a consistent reading helps everywhere.

• Dashboard: the Findings by severity card shows bars for all six levels, and Top vulnerable targets shows "N critical/high" per target. See dashboard overview.
• Targets list: severity dots in the Results column.
• Scan Overview: a severity breakdown with the results donut.
• Email: in My Account, a checkbox sends mail when a scan finds critical or high issues.

Why does the number of exploited vulnerabilities matter?

Attackers reuse what already works. In its 2025 report, Verizon says exploitation of vulnerabilities as an initial attack vector saw a 34% increase. CISA's Known Exploited Vulnerabilities catalog lists 1,734 vulnerabilities as exploited in the wild at the time of reading, and the 2026 edition of the DBIR page leads with "31% of breaches now start with software vulnerabilities".

That is why proof counts. A queue where each Critical or High finding is already demonstrated lets a team spend its week fixing, not arguing. The KEV catalog and EPSS, which FIRST describes as a model that estimates the chance a published CVE will be exploited in the wild within 30 days, are useful outside signals for known library flaws; they sit beside Cyberlop's own proof, they do not replace it.

What are the common mistakes when reading severity and confidence?

Troubleshooting a confusing finding

Mistake: ignoring everything below Critical

A High finding with a screenshot and a reproduction step is often cheaper to fix and as risky to your customers as a doubtful Critical. Look at both columns before you drop anything.

Mistake: closing Low confidence findings without reading them

Low confidence means "not proven", not "not real". Read the Description and, for white-box findings, the file and line in Location. If you decide it is wrong, choose False Positive and write why.

Mistake: treating Informational and Best Practice as noise

They are lower in the list, not absent from your risk. A server banner that names an exact version helps anyone choosing an exploit. Batch them; do not delete them.

What should you do next?

Next step: download PDF reports, where the filters above decide what lands in the document. Before that, read a finding end to end and see how fixed and regressed issues change a finding's state when you rescan. Why Cyberlop reports only what it exploited is explained on the evidence page and, with its limits, on honest.