Skip to content
Notifications
Clear all

Has anyone gotten Mend to work with Bazel builds?

4 Posts
4 Users
0 Reactions
1 Views
(@crm_hopper_2024)
Reputable Member
Joined: 4 months ago
Posts: 121
Topic starter   [#17544]

Trying to integrate Mend SCA into our Bazel monorepo. It's been a special kind of hell.

Their docs basically say "use our plugin" which assumes Maven/Gradle. The agent-based approach feels like trying to fit a square peg into a round hole with Bazel's sandboxed, hermetic builds.

Has anyone actually gotten this to work without duct tape and prayer? I'm looking at post-build analysis, but their support just sends me the same pre-canned responses. Feels like they don't actually support non-standard build systems.


CRM is a means, not an end.


   
Quote
(@integration_ian_3)
Reputable Member
Joined: 1 month ago
Posts: 129
 

Oh man, that post-build analysis route is exactly where I ended up after banging my head against it for weeks. The agent really doesn't play nice with the sandbox.

What finally worked for us was treating it as a separate, non-hermetic step. We generate a merged dependency graph file (like a cyclonedx SBOM) from Bazel's query commands after the main build finishes, then feed that static file to the Mend CLI scanner. It's clunky and adds a few minutes, but at least it's consistent.

You lose the live scan during the build phase, but you get accurate results. Their support definitely isn't equipped for this - I had to piece it together from GitHub issues and old Slack threads.


Integration Ian


   
ReplyQuote
(@emma88)
Trusted Member
Joined: 6 days ago
Posts: 33
 

That's basically our plan B. Did your accuracy change at all going to post-build? We've seen some false positives creep in with the static SBOM approach, especially around transitive dependencies Bazel prunes.



   
ReplyQuote
(@db_diver)
Estimable Member
Joined: 4 months ago
Posts: 93
 

Exactly. Their documentation and support model are built around a Maven/Gradle world. It's the same issue you see with many security tools; they prioritize the Java ecosystem's standard dependency management, leaving hermetic build systems as a second-class concern.

The core problem is the agent expecting a live, mutable environment to intercept calls, which is antithetical to Bazel's sandbox. I've seen teams attempt to wrap the build in a custom action that disables sandboxing for that step, but that defeats the reproducibility guarantee.

You're correct that post-build analysis is the pragmatic path, though as others noted, you trade some fidelity for stability.


SQL is not dead.


   
ReplyQuote