Originally published on LinkedIn on 2025-10-22.
Vulnerability scans can be tricky and there are different strategies. It starts already at the datasets provided by the different OS and how they are implemented from the scan tools. For example Alpine. A lot Engineers think it is secure because 0 vulnerabilities shown at scans with tools like trivy.
But there is security.alpinelinux.org and information about potential CVEs within Alpine packages.
And Alpine provides also information about CVEs which are already fixed within the secdb.alpinelinux.org service.
The information a vulnerability scanner utilizes to detect Common Vulnerabilities and Exposures (CVEs) during the scanning of artifacts, such as container images, is highly relevant. For example, a Trivy scan of an Alpine-based container image that reports zero vulnerabilities often signifies that zero security fixes (secfixes) are currently available for the listed Alpine packages. This approach makes sense, especially when package versions are pinned within the Containerfile, as the focus is on known, fixable issues. Integrating this scanning strategy early in the CI/CD pipeline is highly beneficial, since fixable CVEs are detected during the build process, raising immediate awareness. Consequently, Trivy does not support the detection of truly unfixed CVEs when scanning Alpine. A detail which may not be surprising if the documentation was properly read.
See: https://trivy.dev/v0.67/docs/coverage/os/alpine/
In contrast, Debian pursues a different strategy. It maintains a database of open, known CVEs for its packages (www.debian.org/security/), and Trivy uses this information for its scans. This results in a completely different outcome: with the same tools in the same workflow, the detection of unfixed CVEs is supported.
Details in the Trivy documentation: https://trivy.dev/v0.67/docs/coverage/os/debian/
The crucial implication of these contrasting strategies is immediately apparent in the maintenance of the vulnerability baseline: the .trivyignore file. For an Alpine-based image, the .trivyignore file will contain significantly fewer entries, documenting only exceptions for issues where a fix exists but is being deferred. Conversely, the Debian approach necessitates a .trivyignore file with many more entries, as it forces the user to manually suppress or accept known, but as yet unfixable (by simple package updates), CVEs that are reported by the scanner.
Ultimately, teams must decide which vulnerability reporting strategy aligns best with their risk tolerance and pipeline metrics. This distinction is relevant for effective #DevSecOps and #Security practices, underscoring the importance of knowing your tools and their limitations. Maybe also use multiple tools, but evaluate if there are different strategies to detect what is expected.