Comparing scanner results to the Minimus vulnerability report
The primary goal and focus of Minimus vulnerability reports is the quality of the results. Minimus emphasizes the accuracy of its vulnerability reports over volume, following the conviction that quantity should not be the primary driver in vulnerability reporting.Given that each vulnerability scanner has its unique workings, it can seem difficult to compare results across scanning tools. Becoming familiar with scanner defaults can help demystify the results. Following is a discussion of key points to keep in mind when reviewing Minimus vulnerability reports.
This depends on how you count vulnerabilities. There are different methods:
Unique CVEs - If a CVE affects more than one package in the image, you still count it as one vulnerability.
Affected packages - In this method, you count the number of packages affected by each CVE. This method is also known as counting findings or counting unique issues per dependency path.
Minimus vulnerability reports count each unique CVE once, regardless of the number of affected packages. To be clear, the image vulnerability report in Minimus will list all affected packages, it just won’t count them separately.
This depends on how you identify vulnerabilities. There are different systems for cataloging vulnerabilities, each with their pros and cons.
Normalizing to CVE ID - This approach favors the CVE (Common Vulnerabilities and Exposures) database run by the MITRE Corporation. This means the report will identify vulnerabilities by their CVE ID whenever possible. The only times you might identify a vulnerability by another database, is if it was never mapped to a CVE. This method has the advantage of deduplication.
Original data source feed - Here vulnerabilities are identified by the original data source. For example, the Grype scanner maps language packages to a GHSA ID (GitHub Security Advisory) by default (ref).
Minimus normalizes its vulnerability reports by CVE ID. You will still see GHSA IDs when they have not yet been mapped to a CVE.
This depends on your tolerance for “noise”. There are competing approaches:
Filter out unconfirmed vulnerabilities - to minimize questionable reports
Report all programmatic findings - even if unconfirmed or disputed
Minimus vulnerability reports filter out vulnerabilities still under review. The Minimus advisory will show the potentially affected package and the status under review, but it will not be mapped to an image until it has been confirmed. This approach suppresses noise and avoids unnecessary strain.
A vulnerability NVD listing may show competing severity scores. In such cases, an “operative” score must be selected. There are different approaches:
Preferred - This approach adopts an internal logic for ranking scores by the CVSS version used and the reputation of the reporting CNA - CVE Numbering Authority (ref). This approach favors CVSS 4 scores over CVSS 3.1 and makes use of NVD’s ranking of CNAs based on auditing results. The severity promoted by NVD as most reputable is adopted.
Highest severity - This approach ignores the priority of CVSS 4 over CVSS 3 and does not weigh in the ranking of the reporting CNA.
NVD assigned score - This approach strictly adheres to the score provided by NVD and disregards scores provided by other recognized CNAs and CISA-ADP scores. This approach may be attributed to FedRAMP’s directive to use NVD assigned CVSS scores as the “original risk rating” (FedRAMP Rev5 Vulnerability Scanning Requirements). However, this approach has not been widely adopted and has the downside of registering many vulnerabilities as having unknown severity unnecessarily.
Minimus advisories show the preferred severity as recommended by NVD. This approach has the advantage of suppressing noise, especially when the highest severity score is less trustworthy.
Minimus only counts OS-level packages (APK format) in its SBOM and vulnerability reports. Some scanners will show a higher package count because they include non-OS dependencies. This explains why the package count may not match between different scanner reports.
Some scanners count the number of different layers a CVE affects. Minimus images are always built as a single layer, without a Dockerfile. Therefore, there should not be variations due to image layers.
To help illustrate the issues, we will compare the Minimus vulnerability report to a Grype report for the same image: reg.mini.dev/elasticsearch:9.2.0 (performed January 2026).
Minimus counts 71 OS-level packages in the SBOM. Grype detects hundreds more packages because it also inspects dependency manifests and compiled artifacts.
The vulnerability count is vastly different. The Minimus report counts the number of unique vulnerabilities and lists all affected packages. The Grype report counts the number of affected packages as the number of vulnerabilities.
Vulnerabilities under review are not listed in the Minimus vulnerability report so as to avoid false positives. The Grype scan includes any vulnerabilities that were programmatically detected even if they have not yet been vetted.For example, CVE-2026-22184 affecting zlib was listed by Grype. The Minimus report did not list the vulnerability while it was under review. Later, the Minimus security research team determined that the CVE was a false-positive and that the package was unaffected. (See the Minimus advisory for details.)
Minimus pulls the preferred severity from NVD. Grype, in turns, prefers the highest severity.For example, CVE-2026-22184 showed up as a critical vulnerability in the Grype report, but as only medium severity in the Minimus advisory. This is because the Minimus algorithm favors CVSSv4 over CVSSv3.1. CVE-2026-22184 - which also happens to be disputed - was assigned a critical severity of 9.8 in CVSSv3 but only a medium severity of 4.6 in CVSSv4. Learn more about how Minimus assesses severity in cases of conflicts
The Minimus report normalizes vulnerabilities by their CVE ID. In other words, where a CVE ID is available, Minimus prefers it over the GHSA ID. For example, the Grype report lists GHSA-vc5p-v9hr-52mj, while the Minimus report lists the same vulnerability as CVE-2025-68161.
