# Working findings

The Findings page turns reports from your security data into a list you can investigate and assign. This guide explains grouping, sorting, evidence and the steps from a new finding to a verified fix.

## Start with the right scope

Use the source, target, owner team and severity filters. Search for a title, CVE, package or target, then press Enter or leave the search field to apply it. Results load 25 at a time; opening a group loads its findings separately.

Choose **Show** according to the question you have:

| View | What one row represents |
| --- | --- |
| Grouped by fix | A proposed change that addresses several findings |
| Grouped by vulnerability | A CVE, or a shared title where there is no CVE |
| Every finding | One report on one target |

These totals are different units. Three fix groups can represent dozens of findings. Use vulnerability grouping to see spread, and fix grouping to plan the work.

## How sorting works

**Most urgent first** puts breached deadlines first, then higher severity and the earliest deadline. You can also sort by severity, age, or, for groups, size. EPSS contributes a separate exploit-likelihood flag; it does not replace this ordering.

A source severity label drives the app's deadline. Read [Vulnerabilities and scores](/docs/secops/vulnerabilities) before interpreting CVSS or EPSS as a priority on their own.

## Open the evidence

An open finding shows its source, target and remediation information, with CVE, weakness, package, fixed-in version, CVSS, EPSS, first discovery and scan-count details when available.

Check which version and target the report describes. A fixed-in version is an advisory's remediation clue, rather than evidence that you have deployed that version. A scan count is the number of observations supplied by the data, not necessarily the number of independent tools confirming the issue.

Follow the remediation workstream to see related work. [Remediation](/docs/secops/remediation) explains why one fix can clear several findings.

## Update the work status

The **Update** box offers:

- **New:** recorded but not yet worked through.
- **Triage:** being assessed for relevance, impact and ownership.
- **In progress:** remediation work is under way.
- **Risk accepted:** a documented, temporary decision to keep a real risk.
- **False positive:** a documented, temporary decision that the report does not apply.

Updates are saved for other readers immediately. Derived counts can still reflect the previous model until the next daily run, and the screen can say the latest update is not in reports yet.

Exceptions need a reason and a future recheck date. See [Risk acceptance and false positives](/docs/secops/exceptions) before choosing one.

## What makes a finding fixed?

There is no manual **Fixed** option. The source's non-open state causes SecOps to count it as fixed. Making a code change or closing a Jira ticket alone does not establish that the scanner's issue is resolved.

After remediation, let the source scan or report the new state, then let SecOps read it. If it remains open, check the deployed version, scan freshness and source status before dismissing it.

## A repeatable triage

1. Confirm the source, affected target and report details.
2. Read severity, exploit evidence and [deadline](/docs/secops/deadlines).
3. Confirm the [owning team](/docs/secops/ownership).
4. Identify the fix group and request a [Jira ticket](/docs/secops/tickets), or record an appropriate exception.
5. Verify the source reports the issue resolved after the fix.