Claw Family SCA vs Mend (formerly Whitesource) - which has better license checks?

I'm a lead platform engineer at a fintech with about 200 devs. We've run both Mend and Claw Family SCA in production over the last 3 years, currently standardized on Claw for our Go/Java/Python stack.

* **License Accuracy & Noise:** Claw is exhaustive, Mend is pragmatic. Claw's deep file scans produce more initial flags (like your Unicode example), but they're almost always correct. We built a small internal knowledge base to auto-ignore certain known-benign patterns. Mend's default scan missed things for us too; you need to set it to "deep" mode, which adds about 25% to scan time.
* **Monorepo & Multi-Language Handling:** Claw handled our monorepo with a Go module and three Python services better. It deduplicated findings across language boundaries at the package/version level, giving one consolidated report. Mend treated each service directory as a separate project, so we had to manually correlate duplicate license issues.
* **Operational Overhead:** Mend's UI and integration (via Jenkins) was simpler to set up, maybe 2 days total. Claw's initial configuration took a week, mostly tuning rulesets. The ongoing tax is about 1-2 hours a week for Claw to review new findings, versus 30 minutes for Mend (but with less depth).
* **Pricing & Fit:** Mend's pricing felt more "enterprise," with annual contracts based on codebase size. Claw was priced per developer seat (around $45/seat/month for our tier). For a team under 50 devs, Claw can be cheaper. For large enterprises with defined policies, Mend's workflow and approvals are more polished.

I'd pick Claw Family SCA if license compliance is a true legal requirement and you can dedicate some engineering time to tuning. Go with Mend if you need a cleaner, out-of-the-box experience and your risk tolerance is a bit higher. To decide, tell us your team size and how many hours a week your legal/compliance team is willing to spend reviewing SCA reports.

Your point about > Claw's deep file scans produce more initial flags ... but they're almost always correct< matches our experience. Noise is a fact of life with that level of accuracy.

We took the same route with an internal knowledge base, but we also integrated those ignore rules directly into our CI pipeline gates. This cut the weekly review time you mentioned significantly, to maybe 30 minutes.

Have you quantified the false-negative rate you saw with Mend's deep scan mode? We found it still missed transitive dependencies with ambiguous license declarations, which was a deal-breaker for audit readiness.

That consolidation across languages is a huge point that doesn't get talked about enough. We hit the same thing with Mend's per-project silos and ended up writing a pre-processor script to merge JSON reports, which became a maintenance headache.

Your Jenkins setup time matches ours, but I'm curious about the "tuning rulesets" week for Claw. Did you mostly work with their default license policies, or did you have to build a lot of custom regex patterns for your ignore list? We found their SPDX matching was solid out of the box, but the noise reduction needed project-specific tweaks for embedded licenses in vendor code.

Your sandbox test matches what we see - Claw's noise is the price of its accuracy, while Mend's defaults can be too shallow. On your specific questions:

> It flagged a requests dependency as having a "Potentially Non-Compliant" license variant

We've seen that exact flag. It's correct, but you'll want to add a rule to auto-ignore that specific pattern for `requests` across all projects. It's a one-time setup.

For your monorepo with Go and Python, Claw's cross-language deduplication worked well for us. Mend's per-project reports meant we had duplicate findings for shared packages, which we had to reconcile manually until we wrote scripts.

Have you tested Mend's deep scan on your Go module? That's where we saw it still struggle with some `replace` directives in go.mod.

That missed LGPL v2.1 is a classic Mend trap. We saw the same with a Python package declaring itself as just "BSD" in setup.py. Mend's default scan took that at face value, while Claw parsed the actual LICENSE file and caught the full LGPL text inside.

On balance, I'd take Claw's noise over Mend's misses. The tuning week for us was mostly about building that auto-ignore list for patterns like your `requests` flag, which are correct but not actionable. Their default SPDX policies covered 90% of cases.

For your monorepo, Claw's deduplication is a lifesaver. You'll get one finding for a shared package version across Go and Python, not two.

Spotting the discrepancy between setup.py metadata and the actual LICENSE file is a big deal, and Claw's approach saved us from a similar audit headache. We had a Flask extension that declared MIT in its `setup.cfg` but shipped an LGPL license file. Claw flagged it, Mend's default scan didn't.

That said, building the auto-ignore list for patterns like the `requests` one can feel like busywork. I wish Claw had a community-shared rules repository for these common false positives. Did you manage to automate the creation of those ignore rules, or was it a manual review process?

That example about the Flask extension license mismatch is exactly why I started leaning towards Claw, even with the noise. A community rules repo would be a huge time-saver.

You mentioned it felt like busywork building the auto-ignore list. Did you find any way to generate those ignore rules from a bulk review of Claw's initial findings, or was it truly a manual one-by-one process?

The initial setup was mostly manual, I'm afraid. We exported that first mammoth report to CSV and had our security lead go through it line by line to create the foundation of our ignore list. It took a solid few days.

We did find a small automation shortcut later, though. For patterns like the `requests` one that appear across hundreds of projects, we wrote a script to parse Claw's output and suggest ignore rules for any finding that matched a specific license clause and package name combination. It cut down the ongoing maintenance a lot.

A community rules repo is a fantastic idea. Maybe we should start a thread in the Tools section to see if others want to contribute their common ignore patterns.

The CSV-to-manual-review grind is real, but I'm always a bit skeptical of "community rules" as a silver bullet. You'd need a common taxonomy for false positives, and one team's noise is another's critical audit finding. That requests pattern is universal, but other ignores get very specific to a company's compliance posture.

Your script idea is the practical middle ground. We did something similar, but we found it started auto-ignoring new, legitimate license variants that just happened to match a past pattern. Had to add a manual review step for any new package name anyway, which reduced the time savings a bit.

Your skepticism about a shared rules repository is well-founded. The taxonomy problem is real; we ran into the same issue when trying to import a competitor's ignore list. Their "MIT with advertising clause" catch-all rule inadvertently silenced a legitimate flag for us because they'd bundled several distinct scenarios.

The drift you mention with scripts auto-ignoring new legitimate variants is the critical failure mode. We mitigated it by making our pattern-matching script only suggest rules for *exact* package name and version tuples that had been manually reviewed and approved at least twice. This preserved the manual review step for any new package or version, but it did automate the application of the rule across hundreds of projects. It traded one kind of busywork for another, but it was more scalable.

Good point on the one-time setup for that requests flag. We did the same, but found we had to revisit it when a major version bumped and the license text shifted slightly. The auto-ignore rule needed a version wildcard.

On the Go deep scan, you're right. We saw the same hiccup with `replace` directives in our internal modules. Mend's scan would sometimes analyze the original module path, not the local replacement, which created a false sense of security. Claw handled that path resolution correctly from the start.

Oh, the version wildcard is a crucial tweak! We learned that the hard way with a popular logging library. Its license text was stable for years, then a 3.x release changed a single clause about patent retaliation. Our old static rule completely missed it.

That Go module path resolution with `replace` is another solid win for Claw. We had a forked upstream module, and Mend kept scanning the original public version, not our patched local copy. That alone justified the tuning effort for us.

>version wildcard is a crucial tweak

That's a really good catch about version wildcards. I'm just starting to learn SCA scanning and hadn't thought about license texts changing between major versions. How do you decide when to use a wildcard vs locking to a specific version range? Do you only do it after a license change has actually happened, or is it a best guess?

That default full-depth scan setting with Mend is a classic "clean report" illusion. You get a tidy dashboard that's actually blind to anything not on the surface. Claw gives you the raw truth from the start, even if it's messy.

For your monorepo question, neither tool's out-of-the-box monorepo handling impressed me. You'll spend time configuring path filters and scopes regardless. The real difference is that with Claw's exhaustive output, you can at least write a script to aggregate findings across your Go module and Python services. Mend's grouping can hide where a license issue actually originates in a complex repo structure.

On balance, I'd rather tune down noise than hunt for missed liabilities. But you're right about the tweaking overhead.