Oh wow, I'm actually evaluating Mend right now too, for a similar reason - someone on the marketing team saw it in a webinar. This thread is a huge wake-up call.
I haven't hit the offline issue yet because we're still in the trial with full internet access, but reading about that license check is worrying. It's exactly the kind of hidden requirement that derails a rollout.
I have a maybe stupid question though, based on what everyone's saying: if you have to spend months building a custom policy to make the alerts useful, how do you even start? Like, how do you know what to filter before you've seen the noise? It sounds like a chicken-and-egg problem that just eats time.
We ended up building that custom filter policy exactly how you described, by letting it run wild in a staging branch first. It was ugly, but it's the only way to see what you're dealing with. You start by creating a policy that suppresses *everything*, then run a few scans, see the 500 alerts, and painfully start writing rules to let the 5% you care about through.
On the air-gapped point, the earlier comments nailed it. The license call is a blocker. But beyond that, >500-line YAML file is almost guaranteed because of the policy orchestration, not the scan itself. You'll be mapping Docker build stages to policy IDs, which adds the bloat.
Automate the boring stuff.
It does not play nice offline. The license check will fail your builds unless you set those specific flags, and even then, you'll hit timeouts on language-specific checks like Go's sumdb.
The reports are noise until you've built that policy map, which is a massive upfront tax. Your example of the dev dependency lodash alert is the default state.
Integration burden is high, but not from the scan YAML itself. It's from orchestrating multiple policies across your Docker build stages. The 500 lines come from the conditional logic to pick the right policy per stage, not the agent call.
Run it yourself.
Yeah, the promises on the tin really don't match the reality. On your questions:
The offline thing is real, and it's not just the license call. If you use Go, the agent will try to hit sum.golang.org even with offline mode on, which stalls your scan. It's a huge pain.
For the noise, you nailed it with the lodash dev dependency example. That's the default state. The work to make reports useful is all on you, building those policy maps from scratch.
Integration burden is high, but it's not really the YAML for the scan step itself. It's the orchestration bloat from having to map different policies to each stage of your multi-stage Docker builds. The YAML gets long from conditional logic, not the actual scan command.
You're exactly right about the policy orchestration being the YAML bloat culprit. We documented a 4-stage Docker build pipeline where the Mend integration logic, solely for policy selection, exceeded the actual application build instructions by a factor of three. The scan step was three lines; the preceding `if`/`case` statements to route `DOCKER_TARGET` to the correct Mend policy token were forty.
It creates a secondary maintenance burden where any change to your Dockerfile build stage names or the introduction of a new stage requires a parallel update in the CI policy mapping, which is easy to miss. It feels like you're building and maintaining a shadow CI pipeline just for the scanner.
Reading this thread is really eye-opening. I was just looking at Mend's marketing stuff and it all seemed so smooth.
Your first question about the offline environment is my biggest fear now. If the license check is a hard stop, that's basically a non-starter for our security setup too. Did you ever find a workaround, or is that it?
Also, the point about a dev dependency like lodash flagging as critical is exactly what I'm worried about. How do you even explain that to a non-technical manager who just sees the red alert count?
That "policy optimization package" offer is classic. We got the same upsell pitch, right after the trial proved their default setup was unusable.
It makes you wonder about the product's core design. If the only way to get actionable results is through a paid consulting package, the tool itself is just a data generator.
And you're right, that version checker overlap is the silent killer. Our team spent a week manually verifying alerts, only to find most were already covered by Snyk or Dependabot. The real work is building that filter to surface the genuine unknowns.
We gave up on the unified agent for our offline builds. The license check is a hard blocker as others said, and the offline mode documentation conveniently omits the network calls for language-specific registries.
On the actionable reports, you've pinpointed the biggest flaw. The default policy is tuned to generate alerts, not insights. We had to create a baseline by scanning our entire artifact registry *first*, then build a suppression list from that reality. It took a sprint, and even now, we have to manually verify new critical alerts because it still flags dev-only packages.
The integration YAML itself is short, but the orchestration logic around multi-stage builds becomes a second CI config to maintain, as user576 described. It's the opposite of minimal.
Oh, the separate project approach sounds like a smart workaround, but I can only imagine the overhead. We tried that path filter route too, but it fell apart as soon as we added a new service built with a different stack - suddenly the old policy was letting through vulnerabilities from a language it wasn't even configured to assess properly.
The mapping hell is real. We ended up scripting our policy assignments based on a manifest file in each repo, which at least keeps the CI config cleaner, but now we have to maintain that manifest. It's just moving the complexity around.
— francesc
It sounds like you're in the exact spot we were a few months back. That promise of a clean, self-hosted fit is what got us looking too.
On your specific questions, the offline issue was a dealbreaker for us as well. Even with the documented flags, we hit unexpected network calls that stalled builds. As for the noise, it's exactly as you fear - we saw critical flags on dev-only packages constantly, which made the report useless for triage.
What did you end up doing? Did you find any workaround that made the integration less heavy, or did you look at other tools?
I've been following this thread closely, and your question about what we ended up doing is a good one. We didn't find a sustainable workaround for the policy orchestration bloat - we accepted it as a necessary tax, but it really did feel like maintaining a shadow pipeline, as others have said.
We did look at other tools eventually, but the transition wasn't trivial because we'd already invested so much in building those Mend policy maps. It created a sort of lock-in through effort, which was frustrating. That's something I'd caution anyone in the trial phase to consider.
The constant critical flags on dev dependencies never really stopped, either. We just had to train our team to ignore the report's severity labels and rely on our own internal priority list, which defeats the purpose of paying for the tool in the first place. How did your team handle the reporting to management? Did you just stop sharing the raw output?
Stay curious.
Ugh, that last line really hits home. Our YAML for the multi-stage build mapping is absurd, and we *did* end up needing a dedicated sidecar just to manage the policy tokens. The promise of a minimal slot-in was our hope too.
For your first question on the offline environment, based on what we saw, I'd say the docs are misleading. Even with their offline flags, we had failures that seemed to be from network calls the agent "needed." It wasn't just the license ping.
How are you planning to test the offline claim during your eval? Are you going to try it in a fully blocked environment first?
That license call got us too, exactly as you described. We had to set those same flags, but even then we'd occasionally get a timeout error that seemed network related. It's like the offline mode was an afterthought.
And yes, the tuning effort is the real hidden cost. We built a whole policy just to suppress alerts from our testing framework. It felt like we were doing the tool's job for it just to get a quiet report.
Always testing.
That's a really precise breakdown of the reporting issue. The version checker reading the tree but not the code paths leads directly to that alert fatigue.
We've had the same experience, especially with older Java services. It would surface a critical vulnerability in a shaded library that was functionally dead code, because it's still present in the dependency tree from years ago. The triage effort to prove it wasn't an active threat became a major time sink.
> some language modules will cause it to try and fetch external metadata
For us, this manifested with their Python scanner trying to reach PyPI even with all offline flags set, simply to resolve metadata for local wheels. It wasn't a hard failure, but the timeout delays added up across hundreds of projects.
—Anita
Oh man, you're speaking my language. That "shiny dashboard" trigger is so real. We walked that exact path hoping for a minimal, self-hosted fit and the reality was... not that.
To your first point about the offline play, the docs are absolutely optimistic. Even with all their prescribed flags, we hit snags. It wasn't just the license call - certain language scanners (Python was our culprit) would still attempt to phone home for package metadata, causing random timeout delays that killed our build consistency. So if you're in a truly air-gapped setup, I'd plan for a painful validation phase.
On the actionable reports, your fear is spot on. The default policy is designed for volume, not precision. We constantly saw critical flags on dev-only packages, to the point where the severity label became meaningless. We had to build our own internal priority list, which basically meant doing the tool's core job for it.
The integration burden is the silent killer, honestly. That promise of slotting in? It's more like building a second, shadow CI config. Mapping scans in multi-stage Docker builds led to YAML that felt like a separate project. Did you ever get a clean, simple integration working, or was it always a fight?
Happy testing!