We’ve been running Wiz for about four months, mostly for cloud security posture and vulnerability scanning in our EKS clusters. This week it flagged a critical CVE in a Java library (`commons-collections4:4.0`) in one of our microservices.
The problem: our service doesn’t depend on that library. At all.
Here’s what I’ve verified so far:
* The Docker image for that service is built from a minimal base image. Our `pom.xml` does not list `commons-collections4`.
* Ran `mvn dependency:tree` on the build – it’s not pulled in transitively.
* Checked the image layers with `docker history` and `docker inspect`. No unexpected additions.
* The Wiz finding points to a path inside the container: `/usr/local/tomcat/webapps/ROOT/WEB-INF/lib/commons-collections4-4.0.jar`. That directory doesn’t exist in our final image – we use a distroless Java runtime.
I suspect the scan is either:
1. Picking up a build artifact from an intermediate layer that isn’t in the final running container.
2. Misattributing a library from the base image (though our base is clean).
3. There’s a cached or leftover file in the CI runner that got bundled during the scan process.
Has anyone else run into false positives with Wiz’s vulnerability detection for interpreted/compiled languages where the dependency isn’t actually present in the deployed artifact? If so, what was the root cause and how did you resolve it with Wiz?
I need to either fix our pipeline to eliminate the false positive or adjust Wiz’s scanning logic – but I need evidence. The “critical” severity is causing unnecessary escalation alerts.
-shift
shift left or go home
That intermediate layer theory is likely correct. Vulnerability scanners often analyze the entire image build context, not just the final running filesystem. I've seen this exact pattern with trivy and grype when scanning multi-stage builds.
You can confirm by running a manual scan on just the final image layer. Use `docker inspect` to get the layer hash, export it with `docker save`, and run your scanner against that single tar stream. Alternatively, add a `--ignore-unfixed` flag if your scanner supports it, but that's a band-aid.
The real fix is in your CI pipeline. Configure Wiz to only scan the final, deployed image artifact, not intermediate build stages. If you're building in Jenkins or GitLab, ensure the scanning step runs after the image is fully assembled and pushed to the registry, not during the Docker build process where it can pick up leftover dependencies from the builder stage.