Alright, so we're giving Mend a proper trial run after the whole WhiteSource rebrand. The pitch was solid: consolidate SCA, container, and IaC scanning. One pane of glass, etc. We've been at it for a quarter now, and I have to say, the container scanning module is threatening to derail the entire project.
The false positive rate on our container images is absurd. We're talking about flagging base image "vulnerabilities" that are patched in later layers, or highlighting libraries that are present in the build context but never actually packaged into the final runtime image. It's creating so much noise that our security team is starting to just ignore the Mend dashboards altogether, which defeats the whole point.
A few specific pain points:
* **Ubuntu base image mania:** It keeps screaming about CVEs in `libc6` or `apt` packages from the base Ubuntu layer. We're using a multi-stage build where the final image is based on `distroless` or `alpine`. The vulnerable packages aren't in the final artifact. Mend seems to just scan the first stage and call it a day.
* **Build-time dependency ghosts:** It's flagging Node.js `devDependencies` or Python packages only used during the build process. Our Dockerfiles have explicit steps to remove them before the final layer, but Mend's scanner either isn't following the Dockerfile logic or is taking a naive filesystem snapshot.
* The triage workload has tripled. Every sprint, we're wasting hours manually validating and dismissing these non-issues. The "suppress" rules feel clunky and don't scale.
We came from a patchwork of Snyk and Trivy, and while Mend's SCA is decent, this container scanning feels like a bolted-on afterthought. It generates fear, uncertainty, and doubt (and lengthy compliance reports for management) without the accuracy to back it up.
Has anyone else hit this wall? Did you find a magic configuration setting we've missed, or is this just the state of their engine? We're already eyeing the exit, which is a shame because the licensing and dependency reporting was cleaner for our non-container stuff. At this rate, we'll be back to a multi-tool setup by next quarter—exactly what we were trying to avoid.
Yep, hit the same wall with their container scanning. It treats the Dockerfile like a simple list, not an actual build process.
For the multi-stage build issue, you need to explicitly tell Mend which stage is your final target. Check the scan command or config for a `--target` flag or similar setting. If you're not providing that, it will absolutely just scan the first FROM line it sees.
On build-time dependencies, that's a harder one. Their SBOM generation isn't distinguishing between build and runtime layers effectively. We had to implement a pre-scan step to prune `node_modules` and `__pycache__` from the build context before the Mend scan kicks off. Adds friction, but cut the noise by about 60%.
Have you looked at the policy rules to try and auto-suppress based on image type? It's clunky, but might help stop the alert fatigue.
Integration is not a project, it's a lifestyle.
Totally agree on the multi-stage target flag, that's crucial. We missed that at first too and it caused a week of chaos.
The pre-scan step for build deps is a solid workaround, but it feels like we're papering over a core SBOM issue. We've had similar luck with their policy rules for auto-suppressing certain base image CVE ranges. It helps, but then you're just building a brittle suppression list on top of a noisy tool.
Have you tried running a scan from the pushed image in your registry vs. during the CI build? We saw slightly different, but not better, results. Makes me wonder how they're even constructing the layer tree.
—b