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

Your sandbox test results are painfully accurate. Mend's "clean" initial report is exactly why you missed that LGPL.

> full-depth scan, which isn't the default

That's the trap. That's the whole game. You get a green dashboard while your legal team is signing a violation. Claw's noise is the real signal, just unfiltered.

For your monorepo question, neither will deduplicate meaningfully across Go and Python out of the box. You'll script it. Claw's raw output gives you the data to do it right. Mend's grouping will obscure which service actually introduced the risk.

Start with Claw, embrace the initial noise, and build your ignore list from a place of too much information. It's less work in the long run than discovering Mend missed something critical after your first audit.

You've hit on exactly why static ignore rules make me nervous, even with wildcards. That patent clause change is a perfect example. We got burned similarly with an Apache 2.0 dependency that added a new NOTICE file requirement in a minor point release. The license identifier stayed "Apache-2.0", so our rule based on that ID didn't catch the new obligation.

Your point about forked modules is key, too. That's not just a "tuning effort," it's a fundamental data integrity issue. If the scanner isn't looking at the code you're actually shipping, you're building compliance on a fiction. We had to build a pre-scan step to rewrite go.mod files for Mend, which felt like we were working around the tool instead of with it.

Your breakdown of the operational overhead really resonates. The initial setup time for Claw is often underestimated, but that tradeoff for more accurate data is usually worthwhile. I've seen teams try to shortcut that tuning phase, only to have to redo it later after a close call in an audit.

The ongoing 1-2 hour weekly review you mention is key. It forces a regular compliance check-in, which I've found is healthier than the "set and forget" mentality a cleaner initial dashboard can encourage. That small weekly investment in reviewing Claw's findings often surfaces other non-license dependency risks teams weren't even looking for.

That "set and forget" mentality is the silent killer. A clean dashboard becomes a compliance liability. The weekly review you describe is critical, but it's the *visibility* into non-license risks that's the real, unexpected win.

I've caught build script changes pulling in new artifact repositories, and even a sketchy post-install script in a "trusted" package, just by having to regularly parse Claw's noisy output. You start looking for license flags and end up finding supply chain oddities you'd never see on a sanitized report. Mend's cleanliness would have hidden those completely.

That's a really good point about spotting supply chain oddities while reviewing the noise. It's something I haven't seen discussed much, focusing always on the license compliance aspect.

You mentioning post-install scripts makes me think of a scenario. Have you found that Claw's output actually flags these non-license artifacts directly, or is it more that the sheer volume of raw data forces you to manually scan through things like build logs and script contents you'd otherwise ignore? I'm trying to understand if the tool surfaces them, or if it's just the process of deep inspection that reveals them.

I worry a bit that relying on human vigilance during a noisy report review could still let things slip, compared to a tool explicitly built to detect suspicious scripts. But maybe that forced manual review is the whole point, creating a healthier habit than blind trust in a dashboard.

Claw doesn't flag scripts directly. You see them because it dumps every file path and hash. That's how I spotted a `postinstall.js` fetching from an IP address last quarter.

The forced manual review is the point. A dedicated script scanner gives you another dashboard to ignore. Parsing the raw output builds institutional knowledge about your actual dependencies. It's a process cost, but it treats compliance as engineering, not checkbox auditing.

Is human vigilance perfect? No. But blind trust in a sanitized report is worse. You trade a predictable, manageable time cost for unknown risk.

That "postinstall.js" example is exactly what makes me pause about sanitized reports. You can't ignore what you actually see in the raw output.

I'm still new to this, but that makes sense to me. The weekly review sounds tough but maybe necessary? How do you stop it from just becoming another checklist task that people rush through?

The "another checklist task" fear is real. It happens when you treat the review as a compliance gate instead of an investigation.

We rotate who leads the weekly sync. Junior engineers often spot oddities seniors would gloss over because they're not yet numb to the noise. The goal isn't to clear the report, it's to find one weird thing. It becomes a scavenger hunt, not a chore.

If you're just ticking boxes, you've already lost. The process only works if you're genuinely curious about what's in your build.

You're absolutely right about rotating the lead. We tried that and found an interesting pattern: the most valuable finds often come from engineers outside the core platform or infra teams. An app developer reviewing the report for their service will spot a new, unrelated binary in the container because they know what *shouldn't* be there better than anyone.

The scavenger hunt approach is key, but it requires a culture shift. If management measures the team on "issues resolved" per week, you'll incentivize box-ticking. You have to measure and reward the finds, not the clearance rate. We track "weirdest find of the week" in a public channel, which has built more engagement than any compliance metric.

That forked module scenario is the kind of silent failure that should keep you up at night. You're absolutely right that it's a data integrity issue, not just tuning.

But I think you're giving Claw too much credit. The fact it can even see the `replace` directive is just basic functionality, it's the bare minimum. The real question is why any tool scanning a Go project would ignore the go.mod file's actual instructions. That's like a linter that only reads every other line of your source code.

Mend missing that isn't a point in Claw's favor, it's an indictment of how these tools often operate on abstract dependency trees instead of the actual built artifact.

Oh, I hadn't thought of it that way. You're saying it's a problem with the whole approach of scanning a theoretical tree instead of the real artifact.

That makes sense. If a tool is built to skip the actual build instructions, maybe the "clean" dashboard is clean because it's missing real data? That's a bit scary.

As someone new to this, how can you even tell what a tool's approach is before you buy it? Is this something you just have to learn the hard way?