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.Documentation Index
Fetch the complete documentation index at: https://docs.minimus.io/llms.txt
Use this file to discover all available pages before exploring further.
How many vulnerabilities impact my image?
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.
Which vulnerabilities are impacting my image?
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).
How can I be sure there are no false positives?
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
How is severity assessed?
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.
How many packages were scanned?
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.Scanning by image layers
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.Example
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).Grype report for reg.mini.dev/elasticsearch:9.2.0
Package count
Minimus counts 71 OS-level packages in the SBOM. Grype detects hundreds more packages because it also inspects dependency manifests and compiled artifacts.Unique vulnerabilities
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
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.)Severity
Minimus pulls the preferred severity from NVD. Grype, in turn, 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 also happens to be disputed. It 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 conflictsVulnerability IDs
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 listsGHSA-vc5p-v9hr-52mj, while the Minimus report lists the same vulnerability as CVE-2025-68161.