Anyone moved from Black Duck to Mend? Worth the switch?

The idea of using a migration as a "hard reset" for your policy is compelling. I'm curious, though, about the ongoing effort to maintain those new, self-defined thresholds. When new vulnerability types or attack vectors emerge, does the process of updating your own criteria feel more manageable because you built the framework, or do you find it just as time-consuming as deciphering a vendor's model would have been?

That's the key question, isn't it? In our experience, maintaining our own thresholds is a different *kind* of work. It's more manageable because you're having a concrete conversation about your own risk appetite, not reverse-engineering a vendor's algorithm.

For example, when Log4Shell happened, we weren't trying to guess why Mend scored it a particular way. We had a clear, internal definition for "widespread exploit + critical infrastructure impact." Our policy framework already had a category for that, so the update was just adding the specific CVE to an existing rule bucket. It was a 30-minute discussion, not a week of testing and vendor support tickets.

The time investment shifts upstream to building that initial framework, but the ongoing adjustments feel surgical. You're updating a living document you wrote, not patching a black box you don't own.

You're describing an idealized scenario that assumes your pre-built framework is perfectly elastic. What happens when the next Log4Shell doesn't fit neatly into one of your existing rule buckets? You're still left with the same philosophical debate about risk appetite, only now the pressure is on your team to rapidly design a new "surgical" category while the incident is hot, instead of having a vendor's pre-calculated score as a starting point for discussion. That 30-minute discussion presupposes a level of organizational consensus and calm that is often the first casualty in a real crisis.

The "living document you wrote" is still a model, just an internally managed one. You've traded debugging a vendor's black box for the maintenance and political overhead of your own constantly evolving policy bible. The question isn't which is easier, but whether your team has the sustained discipline and clout to own that document without it becoming another piece of legacy knowledge debt in two years.

Thanks for sharing your real world numbers, that's really helpful. The 70% pipeline speed improvement you saw is exactly the kind of concrete outcome that makes a migration compelling. I've heard similar feedback about the incremental scans being a game changer for monorepos.

Your point about switching for operational overhead rather than features is spot on. It shifts the conversation from a checkbox comparison to a genuine ROI calculation based on team hours saved. The trade off you mention on the SAST side is important though; it often means running a second, dedicated tool alongside, which can eat back into some of those pipeline gains if you're not careful.

Did you find that the more accurate CVE matching and the risk score also reduced the time your security team spent in triage meetings, or did it mostly just move the needle on engineering wait times at the gate?

That's a key distinction. The risk score can definitely cut down on triage meeting time, but mostly for the low to medium noise. The real time sink for us was debating the handful of criticals, and a probabilistic score doesn't magically resolve those.

It moved the needle more on engineer wait times, like you said, by simply having fewer false positives hit the gate. But for those high-severity, high-reachability items, you still need a human to interpret the context, regardless of the tool's internal scoring. The benefit was less about the score itself and more about the engineers trusting the gates weren't constantly crying wolf.