Understand findings

Outcome

You can read a repository's Findings tab: what a deduped finding is, how severity and evidence are scored, what each status badge means, and which findings need a decision from you.

Who can do it

• Customer — sees repositories in their own GitHub namespace.
• Organization member — sees only repositories an owner placed in their scope; viewing findings needs no cost capability.
• Site admin — sees every repository.

Reading findings is a view-only activity. Acting on them (acknowledge, reject, patch) is covered in Acknowledge true positives or reject false positives and gated by separate capabilities — see Roles and permissions.

Before you begin

• At least one scan has completed for the repository — see Run a security scan.
• You are signed in and the repository appears on your Attack Surface page (/byos).

Steps

1. Open Attack Surface (/byos) and select the repository. The repository page opens on the Findings tab, titled Deduped Findings.
2. Read one row as one deduped finding group: prpl groups occurrences of the same weakness (same CWE, file, line, and summary) that were found across scans. A ×3 · 2h chip means the group was seen 3 times across 2 scans; rows seen only once carry no chip.
3. Read the Status column:
   • needs review — validated evidence is waiting for your true-positive / false-positive decision.
   • defend ready — acknowledged (or auto-confirmed) and eligible for Defend patch generation.
   • defend running — a patch generation run is in flight.
   • defended — a patch was generated and evaluated.
   • confirmed — a real vulnerability; patching is on hold or already handled elsewhere.
   • false positive — a reviewer rejected the finding.
   • candidate — surfaced but not validated; no action needed yet.
   An env change chip means the scan asked for an environment adjustment before it can prove the finding.
4. Read severity from the colored CVSS tile — the worst CVSS score across the group's occurrences: 9.0+ critical, 7.0–8.9 high, 4.0–6.9 medium, below 4.0 low. A NEW badge marks a confirmed finding that first appeared in the latest scan.
5. Use the filter chips above the table (click a chip to filter): all, confirmed, new, needs review, defend ready, defended. Each chip shows its count.
6. Open a finding by clicking its status badge or its finding id. The scan run page shows the evidence for that occurrence: the proof-of-concept files, the transcript, and the verdict panel.
7. Read confidence from the verdict panel: a validation state (D0–D5), the decision, an evidence level, and a rubric score out of 100 with a per-criterion scorecard and negative controls. The review panel summarizes this as evidence: strong (D4·E3) — strong means D4/D5, moderate D2/D3, weak below.

Verify

• You can state, for each row, why it has its status and what (if anything) it is waiting on.
• Clicking a needs review badge lands on the finding's evidence with a human review panel showing pending.
• The filter chip counts add up against the rows you see.

Troubleshooting

• "No validated hunt findings have been recorded for this repository yet." — no scan has completed. Start with Run a security scan.
• A finding you expect is missing — it may be archived. Click Include archived (N) above the table; archived rows render dimmed with an archived chip. See Archive scans, findings, and history.
• Rows look stale after acting elsewhere — reload the repository page; statuses are recomputed from the latest scan results on each load.
• Two repositories show the same finding — groups are per-repository; check you are on the right repository and environment filter.

Next steps

Decide on the pending rows: Acknowledge true positives or reject false positives. For the full picture of where findings sit in the pipeline, see the Scan and finding lifecycle.