Skip to content
Security

Findings

Severity, proof state, file and line information, and how to work through a finding.

What a finding containsPermalink to What a finding contains

A finding describes one issue: what it is, how serious it is, how well it is evidenced, and where in the repository it was found. Where the location is known, the finding names the file and the line.

Where this happens in the console

SeverityPermalink to Severity

Findings are ranked by severity, most severe first.

SeverityHow to treat it
CriticalAddress first.
HighAddress promptly.
MediumSchedule remediation.
LowFix when convenient.
InformationalNo action implied; context only.
UnknownSeverity could not be determined — judge it on its content.
Severity levels, in the order the console sorts them.

Proof statePermalink to Proof state

Severity says how bad an issue would be. Proof state says how confident the scan is that the issue is real. Read them together — a critical finding that is unconfirmed is a lead, not a conclusion.

Proof stateWhat it tells you
ConfirmedThe finding is supported by evidence gathered during the scan.
Needs validationThe finding is plausible but was not confirmed. Verify it before acting.
UnconfirmedThe finding was not established. Treat it as a lead to investigate.
Proof states.

Proof state is not severity

The two are independent. Sorting by severity alone will put unconfirmed leads above confirmed lower-severity issues, so check both columns before deciding what to work on.

Deciding what a finding isPermalink to Deciding what a finding is

Every finding starts as open. You can record what you decided about it, and that decision changes what your workspace counts as confirmed. The decision belongs to the workspace, not to you personally — everyone with access sees it.

DecisionWhat it meansEffect on your confirmed findings
OpenNot yet decided. This is where every finding starts.Counted
Not a real issueYou looked and this is a false positive.Removed from your confirmed findings and severity summary
Accepted riskReal, and you have decided to live with it.Kept, marked as a decision you made
IgnoredNot something you intend to act on.Removed from your confirmed findings and severity summary
FixedYou believe it is resolved.Kept, marked as resolved — re-scan to confirm
The five decisions, and what each one does to your counts.

Two of the five change your numbers

Marking a finding “not a real issue” or “ignored” takes it out of the confirmed findings list and out of the severity summary. That is the point of those two decisions, and it is why the console states the consequence next to each one before you choose.

Marking something Fixed does not verify it. Only a new scan against the changed code can do that, which is why the decision is kept in your findings rather than removed.

Every change is recorded with who made it and when, and the finding shows that history. In an organization, changing a decision requires the owner or admin role; other members can read the decision and its history but not change it.

Where this happens in the console

Working through findingsPermalink to Working through findings

  1. Start with confirmed and severe

    Findings that are both high-severity and confirmed carry the most information per minute spent.

  2. Open the location

    Use the file and line to read the surrounding code before judging the finding.

  3. Validate what needs validating

    For anything not confirmed, reproduce it before you change code.

  4. Record what you decided

    Mark a finding as a false positive, accepted risk, ignored or fixed so the next person does not re-investigate it.

  5. Re-scan after changes

    A new scan reflects the current state of the branch, and is the only thing that confirms a fix.