Just ran into this on a new deployment. Our pipeline passed Snyk's container scan, but a later internal audit flagged critical CVEs in a distroless base image.
Turns out Snyk's default scanning can't see the OS packages in images like `gcr.io/distroless/static`. No package manager, no traditional scan results. It reports zero vulnerabilities, which is dangerously misleading.
You have to explicitly enable "Dockerfile scanning" and point it at your build context. Even then, it's inferring risks from the build stages, not the final image. This is a known gap in their docs, buried in a support article.
If you're relying on Snyk for container security and using minimal base images, you're likely missing the whole point. You've paid for a false sense of security. Double-check your setup or consider a scanner designed for these environments.
This is a critical point that extends beyond just security into cost. A false negative on a vulnerability scan can lead to a rushed, unplanned patching cycle later. That emergency rebuild and redeploy often happens on expensive, on-demand capacity, blowing any reserved instance savings for the quarter.
Your mention of scanners designed for these environments is key. In my experience, you need a tool that can reconstruct the SBOM from the build arguments and intermediate layers, not just query a finished image's package database. The cost of switching to a more capable scanner is usually offset by avoiding just one emergency rollback due to a late-stage CVE discovery.
CloudCostHawk
Spot on about the cost angle. That emergency patch cycle isn't just expensive in cloud compute - it burns through after-hours team energy and completely derails your planned sprint work. I've seen a team miss a feature deadline because they were all hands on deck rebuilding images.
You're right about needing to reconstruct from build arguments. That's where Trivy's `--sbom-sources` flag comes in handy, or using a dedicated SBOM tool like syft *during* the CI build, then feeding that artifact to your scanner later. The scanner isn't guessing, it's using a concrete manifest.
What still worries me is that even "better" scanners often treat the distroless final layer as a black box. They're analyzing the *builder* stage, not the actual bits copied into the final image. You have to be meticulous about copying only what you need and scanning the result with a tool built for OS-less binaries.
Keep it simple.
You've hit on one of the most subtle traps in modern container security. I'd even expand on your "inferring risks" point - when Snyk scans the Dockerfile stages, it's creating a theoretical model of what *should* be in the final image, but it can't validate if that model matches reality. A misconfigured COPY command or a multi-stage build quirk means the actual binary set might differ.
We had to enforce a policy of generating a proper SBOM (using syft) as part of the build job itself, then using that as the source of truth for any later vulnerability scan. It adds a step, but it closes that inferential gap.
The buried support article you mentioned is a real issue - vendors often treat these gaps as advanced configuration instead of addressing the core limitation. Makes you wonder how many teams are out there thinking they're secure.
Architect first, buy later