After 18 months of using Mend (formerly WhiteSource) as our primary SCA tool, our team has reached a consensus on its strengths and significant frustrations. We implemented it to automate vulnerability remediation and maintain license compliance across a large Java and JavaScript microservices portfolio.
Here’s a breakdown of our experience.
**What we loved:**
* **Remediation automation:** The ability to automatically create pull requests with suggested dependency upgrades was a major time-saver. It integrated cleanly with our GitHub Enterprise workflow.
* **Comprehensive vulnerability database:** The breadth and update frequency of its database gave us confidence we weren't missing critical CVEs. The prioritization based on actual reachability in our code was valuable.
* **License compliance clarity:** The policy engine for licenses worked well. Generating compliance reports for legal was straightforward and reduced manual review.
**What made us consider switching:**
* **Alert fatigue and noise:** Despite tuning policies, we received a high volume of alerts for vulnerabilities in development dependencies or transitive dependencies with no actual execution path. The signal-to-noise ratio became a persistent management issue.
* **UI and performance bottlenecks:** Navigating the product's interface, especially when dealing with hundreds of projects, felt slow. Certain batch operations, like applying a policy change across multiple repositories, were clunky.
* **Integration friction with our CI pipeline:** While the basic integration worked, more advanced CI pipeline scenarios (like monorepos with complex builds) required custom scripting that felt unsupported. This increased maintenance overhead.
Our overall health score for the tool would be mixed. It delivers on core SCA promises but introduces workflow inefficiencies that have led us to evaluate alternatives. We are now specifically looking at tools that offer more granular control over alerting and provide a faster, more developer-friendly interface.
I'm curious if other long-term users have hit similar pain points, and if so, how you've addressed them.
That point about alert fatigue is a common pain point I've seen, especially in larger microservices environments. While the reachability analysis is strong, the sheer volume of transitive dependency noise can really undermine the signal.
Have you experimented much with their new policy filters from the last platform update? A team here had some success reducing the noise by creating stricter rules that ignored dev dependencies entirely and only flagged transitives if they were pulled in by a direct dependency with a `runtime` scope. It's not a perfect fix, but it helped them stay focused on what was actually deployable.
Keep it real, keep it kind.
Totally feel you on the alert fatigue. The reachability analysis is good, but the transitive dependency graph for a typical Java/JS app is just so huge. That noise-to-signal ratio becomes a real problem for team adoption - you can't have devs ignoring the dashboards because they're flooded with non-issues.
We found that creating super-strict, project-specific policies was the only way to manage it, which kind of defeats the purpose of a unified platform view. Had to basically maintain a rulebook for what we considered "in scope" for each service.
Did you ever see issues with the remediation PRs themselves? We ran into cases where the suggested upgrade path for one CVE would introduce a new, incompatible API change that broke a build, creating a different kind of fire drill.
That's a great observation about the unified view. You're right, when you have to build a custom rulebook for every project just to get a clean signal, the platform's central dashboard becomes more of an administrative burden than a source of truth. It fragments the visibility it's supposed to provide.
On the breaking changes from remediation PRs, yes, we saw that too. The automated fix for a low or medium severity CVE sometimes introduced a major version bump with breaking API changes, which is a much higher business risk than the original vulnerability. It forced us to review every automated PR with the same scrutiny as a manual one, which cut into the promised efficiency. Did your team settle on a process for pre-screening those upgrade paths, or was it always reactive after a build broke?
Review first, buy later.
> The prioritization based on actual reachability in our code was valuable.
> Alert fatigue and noise... for vulnerabilities in development dependencies or transitive dependencies with no actual execution path.
Exactly this. That reachability analysis is such a double-edged sword. It's great for prioritization on paper, but it can make the noise feel even more frustrating because you've already been told the tool is smart enough to know what's actually reachable.
We ran into a similar wall with adoption. The dashboard would show hundreds of "reachable" issues, but a deep dive would reveal the path was through a test utility or a dev-only build script. You end up having to build that internal "rulebook" anyway to define what "reachable" *should* mean for your context, which eats into the time you were supposed to save.
Have you found the noise impacts how your security and dev teams collaborate on this, or does everyone just tune it out?