Skip to content
Notifications
Clear all

Is Mend worth it for a Python monorepo?

1 Posts
1 Users
0 Reactions
5 Views
(@oliviar)
New Member
Joined: 1 week ago
Posts: 2
Topic starter   [#2971]

I've been evaluating Mend (formerly WhiteSource) for the past six months to manage security and licensing across our rather sizable Python monorepo, and I wanted to share a detailed breakdown of our experience for anyone considering a similar path. Our codebase is a single repository containing over a dozen interconnected services and libraries, all in Python, using a mix of Poetry and pip for dependency management.

The core question is whether Mend's approach aligns with the unique complexities of a monorepo structure, where dependency trees can be deep and intertwined, and where a vulnerability in a low-level shared library can potentially affect many projects at once. From a security and compliance standpoint, the centralized visibility is Mend's strongest suit. The ability to see all vulnerabilities and licenses across every service in one dashboard, and to track remediation as it propagates through the dependency graph, has been invaluable for our compliance audits.

However, integration required thoughtful configuration to work seamlessly. The out-of-the-box scanning for a monorepo can be noisy if not directed properly. We found success by creating a unified configuration file at the root that explicitly defines each component's path and package manager. This helped Mend understand our structure and produce accurate, component-specific reports.

Here’s a simplified snippet of our `.whitesource` configuration structure:

```yaml
# .whitesource at monorepo root
apiVersion: 1.0
config:
scanSettings:
projectToken: YOUR_PROJECT_TOKEN
baseBranches:
- main
scanConfigs:
- monorepo: true
rootDirectory: .
includes:
- "service-a/pyproject.toml"
- "service-b/requirements.txt"
- "shared-lib/pyproject.toml"
```

**Key takeaways from our implementation:**

* **Proactive Vulnerability Management:** Mend's continuous monitoring and automated PRs for updates are excellent, but you must tune the severity thresholds. For a monorepo, a critical fix in a shared library should trigger actions across all consuming services, which Mend handles well.
* **License Compliance Clarity:** The license risk reports are thorough, categorizing licenses by policy (e.g., permissive, copyleft). This is crucial for a monorepo that might bundle dependencies for various distribution purposes.
* **Performance & Scanning Overhead:** Initial full scans are time-consuming. Incremental scans on PRs are faster, but you need a robust CI pipeline. The Mend agent adds a step, so factor in those compute minutes.
* **The "Noise" Challenge:** Without careful path exclusions (for virtual environments, build artifacts), you'll get false positives. Defining precise `includes` and `excludes` in the config is a mandatory first step.
* **Remediation Workflow:** The suggested fixes are sometimes too aggressive (major version jumps). We've adopted a practice of reviewing its automated PRs, especially for core dependencies, to ensure we don't introduce breaking changes across the monorepo.

Is it worth it? For us, the answer is yes, but with caveats. If your Python monorepo is critical to your business and you operate under strict security or compliance requirements (SOC2, GDPR, etc.), Mend provides the consolidated oversight and audit trail that is very difficult to replicate with a patchwork of open-source tools. The initial setup and tuning effort is significant, but the ongoing reduction in manual toil for vulnerability tracking and the assurance of comprehensive license compliance justify the investment. For a small, simple repository, it might be overkill, but for a complex monorepo, it becomes a powerful central pillar for a Zero Trust approach to software supply chain security.



   
Quote