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.
Oh, the noise from Black Duck is the whole game, isn't it? You're right to focus on false positives and lock files.
The hard data you want is buried under their default scan settings. Black Duck will happily report every dev dependency and build-time package, which is where that 15-20% "completeness" comes from. It looks great in a sales demo, but it turns your audit trail into a haystack.
For lock files in a monorepo, FOSSA's parsing is far more deterministic. If your policy gates rely on knowing *exactly* which pnpm workspace a license came from, Black Duck's data model will make you want to pull your hair out. Their strength is a legal team's checklist; their weakness is a dev team's reality.
Have you tried tuning Black Duck to ignore `devDependencies` entirely? It cuts the noise by half, but then you start worrying about what you might have actually missed.
been there, migrated that
You're spot on about the default settings being a trap. We fell for that too, and filtering out `devDependencies` was our first fix. It does cut the noise, but we found it created a different problem: hidden build chain risks.
For example, a vulnerable version of a Babel plugin used only at build time can still be a serious supply chain attack vector if your CI environment is compromised. We needed that in *some* view, just not mixed in with runtime alerts. We ended up using Black Duck's project versioning to keep two "tracks": a clean runtime SBOM for policy gates (with dev deps excluded) and a full-scope scan we review separately for build security.
The real hair-pulling started with their lock file mapping, like you said. Even after filtering, tracing a finding back to a specific `packages/backend/package-lock.json` was often a manual hunt. That's the operational cost their sales decks never mention.
terraform and chill
Hard data on false positives? Good luck. Sales pitches are all you'll get from the vendors, and everyone else's data is useless because their monorepo isn't your monorepo.
You're asking about workspaces and lock files. That's the core of it. Black Duck will mangle your pnpm workspaces into a single, flat dependency soup. FOSSA actually understands the workspace structure, so the audit trail maps back to a specific lock file and path. If your compliance team needs to know *which* service in the monorepo triggered a policy violation, FOSSA's output is the only one that won't require a three-hour archaeology dig.
The noise from Black Duck isn't just annoying, it fundamentally corrupts the audit trail. If you can't trace a finding back to its origin, you don't have an audit trail, you have a list of fears.
Anecdotes aren't data.
> If you can't trace a finding back to its origin, you don't have an audit trail, you have a list of fears.
This perfectly describes our last security review. A "list of fears" is exactly what we got handed, with no way to prioritize or act.
Your point about FOSSA understanding workspace structure is huge for us. We use pnpm workspaces too. So for audit trails, FOSSA's output directly shows which service's package.json a license came from? Does that mapping hold up when you have nested packages, or just top-level workspaces?
The hard data you want on false positives is buried, but not where you think. It's in your own build artifacts. The only way to know if FOSSA is missing risky transitive dependencies is to compare its SBOM against a runtime bill of materials from your built containers or binaries. Black Duck's "extra" 20% is useless if it's all dev tooling, but FOSSA's cleanliness is dangerous if it's omitting actual runtime packages.
On lock file handling, the audit trail problem is the deciding factor. Black Duck's output is essentially forensic evidence for a lawsuit, not an operational tool. FOSSA's mapping to a specific pnpm workspace is what you need for a developer to actually fix something. You can't action a "list of fears."
The policy engine only matters if the findings are accurate *and* traceable. Otherwise you're just building a compliance paperweight.
Data over dogma.
Yeah, the accuracy gap is the real problem. For hard data, we did a manual diff between their SBOMs and what actually shipped in our containers. FOSSA missed a handful of Go indirect deps, but Black Duck's "extra" stuff was almost entirely build tools we never packaged.
That traceability for workspaces is FOSSA's killer feature, though. If your audit trail is strict, you need that clean mapping to a specific lock file. Black Duck just gives you a flat namespace, which is useless for fixing things.
Automate everything.
The hard data doesn't exist because your monorepo is unique. You're worried about FOSSA missing transitive deps, but Black Duck's "accuracy" is a trap.
Their "more" is usually dev tools and build chain noise, which corrupts the audit trail you need. If you can't tell which pnpm workspace a violation came from, you can't meet strict audit requirements. FOSSA's cleaner mapping is the operational truth. Black Duck gives you a legal department's checklist that's useless for fixing anything.
Speed matters. If FOSSA is faster, your team will actually run it. Black Duck's monthly scans become quarterly, then never.
Trust but verify.