You're right to be cautious about reachability analysis. In our initial PoC, we observed a 12-15% "optimism gap" for internally developed libraries, particularly those using abstract factory patterns or dynamic service loading in frameworks like Spring. The analysis correctly identified direct imports but sometimes missed transitive instantiation via configuration files or environment-specific profiles.
Our validation involved running the application with debug logging for class loading during integration tests, then cross-referencing that against Mend's reachability report. The discrepancy wasn't critical, but it required us to adjust a few custom rules to treat certain internal package patterns as "always reachable" for safety. After that tuning, it's been accurate.
The real test was the quarterly compliance audit, where the external auditor sampled our suppressed vulnerabilities and we walked them through the class-loading proof. That passed without issue, so the initial optimism was more about our own internal complexity than a flaw in their model.
Your data on the 70% pipeline gate improvement is interesting, but it would be more valuable with the underlying hardware and baseline configuration details. A 70% reduction on a ten-minute scan is a different operational gain than on a two-hour one.
The trade-off you didn't mention is the audit trail for suppressed findings. When their algorithm marks a transitive dep as unreachable, you're trusting a proprietary model. We documented a 12-15% discrepancy in reachability analysis for internal libraries using dynamic loading patterns, which required manual rule adjustments. That risk score is useful, but you need to verify its logic for your specific architecture before it becomes a source of truth.
The operational gain is real, but it's contingent on accepting a new, different black box. The cost of verifying its output is the real price of the switch.
Your point on the six-month library normalization period is critical and often underestimated in migration plans. That operational drag from duplicate component warnings can derail a project's momentum.
I'd add that the quality of your SBOM baseline directly dictates that timeline. If you're coming from years of ad-hoc Black Duck scans with inconsistent policies, you're essentially starting from scratch. The cost isn't just Mend's support being slow, it's your team's time spent cleaning up historical data debt.
The SAST point is spot on. We treat it the same way, as a basic hygiene check. It's a checkbox feature, not a replacement for a dedicated SAST tool. Anyone expecting deep, context-aware analysis from it will be disappointed.
Yeah, the SBOM baseline cleanup is a huge hidden cost. We had to dedicate a sprint to just consolidating component IDs and purging old, inactive projects from our Black Duck instance before we even started the Mend import. Without that, the noise would've been unbearable.
>treat it the same way, as a basic hygiene check
Exactly. Their SAST is fine for catching the low-hanging fruit in a PR gate, but we never turned off our dedicated tool. It's not in the same league.
YAML all the things.