One finding, many scanners

Vulnara runs several independent scanners over the same code, and a scan covers many commits. Left alone, one leaked key committed once and seen by two scanners across 26 commits would be 52 rows. Vulnara gives each finding an identity that every scanner agrees on, so the same real problem is one row, one count and one decision.

What it is for

• A findings list and a dashboard that count real problems, not scanner output.
• A Confirmed by N tools signal: a finding that several independent scanners reported is much less likely to be a false positive, so it is a good place to start triage.
• Decisions, issues and scores that follow the problem, whichever scanner reports it next time.

How it works

Each finding gets an identity built only from facts every scanner agrees on. Scanner opinions, such as severity and confidence, are never part of it, because scanners rate the same finding differently. Which scanner reported it is not part of it either. That is the whole point, and it is what lets two tools' reports collapse into one row.

Secrets and personal data

A secret is identified by the file it is in and the secret value itself. Personal data is identified by the file, the kind of data and the value. The same file written three ways by three scanners, for example with or without a leading ./, is recognised as one file.

Vulnerable dependencies

A vulnerable dependency is identified by the package and version, plus the advisory. The manifest file is left out on purpose: one scanner reads requirements.txt while another reads the lockfile for the same package.

Advisories often have several ids. One scanner reports CVE-2020-11023 and another reports GHSA-jpcq-cgw6-v4j6 for the same problem. Vulnara knows which advisory ids refer to the same advisory, from the aliases the scanners supply and from the public OSV database, and prefers the CVE id when there is one. Both findings become one.

Misconfigurations and file-level findings

A misconfiguration is identified by the file, the resource and the rule. Different scanners name their rules differently, and no public registry links them the way CVEs are linked. Vulnara keeps a reviewed table of rules from different scanners that check the same thing, and recognises findings from equivalent rules as the same finding. A rule pair that has not been reviewed yet is not merged, so two reports of the same problem may show as separate rows until it is.

Across commits and repositories

The identity does not include the commit or the branch, so a finding present in many commits is one row, with the Occurrences column showing how many raw findings it collapsed. The identity does not include the repository either, but Vulnara always counts and decides per repository: the same secret committed to two repositories is two findings, one in each.

Severity when reports disagree

When the scanners that reported a finding give it different severities, Vulnara shows the highest. Showing a critical issue as low could mean it is never looked at.

What you can set

Matching is automatic. There is nothing to configure. What you control is how you use the result:

• Category facet: filter the explorer to one kind of problem: SAST, SCA, secrets or personal data.
• Triage decisions: a decision on a matched finding covers every scanner that reports it. See Triage findings.

Do it

Find the corroborated findings

1. Open Vulnerabilities in the web app at vulnara.rso.dev.
2. Look for the Confirmed by N tools tag on a row. It tells you how many independent scanners reported the finding.
3. Start with the highest N at the highest severity: those are the findings least likely to be wrong.

The dashboard also shows how many open findings were confirmed by two or more scanners, and lists them. See Security posture dashboard.

Read it through the API

• GraphQL: scanFindingMatchGroups returns one row per real finding with its occurrences and toolCount. findingCorroboration returns, for one repository, each matched finding with the number of scanners that reported it and its reconciled severity, most strongly corroborated first.
• MCP (read only): scan_finding_match_groups and finding_corroboration.

query {
  findingCorroboration(repositoryId: "<repository id>") {
    items {
      matchHash
      toolCount
      severity
    }
  }
}

toolCount is the corroboration signal. There is no field that names the tools behind it.

Good to know

• Confirmed by N tools counts distinct scanners. One scanner reporting the same finding many times is still one tool.
• Some findings cannot be matched. A secret whose value was redacted, a dependency with no advisory id, or a misconfiguration with no rule id has no shared identity. These findings still appear in the explorer, as their own rows. A decision on one applies only to that report rather than to every report of the same problem, and the triage dialog tells you when that is the case.
• Matching only ever adds links between advisory ids. Learning a new alias can merge two findings that were separate, never split one.
• A scan's count of new findings compares it with the previous successful scan of the same repository and branches by the same scanner. The first time a scanner sees a repository it counts everything it finds as new, even findings already reported by another.