I’ve been conducting a comparative analysis of vulnerability scanners as part of our shift-left security initiative and have encountered a consistent discrepancy between Sysdig Secure and Trivy. Specifically, when scanning the same container image—in this case, a base Node.js 18 image with several application dependencies—Trivy reports a number of high-severity CVEs related to bundled system libraries (e.g., `libssl3`, `libcrypto3`) that Sysdig does not list in its vulnerability assessment panel.
My understanding is that both tools ultimately rely on feeding package metadata to vulnerability databases, but the divergence in results suggests a fundamental difference in approach or configuration. This creates a compliance gap, as our policy gates are based on Sysdig's runtime findings, yet our CI pipeline (using Trivy) is failing builds due to these "missing" vulnerabilities.
To provide concrete context, here is a simplified version of the workflow:
**1. Trivy Scan (CI Pipeline):**
```bash
trivy image --severity HIGH,CRITICAL myregistry/app:node18-v1.2
```
Output snippet includes:
```
node18-v1.2 (debian 12.4)
===========================
Total: 42 (HIGH: 38, CRITICAL: 4)
Library: libssl3
Vulnerability ID: CVE-2023-3817
Severity: HIGH
...
```
**2. Sysdig Secure Scan (Post-Deployment):**
- Image is scanned via the Sysdig agent/integration.
- The vulnerability UI shows only 8 HIGH-severity findings, all in application-layer npm packages.
- No operating system/library-level CVEs are reported.
My current hypotheses for the discrepancy are:
* **Scan Scope & Depth:** Sysdig might be configured by default to only scan certain layers or package types (e.g., language packages), potentially ignoring the base OS or its libraries unless a specific setting is enabled.
* **Database Source & Timing:** While both likely use feeds from NVD, there could be differences in synchronization schedules, curation, or even the use of proprietary augmented databases.
* **Vulnerability Filtering/Grouping:** Sysdig may apply active filtering to suppress vulnerabilities it deems "not exploitable in a container context," or it might group multiple CVEs under a single parent issue.
* **Component Detection:** The method for enumerating installed packages (e.g., analyzing `dpkg -l` output vs. inspecting files directly) could yield different component lists.
I am seeking clarification from the community on whether others have observed this pattern and, more importantly, what the root cause tends to be. Specifically:
- Are there specific scanner settings in Sysdig (e.g., `Drift Prevention` settings, `Scanning Scope` options) that must be explicitly configured to match the breadth of a standalone CLI tool like Trivy?
- Is there a known and documented policy within Sysdig regarding the exclusion of certain base image vulnerabilities, and if so, what is the rationale?
- What is the recommended practice for aligning pipeline and runtime vulnerability findings to prevent this type of gap?
The classic "scanner differential" headache. You've hit on the dirty secret of container security: everyone's using different vulnerability databases and, more importantly, different methods for enumerating packages in the first place.
Trivy, by default, performs a pretty aggressive filesystem scan looking for *any* installed library, including those bundled by the base image's package manager that you might not even know are there. Sysdig Secure, in my experience, often relies more heavily on the OS package manager's metadata (like dpkg or rpm databases). If a library is present on the filesystem but not cleanly listed in the package manager's installed manifest, Sysdig can miss it. That's likely where your `libssl3` and `libcrypto3` are hiding.
Check your Sysdig scan configuration. There's usually a toggle between "package-based" and "filesystem-based" scanning. If it's set to package-only, you're only seeing what the OS package manager admits to. Trivy defaults to the latter, which is noisier but more thorough.
Also, verify the feed sources. Are both tools pulling from the same vulnerability database (like VulnDB, NVD) at the same freshness? A lag of even a day can create discrepancies.
Both tools are wasting your time. The real problem is your base image.
You're scanning a Node.js app. Those libssl CVEs are from the OS layer, not your app dependencies. If you're using a bloated base image like `node:18`, you're inheriting a full Debian or Ubuntu userspace. That's where 90% of these "vulnerabilities" live.
Switch to a distroless or minimal base image for Node. Something like `gcr.io/distroless/nodejs`. Your scanner differential will shrink because there's almost nothing *to* scan. Fewer packages, fewer false positives, fewer debates about which scanner is right.
You're chasing scanner accuracy when you should be chasing a smaller attack surface.
Simplicity is the ultimate sophistication
That's a solid example of the database timing lag user198 mentioned. One thing I've noticed is that Sysdig's default feeds sometimes take 24-48 hours longer to populate new CVE matches compared to Trivy's immediate pulls from sources like the NVD. It's worth checking if those specific CVEs are very recent.
If you need parity for policy gating, you can adjust Sysdig's scan depth. There's a setting in the agent config to enable filesystem scanning alongside the package manager check, though it'll slow things down. This often catches those "bundled but not registered" libraries.
```yaml
scanning:
filesystem: true
packages: true
```
But honestly, user188 has a point too. Those base image libraries are a constant source of noise.
Thanks for flagging the config snippet, I was looking for that exact setting. The database timing piece is something I hadn't considered.
When you mentioned the 24-48 hour lag, is that something you've seen documented, or more of an observed pattern? I'm trying to build a case for adjusting our scan schedules so they line up better.
I agree user188's point about the base image is valid, but I think it's a separate track. We can work on slimming the image long-term, but we still need to understand the scanner gap for our current builds, especially for compliance reporting. Enabling filesystem scanning seems like a necessary step for now, even if it's slower.
That lag observation is interesting because it lines up with something I've seen on the product side, but for us it's often about which *feed* you're subscribed to within Sysdig, not just the raw pull time. The default feed isn't always the freshest.
> We still need to understand the scanner gap for our current builds, especially for compliance reporting.
Totally get this. When we were building a case, we ran both scanners at the same time and logged the CVE IDs that only Trivy caught. Then we'd manually check the VulnDB entries to see if they were truly new or just database lag. It was tedious, but it proved the gap existed for our auditors. The filesystem scan will help, but you'll probably still see a timing delta on true zero-days.
That manual logging approach is exactly what I was thinking I'd have to do for our auditors. But the feed subscription thing is new to me - I just assumed Sysdig's default feed was the same as what everyone gets. Is there a way to see which feed your tenant is on without asking support? I'm not sure I even know what the options are.