Let's be honest: most of these "software composition analysis" tools are just glorified version checkers wrapped in a bloated UI with a terrifying price tag. Yet, here I am, forced to evaluate Mend (still can't get used to the name change from WhiteSource) because someone upstairs saw a shiny dashboard.
We run a minimal, self-hosted CI/CD pipeline. Everything is in Docker, built on our own runners. The promise was that Mend would slot in, give us a bill of materials, and flag real issues without drowning us in false positives or requiring us to send our entire SBOM to someone else's cloud.
So, for those of you actually using it in production, not just in a trial:
* Does their "unified agent" actually play nice with offline, air-gapped, or heavily firewalled environments? The documentation reads like it assumes full outbound access, which is a non-starter for us.
* The vulnerability reports – are they actionable, or just noise? I've seen tools that scream about a `lodash` vulnerability in a dev dependency that never makes it to runtime.
* How's the integration burden? If it requires a 500-line YAML file and a dedicated sidecar container just to scan, I'd rather write a shell script that calls `trivy`.
I'm particularly interested in the experience of integrating it into a pipeline that's *not* on GitHub Actions or GitLab SaaS. Something like a Jenkins pipeline or a simple Makefile target.
```bash
# This is the kind of simplicity I want. Does Mend allow it?
make deps
make test
make scan-deps
```
Or does it demand a ritual sacrifice and a JVM to even start?
null
We ran into that exact air-gapped hurdle last year. You can set up a local Mend server to cache vulnerability data, but getting it initially populated and updated is a process. It's doable, but "non-starter" is right if your security team expects it to be a five-minute job.
On your point about noise: it's better than some, but you absolutely still get those dev dependency alerts. The trick is tuning the policies early to ignore certain scopes or paths, otherwise your Slack channel fills up with library vulnerabilities from the build stage that never ship.
Integration was lighter than I feared for our Docker builds. The unified agent runs as one step in the pipeline. The YAML wasn't crazy, maybe 20 lines to call it and pass the project token. The real burden was maintaining those policy filters to keep the signal clean.
Keep it simple.
Their offline documentation is indeed optimistic. You can run it fully disconnected, but the initial setup is a manual lift. You'll need to provision the local cache server with an initial data dump from Mend support, then schedule periodic update file transfers via your secure data transfer process. It's not a deal-breaker, but it's a project, not a checkbox.
On vulnerability noise, you've hit the core issue. The reports are actionable *if* you invest significant time in policy configuration upfront. Without it, you'll be buried in dev dependency alerts. I created separate policies for our build-stage images versus runtime images, which helped. The `lodash` example is perfect - you can set a rule to suppress vulnerabilities from paths like `node_modules/.cache` or with a `devDependencies` scope.
The integration burden for Docker was moderate for us. The unified agent step itself is concise. The real YAML complexity came from orchestrating the conditional logic - we only wanted to run the scan on merge requests, not every branch build, and we needed to fail the build only for high/critical in runtime paths. That added about 40 lines of pipeline logic around their 20-line agent call.
Data > opinions
I feel your pain with the shiny dashboard syndrome. Been there!
On your specific points: we run it fully air-gapped, and it works once you clear the initial setup hurdle. That first data sync is a manual, ticket-with-support kind of task, like others said. But after that, the unified agent itself is pretty lightweight on our runners. The YAML isn't bad - maybe 15-20 lines for a basic scan.
For the noise, it's all about those policies. If you don't carve out your dev dependencies and build paths upfront, you'll drown. We set a blanket rule to ignore vulnerabilities from anything in a `**/node_modules/.cache/**` path and it cut our alerts by like 40% overnight. The reports became useful after that.
The price tag still stings, though. No way around that.