Scanner detection limitations
Sometimes, you will see a detection lag between when the vulnerability was first published and until it is detected in the package. This behavior may be confusing at first since a CVE may even be published weeks before it is first detected in an image. The key is to understand that delays in scanner detection are most often caused by missing data in the CVE listing itself. Since this limitation is general, it is not attributable to any specific scanner and it will impact all scanners equally. A CVE ID may be reserved and listed by NVD with minimal data that is not usable by scanners, effectively rendering the CVE listing not actionable. A scanner cannot flag a CVE in an image until affected versions, package data, and CPEs (Common Platform Enumeration) are defined. This means a CVE may be listed long before it can be detected by scanners. For example, the advisory for CVE-2025-60876 shows a scanner lag from the original publishing date. The change history in the NIST listing for CVE-2025-60876 clarifies the cause is a CVE enrichment lag, not a scanning failure. CVE-2025-60876 was not detectable by vulnerability scanners until the BusyBox CPE and version constraints were added to the NVD record. Prior to CPE data enrichment, the CVE lacked machine-readable product metadata, which prevented reliable scanner matching. This explains the delay observed by scanners. Since this is a general limitation, it is not attributable to any specific scanner.Advisory fix date vs. image fix date
The advisory fix date is based on the package fix date and it can differ from the image fix date. This can happen for several reasons. Below are a few examples of typical cases.Package fixed but pending image build
Minimus packages are updated on a continuous basis that is independent from the vulnerability remediation process. As a result, package updates are published as soon as an update is available upstream. New images, on the other hand, are published on a daily basis. Consequently, an advisory may show the fixed status when the fixed package is already available but before the fixed image is released.
Image fixed before advisory was published (silent fix)
You might wonder how an image could be fixed before the advisory was ever published? This is known as coordinated disclosure and silent patching, or a silent fix. In coordinated disclosure, the vulnerability is discreetly reported and is not publicly announced until after the fix is made available. Usually, the patch is released before the vulnerability is announced to allow users time to deploy the fix and minimize the window of opportunity for exploitation by bad actors. Since Minimus builds updated packages and images on an ongoing basis, Minimus guarantees that you will always have the most secure images available to you, even before word of the vulnerability reaches your scanners, vulnerability management platforms, CNAPP and SIEM.Display of silent fixes in Minimus
Silent fixes describe cases where the fix is released before the vulnerability is publicly disclosed. CVE-2025-68119 is a good example of how Minimus displays silent fixes. The advisories for CVE-2025-68119 were published on Jan 28, 2026 and show that the vulnerability impacted nearly 400 packages and required fixing hundreds of images. Some of the affected packages were fixed before the vulnerability was published - that is, they were silently fixed. For example, the Logstash image changelog shows that an image version that fixes this vulnerability was published on Jan 6, 2026.
- The advisory fix date shows when the scanner recognized the fix. The advisory does not show when the fixed image version became available.
- The changelog fix date shows when the fixed image version was published by Minimus.