Findings

A finding is something a person should look at: a weakness in code, or activity in the audit log or a log store. Code findings come from code assessments and from the security comments of merge request reviews. Log findings come from investigations, including those opened by hunts and alerts. All of them are kept in one list on the Findings tab, de-duplicated, and each is reasoned only: argued by a model from what it was shown, and read by a person before anyone acts on it.

Who can do what

Role	Code findings	Log findings
Admin	Read, dismiss, open again, export	Read, dismiss, open again
Builder	Read, dismiss, open again, export	Not shown
Auditor	Read, export	Read
End user, Reviewer	Cannot open the page

Log findings quote the audit log and your logs, so only the roles that read the audit log see them.

What you see

Summary. Open findings: n, and a tag per severity with its count.
A reminder that every finding is reasoned only, so a person checks one before acting on it.
Filters. Search findings, Status (Open, Dismissed, or Open and dismissed), Severity (Any severity, Critical, High, Medium, Low, Information) and Source (Every source, or one repository). Export SARIF exports the code findings the filters keep; see Exports.
The list, most severe first:

Column	What it shows
Severity	Critical, High, Medium, Low or Information: how bad a successful exploit, or the activity if malicious, would be.
Finding	Its title.
Source	The repository, for a code finding; the log source’s name, or Audit log, for a log finding.
Where	The file and lines, or the subject: an account, an address, a key, an object or a host.
Last reported	When an assessment, review or investigation last reported it.
Status	Open or Dismissed.

The list shows the 500 most severe findings that match. Above that, the page says so: filter by severity to see the rest, or export them.

Open a finding

Select a finding. Its page replaces the tabs and shows:

Section	Code finding	Log finding
Header	Title, severity, confidence (High, Medium or Low confidence), Reasoned only, and Dismissed if it is.	Title, severity, Reasoned only, and Dismissed if it is.
Where	Repository, Location (file and lines), In (the function or type), Weakness (the CWE), Open in the host, and Show in the repository’s graph.	Source, About (the subject), Between (the first and last event), Events (their ids) and Technique (a MITRE ATT&CK id, when named).
Why	Why it may be exploitable: the model’s argument from the code.	What the events show, and what an attacker gains if it is malicious.
Evidence	The code: the lines, from the index.	The events: the rows the model was shown, from the source.
Suggested fix	When the model gave one.
History	First reported, Last reported, First found by (an assessment, a merge request review or an investigation, linked), Reported by (the model), and the dismissal.	The same.

Evidence is always taken from the index or the source, never from the model’s text.

Dismiss a finding

Dismiss a finding that is not reachable, a false positive, or an accepted risk.

Open the finding and select Dismiss.
Under Why it is dismissed, write the reason, for example “not reachable from outside” or “a false positive because…”. A reason is required, at most 1,000 characters.
Select Dismiss.

The finding stays dismissed when later assessments, reviews or investigations report it again; Last reported still moves. The reason, who dismissed it and when are kept with it and in the audit log. To undo, open it and select Open it again.

How findings are de-duplicated

Two reports are one finding when they describe the same thing:

Code: the same file, the same weakness class (the CWE, or the title when there is none) and the same function or type (or, outside one, the same first line). Line numbers move between commits; a function’s name does not.
Log: the same source, the same subject, and the same ATT&CK technique (or the title when there is none).

A repeat updates Last reported and is counted as seen before by the assessment, review or investigation that reported it.