How to search and filter vulnerability findings on the Issues page

The Issues page in Cyberlop is one list of every finding from every scan. Search it by title or location, narrow it with the Severity, Confidence, Class and Target filters, and use the triage chips to hide or show New, Regression, Fixed, False Positive and Accepted Risk. Click a row to open the finding and read its evidence.

What is the Issues page?

The Issues page (Issues in the sidebar, at /issues) is a single table of all findings across your scans. Its subtitle reads “All findings across scans”. Each finding is a vulnerability the scan found in one of your targets, and findings persist per target from one scan to the next. That is why the page works as a running backlog rather than a report for one run.

The scan detail page also has a Findings tab, but it shows only that scan. Use Issues when you want the whole picture: the worst problems across all targets, everything assigned to one class of bug, or all open items on a single app.

The list is sorted by severity, Critical first. Across the top sit Export JSON and Export CSV (see export findings as JSON or CSV), a search box, four filters and a row of triage chips.

Why does a filtered findings list matter?

A long list is only useful if the right items rise to the top. Attackers do not wait for a quarterly review: Verizon’s 2025 Data Breach Investigations Report says exploitation of vulnerabilities (20%) continues to be a leading initial attack vector, and that this vector saw a 34% increase. Filters exist so the serious, proven items are the first thing you see.

Access-control bugs are a good example of why class filtering helps. The OWASP Top 10 for 2021 moved A01 Broken Access Control to the top of its ranking, and reports that 94% of applications were tested for some form of it, with over 318k occurrences in the contributed data. Filtering the Issues page to the Authz class gives you that slice of your own app in one click. Read more on broken access control.

CISA keeps a Known Exploited Vulnerabilities catalogue, which it describes as the authoritative source of vulnerabilities exploited in the wild and which it says organisations should use as an input to their vulnerability management prioritisation framework. At the time of writing it listed 1,734 entries. The same idea applies on a smaller scale to your own list: separate what is proven from what is only suspected. Compare KEV catalogue and risk-based prioritisation.

How do you search and filter findings?

Search first when you know a word, then filter when you want a category. You can combine them: filters narrow the same list the search box reads.

1. Click Issues in the sidebar.
2. Type in the search box, which reads “Search findings by title or location...”. Try a word from a title, such as Injection, or part of a location, such as /api/orders or a file name.
3. Open the Severity filter and pick one level, for example Critical.
4. Open Confidence and, if you want only well-supported findings, pick High.
5. Open Class to look at one kind of bug, or Target to look at one application.
6. Set the triage chips (next section) to hide work that is already finished.
7. Click a row to open the finding.

What does each filter offer?

Table 1. The four filters on the Issues page

Filters are one choice each, so to see Critical and High together, run two passes or use the severity sort already applied to the list.

Useful filter combinations

• Release gate: Target set to the app you are shipping, Severity set to Critical, then High.
• Auth review: Class set to Authz or Auth, Confidence set to High.
• Hygiene sweep: Class set to Config to batch headers and banner fixes in one change.
• Dependency day: Class set to Dependency, then Secrets.

How do the triage chips work?

The triage chip row controls which statuses appear. It starts with a mode switch that reads Hiding ▾ or Showing only ▾, followed by five chips: New, Regression, Fixed, False Positive and Accepted Risk. Click the first chip to toggle the mode. In Hiding mode, the selected chips are removed from the list. In Showing only mode, only the selected chips are kept.

Table 2. Triage chips and what they mean

A common working view is Hiding with Fixed, False Positive and Accepted Risk selected. That leaves New and Regression items, which is the open work. Check which chips are highlighted when you first open the page, because the chips show what is currently hidden or shown.

What do the table columns show?

Each row is one finding, and the seven columns are the quickest way to decide what to open. Read left to right: how bad, what, what kind, how sure, what state, where, and in which app.

Table 3. The seven columns of the Issues table

How do you read the Location column?

The Location column tells you what kind of scan produced the finding. A value like POST /search means the issue was proven against the running app at that endpoint. A value like src/routes/orders.ts:349 means a white-box scan tied the issue to a file and line range in your repository. Both are valid, and a white-box finding may carry both a route and a code location in its detail view. For the difference between scan types, read white-box and black-box scans.

Why severity and confidence sit in separate columns

A finding can be severe but not fully proven, or minor and certain. Cyberlop keeps the two apart so you can decide for yourself. A Critical finding with Low confidence is a prompt to check the evidence, not to drop everything. The usual scale used elsewhere in the industry is the CVSS v3.1 qualitative rating: Low 0.1 to 3.9, Medium 4.0 to 6.9, High 7.0 to 8.9 and Critical 9.0 to 10.0. Cyberlop also shows Informational and Best Practice levels for items that are not exploitable flaws. See CVSS and severity versus confidence.

How do you open and act on a finding?

Click any row. The finding opens in a dialog over the list, and the address stays at /issues, so closing it returns you to the same filters. At the top are Disposition, Assignee and Update status. The Summary tab shows severity, confidence, class, status, the finding ID (a class prefix and number such as INJ-VULN-02), target, location and description. The Evidence tab shows the request, response, reproduction steps and screenshot.

1. Click the row of the finding.
2. Read the Summary: the Status field says how well it was proven, for example Confirmed.
3. Click Evidence and check the payload, request and response.
4. Choose a Disposition: Open (reopen), Fixed, False Positive or Accepted Risk.
5. Pick an Assignee, or leave it as Unassigned.
6. Add Notes and click Update status. Notes are saved with it.

The full walk-through is in how to read a finding and triage findings. After you save, the Triage column and the chips update to match.

How do you build a weekly triage routine from the list?

A routine beats a one-off clean-up. A short, fixed loop works best once the filters are familiar.

1. Set the chips to Showing only and select Regression. Anything here was fixed once and came back, so look first.
2. Switch to Showing only with New selected, then filter Severity to Critical, then High.
3. For each, open the Evidence tab and decide: real, false positive or accepted.
4. Assign real ones to an owner and add a note with the expected fix.
5. After the fix ships, re-run the scan and look at the Fixed chip to confirm it closed. See compare scans.

This follows the usual vulnerability management cycle and keeps the vulnerability backlog honest. For reports to share outside the app, see download PDF reports.

Troubleshooting: why is the list empty or too long?

Table 4. Common problems and fixes

Common mistakes to avoid

• Dismissing Low confidence findings unread. Low confidence is a prompt to open the Evidence tab, not to skip it.
• Marking False Positive without reading the request and response.
• Using Accepted Risk as a way to clear the list. Add a note saying why and who agreed.
• Reading only this page. The Issues page lists findings; the sitemap and Diff tabs show coverage and change.

Next, learn to read a finding in detail. If you want to see how a finding is proven, look at the evidence Cyberlop attaches.