I've been conducting a detailed evaluation of Aqua Security's vulnerability scanning for a potential client integration with their CI/CD pipeline and container registry. During our proof-of-concept, we've encountered a concerning pattern that I wanted to bring to the community for validation and discussion.
Our process involves taking a base image (in this case, a specific version of `node:18-alpine`), installing our application dependencies, and then scanning the resulting container with Aqua's Trivy engine via their CI plugin. In parallel, as part of our due diligence, we ran a manual scan using `grype` and `syft` directly on the same image. The comparison revealed a significant discrepancy: Aqua's scan consistently missed several high and critical severity vulnerabilities related to specific versions of `libssl3` and `libcrypto3` packages that were clearly present in the image layer.
To be methodical, we isolated the issue:
* **Image:** `node:18-alpine@sha256:...` (specific digest pinned)
* **Aqua Scan Command (via Jenkins plugin):**
```
aqua sec scan image --html template.html --high 10 --critical 10 node:18-alpine
```
* **Comparative Command:**
```
grype dir:./image-contents --output json --fail-on high
```
* **Finding:** Aqua reported 15 vulnerabilities. The direct `grype` scan reported 22, with the 7 missing ones all pertaining to OpenSSL libraries. The CVEs were not obscure; they were listed in the National Vulnerability Database and marked as fixed in later package versions.
We've ruled out the obvious:
1. Scanner version is latest (`v0.45.0`).
2. The DB is updated (we force a `--update-db` prior to scan).
3. We are not using custom ignore policies that would filter these out.
This raises critical questions for our integration design. If the scanner's vulnerability database or matching logic has gaps for certain libraries, it creates a false sense of security and undermines the compliance reports we intend to generate automatically for auditors.
My specific questions to the community are:
* Has anyone else observed similar blind spots, particularly with Alpine-based images and library vulnerabilities?
* Are there known limitations in Aqua's default vulnerability databases (like `ubuntu:distro` vs. `nvd`) that require manual configuration to overcome?
* In your experience, does running Aqua's scanner in a different mode (e.g., `filesystem` scan vs. `image` scan) yield more comprehensive results for these types of packages?
The reliability of this data feed is paramount, as it's intended to trigger automated gates in our deployment pipeline via webhook. A missed critical vulnerability could allow a compromised image to progress to production.
- Mike
- Mike