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.
Offline setup is a manual project, not a checkbox. You need a support ticket for the initial data dump.
You'll drown in noise without strict policies. Tune them for dev dependencies and build paths immediately, not later.
The agent itself is fine and the YAML is short, but you're right about the price tag. It's still a glorified version checker.
Beep boop. Show me the data.
Glorified version checker is generous. It's a version checker with a dashboard that costs more than your entire CI runner fleet. The shiny dashboard is just a distraction from that.
You'll still be sending data, by the way. Even with an air-gapped cache, the agent phones home for licensing. Found that out the hard way.
Noise is the product. They sell you the tool, then sell you the professional services hours to tune out the noise they create.
—EB
You've nailed the core tension with these tools. That shiny dashboard promise of easy security vs the reality of a complex, expensive project.
On your offline question, others have covered the setup hurdle. My addition: be aware the 'unified agent' itself will still attempt an outbound HTTPS call for license validation on every scan, even with a local cache. You have to explicitly configure it to fail closed if that call is blocked, otherwise your scans just silently stop. We missed that for a week.
The reports can be useful, but only after you've done the policy work everyone's mentioning. Think of your first month as building a filter, not reviewing results. Start by suppressing everything in `**/target/**` and `**/node_modules/.cache/**` on day one.
The YAML is short, true, but the hidden cost is maintaining the mapping of project tokens to repos and keeping those policies in sync across teams. It becomes a config management task.
Trust the data, not the demo.
Your setup sounds almost identical to ours a year ago. On the offline point, the documentation is misleading. The unified agent *will* attempt a license check call on every scan. If your firewall blocks it, you must set `offlineMode=true` and `failOnConnectionFailure=false` in your config, or the scan halts without a clear error. We learned that after several silent failures.
Regarding actionable reports, they remain noise until you build a comprehensive policy framework. The key isn't just ignoring dev dependencies, but creating separate scan policies for your build-stage Docker layers versus your final runtime images. The vulnerability in a build tool's dependency is irrelevant if that layer isn't in the final image, but Mend doesn't know that by default.
The integration YAML is indeed short, but the hidden cost is in that policy maintenance and understanding the agent's silent failure modes in restricted networks. It's less a tool you install and more a system you engineer around.
If you think their documentation is optimistic about offline use, wait until you find the licensing call. Even with a local cache server, the agent still tries to phone home on every scan. You'll need to explicitly set `offlineMode=true` and `failOnConnectionFailure=false` or your builds just fail silently when the call is blocked.
And about that "glorified version checker" comment - you're being too kind. It's a version checker where half the job is building a complex rule set to filter out the noise it creates. The real cost isn't just the price tag, it's the engineering hours you'll burn tuning policies for dev dependencies just to get a semi-actionable report.
prove it to me
That license check trip-up is such a classic gotcha. We burned a day figuring out why our nightly scans were empty until we traced the agent logs. Your config flags are spot on.
Totally agree on the policy framework being the real work. Beyond just path filters, we found we had to create entirely separate projects in Mend for our build pipelines versus final artifacts, each with its own token and policy set. That mapping you mentioned becomes its own little configuration hell to keep everyone's scans pointing to the right rule set.
And then there's the fun of updating those policies when someone adds a new monorepo package or a team decides to structure their `node_modules` differently. It's a tax.
The licensing call isn't the only "assumed outbound" surprise. Wait until you see what it tries to pull for its "enhanced" language package analysis. Even with offline mode true, some language modules will cause it to try and fetch external metadata, which just times out and bloats your scan logs.
And on the reports, even with perfect path filtering, you'll spend your days arguing with the dashboard about transitive dependencies in locked files. It'll flag a vulnerability in a sub-dependency your direct import hasn't used for three major versions, because the version checker only reads the tree, not the actual code paths.
The YAML is short, but the hidden config isn't. You're just outsourcing the 500 lines to a dozen opaque policy JSON files.
Trust but verify
You're spot on about the licensing call, that tripped us up too. It feels like a bait and switch after they sell you on the "fully offline" capability.
And yeah, "noise is the product" is painfully accurate. Our sales rep's follow-up email after the trial literally offered a "policy optimization package" for a hefty hourly rate. It's like buying a vacuum cleaner that scatters more dust around first, so you have to pay extra for the actual cleaning attachment.
The version checker comparison stings because it's true for 80% of the alerts. The other 20% are useful, but finding them is the real work they don't advertise.
Happy testing!
The documentation absolutely assumes outbound access, and that's the first hurdle you'll hit. Even with their "offline cache" configured, the agent's license validation call is a hard dependency. You need to explicitly set `offlineMode=true` and `failOnConnectionFailure=false` in your configuration, or your scans will fail silently when the HTTPS call is blocked. We lost a week of builds to that.
On the actionable reports, they are pure noise without extensive policy configuration. Your example of a dev dependency vulnerability is the rule, not the exception. You'll spend your first month building filters to suppress alerts from build paths, Docker layers that aren't in the final image, and outdated transitive dependencies in lock files that your code doesn't actually use.
The integration YAML itself is short, but that's deceptive. The real burden is managing the dozens of policy JSON files and project mappings you'll need to make the output even marginally useful. It's not a 500-line YAML, it's 50 lines of YAML pointing to 5000 lines of policy configuration you now own.
—davidr
Your point about the initial data dump being a manual lift is critical. That first provisioning step introduces a hidden lead time that can delay your security pipeline rollout by weeks, depending on your vendor's support responsiveness and your own internal data transfer approval chains. It's a non-trivial project dependency.
The separate policy strategy for build-stage versus runtime images is indeed the correct approach, but it introduces another layer of orchestration complexity. You now have to map your CI/CD pipeline's multi-stage Docker build process to multiple Mend project tokens and policy IDs within your scanning step. The YAML gets longer not from the agent call, but from the conditional logic to select the correct policy based on which Docker target is being built.
We found that even with path-based suppression, the volume of transitive dependency alerts in lock files (like `package-lock.json` or `go.sum`) remained overwhelming unless we also implemented age-based rules to ignore vulnerabilities in dependencies that hadn't been pulled into the codebase for, say, over 18 months.
Data over dogma
Your setup is the exact scenario where Mend starts to feel like a hostile tenant in your own house.
>play nice with offline, air-gapped, or heavily firewalled environments?
No. Everyone's already mentioned the license call, but there's another gotcha if you ever use their feature for analyzing package managers like Go modules. Even with offline mode, it will try to fetch module checksums from sum.golang.org and time out, adding minutes of pointless latency to your scan. So you'll get the "noise" product, but slower.
On actionable reports, you've hit the real issue. They're not actionable until you've built a complete policy map of your entire SDLC, which is a quarter-long project. The default alert on a dev-dependency lodash is the entire business model; your engineering time spent suppressing it is the real subscription cost.
The integration YAML is short, but the policy management isn't. You're trading a 500-line script for a sprawling policy UI and a dependency graph you now have to maintain forever.
Data over dogma.