Hey everyone, been trialing Xray for a few weeks now on our container images. I've noticed that when I switch from the 'standard' scan to 'comprehensive,' the scan times jump significantly—we're talking hours instead of minutes.
But I'm struggling to see a tangible difference in the results. It's catching the same high and critical CVEs in both modes for my test cases. The documentation says it does a "deeper analysis," but what does that actually mean in practice? More layers? Different heuristics? Has anyone done a real comparison and found the extra wait is actually worth it for better findings? Or is it mostly for compliance checkboxes?
Self-host or die trying.
I ran into this same confusion during our evaluation. The support rep I spoke to mentioned that for our use case, which was mostly base images, the "deeper analysis" specifically targets transitive dependencies that aren't explicitly declared in your package manager files. For a standard Node.js or Python app, you might not see much new. But they said it can matter a lot for compiled languages or complex monorepos where dependency resolution is less straightforward.
Has your team tested it on a more complex, multi-stage build image yet? I'm curious if the delta in findings becomes more obvious there, or if the performance hit is truly just for that compliance checkbox.
The documentation is deliberately vague because the actual difference is in scan breadth, not depth. It's not about analyzing more layers, it's about expanding the dependency graph.
Standard scan only checks the direct dependencies listed in your package-lock.json or requirements.txt. Comprehensive mode unpacks every single file in the image and runs multiple package manager detectors, trying to find libraries that were installed manually, copied via `COPY .`, or are buried inside vendored code. If you're only using standard `npm install` or `pip install` in your Dockerfile, you'll see zero difference in results, just the massive time penalty from that brute-force file system crawl.
The real value shows up when you have a Java app that pulls in shaded jars, a Go binary with statically linked libraries, or a legacy system where someone just dumped `.so` files into `/usr/local/lib`. For a clean, modern application built with standard package managers, comprehensive is indeed a compliance tax.
—davidr
That's a really helpful distinction between breadth and depth, makes total sense. I've seen something similar in our own scans with a couple of internal Go tools. The comprehensive scan actually picked up a CVE in a statically linked crypto library that the standard scan missed entirely, because the binary was just copied into the final image.
So it's not just a checkbox, but it is incredibly context-dependent. The time penalty feels brutal when you don't need it, but it can be a lifesaver for those messy, non-standard builds. Makes me think scan policies should really be image-by-image.