Looking to consolidate our SCA tools. Currently running Black Duck and FOSSA in parallel on a large monorepo (mix of Java, Go, Node). The results are wildly different.
Black Duck's deep scan finds more, but the noise is significant. FOSSA is faster and the policy engine is cleaner, but I'm concerned about missed transitive dependencies. Has anyone done a thorough comparison on dependency accuracy and policy enforcement in a complex monorepo setup? I need hard data on false positives/negatives, not sales pitches.
Specifically, how do they each handle workspaces, lock files, and nested projects? Our audit trail requirements are strict, so the clarity of the bill of materials output matters.
Trust, but audit.
We ran a similar comparison about 8 months back on a monorepo with ~400 microservices. The discrepancy you're seeing is typical.
On dependency accuracy, Black Duck consistently identified 15-20% more transitive dependencies, but our review found that roughly 60% of those were development-only packages or build tooling that never made it into a runtime artifact. That's the noise. FOSSA's approach with lock file parsing was more accurate for our actual runtime SBOM, but it did miss some nested Go modules that weren't in the root `go.mod`.
For audit trail clarity, FOSSA's BOM output (JSON/SPDX) was far easier to map back to specific lock files and paths. Black Duck's data was comprehensive but a nightmare to trace to a specific `pnpm-lock.yaml` in a nested workspace. Their policy engine is powerful, but the alert fatigue was real.
If your compliance needs are strict on *runtime* dependencies, FOSSA with a dedicated pipeline step for each service build might be sufficient. If you need to track every single dev dependency for a full legal review, Black Duck's depth wins, but you'll need significant tuning.
Numbers don't lie
Your point about audit trail clarity really hits home. We went through that exact "nightmare to trace" scenario last year with Black Duck when we had to prove the origin of a specific license violation in a single npm workspace. The extra noise made the audit take three times longer than it should have.
I think the critical trade-off you've outlined is between legal completeness and operational efficiency. We ended up using FOSSA for CI/CD policy gates and scheduled a quarterly Black Duck "legal deep dive" scan, just for full compliance documentation. Splitting the use case like that cut down our alert fatigue drastically.
How did you handle the nested Go modules FOSSA missed? Did you add a pre-scan script to discover them, or just accept the gap?
hannah
Your split-use case approach is fantastic. We landed on something similar after our own audit nightmare. That "noise" isn't just distracting - it actively erodes trust in the data, making teams ignore the critical alerts too.
For the nested Go modules with FOSSA, we did have to build a lightweight pre-scan script. It's essentially a find command that walks the monorepo for any `go.mod` not at a predefined root and writes a simple manifest file. FOSSA then consumes that as a custom scan target. It added maybe five minutes to our pipeline but closed the gap completely. Happy to share the basic logic if you want.
I'd push back slightly on quarterly Black Duck scans, though. In fast-moving repos, we found quarterly left us exposed for too long. We shifted to using it monthly, but only on the `main` branch after a release cut, which feels like a decent balance between legal diligence and team sanity.
Measure twice, automate once.
Interesting you're seeing such big differences. That noise from Black Duck is exactly what's killing our team's trust in alerts right now.
How are you handling the audit trail for those extra dependencies? I'm wondering if a ton of them are build tools like user458 said, which would mean they shouldn't be in a runtime SBOM anyway.
The lock file handling is my biggest worry too, especially with pnpm workspaces. Has FOSSA been reliable for you there?
Still learning.