Triage findings

Every scan produces findings: code issues, leaked secrets, exposed personal data and vulnerable dependencies. The Vulnerabilities explorer lists them across all your repositories, one row per real problem, and lets you record a decision about each one so nobody has to work it out again.

What it is for

• Seeing what is open right now, worst first, without counting the same problem once per commit and once per scanner.
• Recording why a finding does or does not need work, so the decision is visible to everyone who looks at it later.
• Keeping false positives and accepted risks out of your working list, while being clear about which of those still count against your security score.

How it works

One row per real problem

Vulnara scans every commit it is asked to, and several scanners often report the same thing. The explorer collapses these into one row. The Occurrences column shows how many raw findings were folded into the row, and is left empty when there is only one. When more than one scanner reported the same finding, the row carries a Confirmed by N tools tag. See One finding, many scanners for how this matching works.

The explorer has two finding types, chosen in the facet rail under Type:

• Code & Secrets: code findings, secrets and personal data, with severity, confidence, scanner, file, line, the matched text, the decision and the occurrence count.
• Dependencies: vulnerable libraries, sorted by severity with the worst first. Each library appears once per repository it is vulnerable in, and its occurrence count is the number of distinct advisories against it. The same library in two repositories stays two rows, because a decision, an issue and a fix are all per repository.

Severities

Findings use the severities Critical, High, Medium, Low, Info and Unknown. When scanners disagree about the same finding, Vulnara shows the highest severity any of them reported. An unrecognised or missing severity counts as Unknown, the lowest.

Decisions

A decision is stored against the finding's identity in its repository, not against a single row. It survives rescans, and it covers every scanner that reports the same thing. If a finding has no cross-tool identity, the decision applies only to the scanner that reported it, and the triage dialog says so.

The decisions you can record:

• False positive: the scanner was wrong, this is not a real finding.
• Not affected: a real advisory, but this code cannot be reached or exploited here. Offered for dependency findings only, and needs a justification.
• Already dealt with: it was real and has been handled, for example a leaked key rotated or a fix already shipped.
• Will not fix: real and still exposed, and you are choosing to carry it.
• Defer: real and still exposed, just not this cycle.

A decision's tag tells you whether it changes the score:

• Clears score: false positive, not affected and already dealt with. The finding leaves the open list and the security score, because the decision says the risk is not real.
• Keeps score: will not fix and defer. The finding leaves the open list but still counts against the security score, because the risk is still there.

History

Every decision and every reopen is appended to the finding's history with who made it and when. Nothing in the history is edited or deleted. In the finding drawer, N earlier decisions expands the history.

Masked secrets

The matched text of a secret or code finding is always masked: only the first and last few characters are shown, and the mask has a fixed width so it does not reveal the value's length either. A workspace admin can reveal the raw value from the finding with Reveal secret. Every reveal is logged with the user, the repository and the finding.

What you can set

• Decision: one of the five decisions above.
• Justification: required for Not affected. Choose from the standard reasons, such as "The vulnerable code is not present" or "Covered by a mitigating control".
• Review by: required for Will not fix and Defer. Defaults to 90 days out.
• Reason (optional): free text shown to anyone reviewing the finding later. Left empty, the decision records that no reason was given.
• Facets: filter the explorer by Severity, Period (last 24 hours, 7, 30 or 90 days, all time, or a custom date), Issue (open, closed or no issue), Decision and Scanner, and by repository.

The Decision facet offers:

• Not decided: nothing recorded yet.
• Any decision: anything recorded.
• Dismissed: false positive, not affected or already dealt with.
• Deferred or won't fix: kept out of the working list but still scored.
• Each individual decision: False positive, Not affected, Already dealt with.

Do it

Find what needs attention

1. Open Vulnerabilities in the web app at vulnara.rso.dev.
2. Pick Code & Secrets or Dependencies under Type.
3. Narrow with the facets. Selecting an active facet again removes it, and Clear resets every filter while keeping the type.
4. Select a row to open the finding drawer.

The filters are kept in the page URL, so you can share a filtered view by copying the address. From the finding drawer, Copy a link to this finding copies a link that reopens the explorer filtered to that one finding, and Copy the finding as text copies its severity, location, scanner, match and links.

Record a decision

1. Open the finding and choose Triage.
2. Pick a decision, add a justification or review date if asked, and optionally a reason.
3. Choose Save decision. The button stays disabled until the decision can be saved.

To apply the same decision to several findings, select them in the table and use the bulk triage action. If some fail, the result says how many of the selection were saved.

To undo a decision, open the finding and choose Reopen. The finding returns to the open list and a reopen entry is added to its history.

Reveal a masked secret

1. Open the secret finding.
2. Choose Reveal secret. The dialog reminds you that the reveal is logged.

Do the same through the API

• GraphQL: scanFindingMatchGroups, scanFindings, scanFindingGroups, repositoryDependencyScanFindingGroups, repositoryDependencyScanFindings, findingTriage, findingTriageHistory, setFindingTriage, clearFindingTriage and revealScanFindingMatch.
• CLI: scan_findings and repository_dependency_scan_findings.
• MCP (read only): scan_finding_match_groups, scan_findings, repository_dependency_scan_finding_groups, finding_triage and finding_triage_history.

setFindingTriage and clearFindingTriage take the repository id and the finding's match key. The match key is the finding's matchHash, or its per-scanner fallback when it has none; the grouped listings return it as triageKey. findingTriageHistory returns every decision on a repository, newest first, and narrows to one finding when you pass matchKey.

mutation {
  setFindingTriage(
    input: {
      repositoryId: "<repository id>"
      matchKey: "<triageKey>"
      findingType: "code"
      state: false_positive
      reason: "Test fixture, not a real credential"
    }
  ) {
    state
    createdBy
    createdAt
  }
}

Good to know

• Recording or clearing a decision needs the Editor role. Viewers can read decisions and their history. Revealing a secret needs the Admin role. See Teams and roles.
• A new decision on the same finding replaces the current one. The earlier one stays in the history.
• If saving a decision fails, the finding keeps its previous decision and an error is shown.
• An empty list tells you why it is empty: active filters, a scan still running, no repositories, nothing scanned yet, only some repositories scanned, or genuinely clean.
• The dashboard reports dismissed and deferred findings next to the open total rather than subtracting them, so the total does not shrink just because someone dismissed a finding. See Security posture dashboard.
• Advisory ids link out: a CVE- id opens its NVD page and a GHSA- id opens the GitHub advisory. Source links open the finding's line, including in files the host would otherwise render, such as Markdown or notebooks.
• From a repository finding you can also use Request Consultation to ask Vulnara's security experts for help understanding and resolving it.