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.