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 that reported it.
• 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 four finding types, chosen in the facet rail under Type:

• Code & Secrets: code findings, secrets and personal data, with severity, confidence, the number of tools that agree, category, file, line, the matched text, the decision and the occurrence count. A row can gather reports from several scanners that do not always agree on the category, so the Category column lists every category the row's reports carry. It has no filter of its own; use the Category facet to narrow the list.
• 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.
• Network: the open ports found by network scans, narrowed by network instead of repository. Network findings take no decisions.
• Web application: the findings of web application scans, with the check that matched, its severity, the URL it matched at, its CVE and CWE identifiers and the web application, narrowed by web application. Opening one shows its description, references, matched URL and what the check extracted. You record decisions on them as on code findings, kept per web application, and a finding without a match identity cannot be triaged.

Exploited tags

A dependency or web application finding whose CVE is in the CISA Known Exploited Vulnerabilities catalogue carries a KEV tag; its tooltip names the CVE, whether it is used in ransomware, CISA's due date and the EPSS probability. One that is not in KEV but has an EPSS probability of 10% or more carries an EPSS tag with that probability. The tags show in the explorer, a scan's dependencies, a repository's vulnerable dependencies and the finding drawers. A library row takes the strongest signal of its advisories. Code and secret findings carry no tag. See Actively exploited findings.

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 that one report rather than to every report of the same problem, and the triage dialog says so.

The decisions you can record:

• False positive: the finding is wrong, this is not a real problem.
• 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, Category, Period (last 24 hours, 7, 30 or 90 days, all time, or a custom date), Issue (open, closed or no issue) and Decision, and by repository.

The Category facet lists the categories your workspace may run: Code analysis, Dependencies, Secrets and Personal data for code and dependency findings, and only Web application for web application findings. It matches each finding's own category, not the categories of the scanner that reported it, and it narrows the facet counts as well as the list. A finding recorded before categories existed has none and is not matched by any category. See Scan categories.

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, Dependencies, Network or Web application 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. A filter that arrives in a link but has no facet showing it is shown as a chip you can remove. 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, confidence, repository, location, match, occurrence count, first-detected time and links. Neither names the scanner that reported the finding.

A link from a scan to its findings narrows the explorer to that scan. An older link that narrowed to a scanner instead is no longer applied: the explorer shows the wider list and a chip saying the link is out of date, which you can remove.

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. For web application findings: dastFindings, setDastFindingTriage, clearDastFindingTriage and dastFindingTriageHistory, keyed on the web application and the finding's matchHash.
• CLI: scan_findings and repository_dependency_scan_findings.
• MCP: scan_finding_match_groups, scan_findings, repository_dependency_scan_finding_groups, finding_triage and finding_triage_history, and set_finding_triage and clear_finding_triage for members whose AI access is Write. Web application findings are readable through dast_findings but cannot be triaged by an AI client.

To filter by category through the API, pass { field: "category", categoryEquals: SECRETS } in filters; one category per query. In the CLI, use --filters category=secrets.

setFindingTriage and clearFindingTriage take the repository id and the finding's match key. The match key is the finding's matchHash, or its single-report 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.
• Your workspace can require an accepted risk for Will not fix. The decision is then refused unless an accepted risk in the risk register links the finding, and its review date cannot be later than that acceptance's expiry. The dialog names which of the two applies.
• A Will not fix or Defer decision ends on its review date: the finding returns to the open list. The risk register's Exceptions tab lists the decisions in force and when each one ends.
• Add to risk in the finding drawer links a code, dependency or web application finding to a risk. See Risk register.
• 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 on the repository's own provider, GitHub, GitLab, Bitbucket, Azure DevOps or Codeberg / Forgejo, and on GitHub and GitLab also 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.