I've been evaluating Software Composition Analysis (SCA) tools for a data platform team managing a complex monorepo. The primary codebase houses all our data pipeline orchestration, custom Spark connectors, and utility libraries, resulting in a dependency graph with over 500 direct and transitive packages (mix of Java/Scala via Maven, Python via pip, and some Node.js). Our builds are orchestrated through a unified CI/CD system.
We trialed Mend (formerly WhiteSource) alongside two other major vendors. The initial setup was straightforward for a simple project, but at monorepo scale, we encountered significant performance and accuracy issues:
* **Scan times became prohibitive**, exceeding 45 minutes, which broke our CI gate.
* **Deduplication across sub-projects was poor**, flooding the dashboard with repeated vulnerabilities for the same library used in multiple services.
* The **dependency resolution for Maven multi-module builds** seemed inconsistent, missing several transitive dependencies that other tools caught.
I am curious if others have pushed Mend to similar scales. Specifically:
* What configuration strategies work for monorepos? Did you use a unified manifest approach, or trigger scans per sub-directory?
* How did you handle performance? We attempted to use the `--shallowScan` option, but that led to missing deep transitive vulnerabilities.
* Was the accuracy of the vulnerability mapping sufficient for a heterogeneous stack, or did you require significant manual overrides?
Our current workaround is a pre-scan step that generates a consolidated SBOM using `cyclonedx-maven-plugin` and `cyclonedx-python-lib`, then feeds that to the SCA tool. This improved Mend's scan time to ~12 minutes, but it feels like an architectural workaround.
```xml
org.cyclonedx
cyclonedx-maven-plugin
2.7.9
compile
makeAggregateBom
```
I'm looking for concrete feedback on throughput and accuracy at this scale. Graphs of scan time vs. number of dependencies or false-positive rates would be ideal.
We've seen similar scaling challenges with Mend in large monorepos. The key config that helped us was bypassing their default project detection entirely.
Instead, we generate a unified SBOM for the entire monorepo as a separate CI step (using Syft) and then feed that single artifact to Mend for scanning. This solved both the deduplication issue and cut scan time by about 70% because Mend only processes one "project." The trade-off is you lose granular, per-sub-project reporting unless you build it yourself.
For Maven multi-module issues, we had to force the use of the `dependency:tree` output because their auto-resolver struggled with our custom parent POMs. It's more work upfront but gave consistent results.
Keep it real, keep it kind.
Generating a unified SBOM first is the right move. We do the same with cyclonedx-cli, but for Maven we had to lock it to a specific Java version during generation. The version you run `mvn dependency:tree` with can alter the resolved tree for some plugins.
The real bottleneck for us wasn't the scanning, it was the policy evaluation step after. With 500+ deps, the default rule set caused timeout issues. We had to strip it back to critical severity only for the CI gate. Everything else gets handled in the daily aggregate scan.
YAML all the things.