Confidence Tiers
Not all vulnerability findings are created equal. ScanRook assigns a confidence tier to every finding based on the strength of evidence that the vulnerable package is actually installed and active. This helps teams focus triage effort on findings that matter most.
The two tiers
Every finding is classified as one of two confidence levels.
The package was verified as installed through a system package manager database or ecosystem lockfile. ScanRook has high confidence that the vulnerable version is present and active in the scanned artifact.
Action: These findings should be triaged with priority. The vulnerable package is confirmed to be present.
The package name and version were inferred from filename patterns or binary metadata. ScanRook found indicators that the package may be present, but cannot confirm it is installed or linked.
Action: Review these findings with additional context. They may represent source archives, build dependencies, or version strings that do not correspond to the installed runtime state.
Evidence sources
The evidence source determines which tier a finding receives.
InstalledDbConfirmedInstalledPackage was found in a system package manager database (RPM db, APK installed, DPKG status). This is the strongest evidence: the package manager confirms the package is installed at that exact version.
Example paths: /var/lib/rpm/Packages, /lib/apk/db/installed, /var/lib/dpkg/status
RepoMetadataConfirmedInstalledPackage was found in a language ecosystem lockfile or manifest that confirms installed versions (package-lock.json, Gemfile.lock, go.sum, Cargo.lock).
Example paths: /app/node_modules/.package-lock.json, /app/Cargo.lock
FilenameHeuristicHeuristicUnverifiedPackage name and version were inferred from a filename pattern (e.g. openssl-1.1.1k.tar.gz). The file exists but ScanRook cannot confirm the software is actually installed or linked.
Example paths: /usr/src/openssl-1.1.1k.tar.gz
BinaryHeuristicHeuristicUnverifiedPackage name and version were extracted from binary metadata (ELF notes, Go build info, PE version resources, Rust panic strings). The binary exists but the version string may not exactly match a distribution package.
Example paths: ELF .note section, Go buildinfo embedded in binary
Why this matters
Confidence tiers are the primary mechanism for false positive reduction.
Traditional vulnerability scanners report every version string they find, regardless of whether the software is actually installed. This leads to noisy reports where build-time dependencies, cached source archives, and version strings embedded in documentation appear as findings.
ScanRook's installed-state-first approach solves this by prioritizing evidence from package manager databases and lockfiles. When ScanRook finds a package in the RPM database or in a package-lock.json, it knows that package is genuinely installed. When it only finds a version string in a filename, it flags it as heuristic so teams can decide whether to investigate.
In practice, this means:
- ConfirmedInstalled findings require attention -- the vulnerable package is verifiably present
- HeuristicUnverified findings may be noise -- they warrant a second look before creating remediation work
- CI/CD gates can be configured to fail only on ConfirmedInstalled critical/high findings, reducing alert fatigue
How it appears in JSON reports
Each finding includes a confidence field and an evidence array.
{
"cve": "CVE-2024-12345",
"package": {
"ecosystem": "npm",
"name": "lodash",
"version": "4.17.20"
},
"severity": "HIGH",
"cvss": 7.5,
"confidence": "ConfirmedInstalled",
"evidence": [
{
"source": "InstalledDb",
"path": "/app/node_modules/.package-lock.json"
}
],
"fixed_in": "4.17.21"
}{
"cve": "CVE-2023-67890",
"package": {
"ecosystem": "Generic",
"name": "openssl",
"version": "1.1.1k"
},
"severity": "MEDIUM",
"cvss": 5.3,
"confidence": "HeuristicUnverified",
"evidence": [
{
"source": "FilenameHeuristic",
"path": "/usr/src/openssl-1.1.1k.tar.gz"
}
],
"fixed_in": "1.1.1l"
}