One finding, many scanners

Vulnara runs several 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. The scanner's name is not part of it either.

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 scanners' findings 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 scanners 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:

• Scanner facet: filter the explorer to one scanner to see only what it reported.
• Triage decisions: a decision on a matched finding covers every scanner that reports it. See Triage findings.

Do it

See which scanners agree

1. Open Vulnerabilities in the web app at vulnara.rso.dev.
2. Look for the Confirmed by N tools tag on a row. Hover it to see how many scanners reported the finding.
3. Open the finding to see which scanners they were.

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, toolCount and scanners. 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
    }
  }
}

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 the scanner 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 the scanner that reported it, 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, branches and scanner only. A scanner's first scan of a repository counts everything it finds as new, even findings another scanner already reported.