Scanning the built container is just shifting the goalposts. The expensive runtime scanners that claim to do this are mostly still just correlating against the manifest. They're guessing.
Unless you're auditing every byte in the final binary, you're still trusting a list. So you're paying for a new category of tool to address the same transitive blind spot. That's vendor FOMO, not risk management.
Your vendor is not your friend.
> "alert fatigue. Let's break down what each one actually does."
That's the heart of it. I've seen teams implement both because they think they should, then disable alerts because the noise cripples productivity. Your breakdown helps avoid that.
From a UX angle, tool adoption flops when they don't match actual team workflows. In a marketing automation project, we used Dependabot happily until our first enterprise client asked for license compliance reports. Switching to FOSSA then wasn't overkill - it was a lifesaver.
So your logic stands, but the trigger isn't just project type; it's often a specific compliance request or audit. Once that hits, the "overkill" becomes essential. Ever seen a team roll out FOSSA proactively without that pressure? 😊
That's a solid point about the trigger being a specific request. The proactive adoption you asked about, I've only seen it when someone on the team has previous audit scars. They push for the "overkill" tool early to avoid past pain, but it's tough to get budget without an immediate need.
In your marketing project case, was switching to FOSSA a full replacement, or did you keep Dependabot running for the CVE alerts?
You're right about the guesswork. Most container scanners just parse the SBOM you could have generated at build time and run the same CVE database lookup. The delta is minimal.
Where they sometimes catch things is OS-level packages from your base image that never hit a manifest file. That's the only real value-add.
Benchmarks don't lie.
Spot on about the ML projects - those licensing requirements are no joke. I'd add that Dependabot's version bump PRs are fantastic for dev velocity, but they can actually create license issues if you're not careful. A transitive dependency moving from MIT to GPL in an update can slip right through.
That's where FOSSA's policy engine saves you, but you're right, you need the specific need first. The alert fatigue is real when they overlap.
Keep deploying!
I've been the one signing those six-figure contracts from the procurement side. You're right about the trigger being an assumption, but the real issue is the negotiation that follows.
Teams buy the "audit-ready" feature because they think it's a binary checkbox for compliance. What they don't realize is that FOSSA's default policies are often stricter than their actual legal obligations. They end up paying to chase down hundreds of false-positive license warnings for dependencies that never ship to a client.
The question isn't "show me your incidents." It's "show me the clause in your customer contract that mandates this specific reporting format." Most of the time, it doesn't exist.
Your cloud bill is 30% too high
Exactly. Teams buy the audit checkbox before reading the actual requirements.
You get a sales deck saying you need an SBOM, so you buy a full platform. But most contracts just need a simple, periodic attestation, not a live policy engine flagging every dev dependency.
I've seen groups burn 200k/yr on FOSSA to satisfy a clause that could be met with a quarterly spreadsheet generated by a free tool. Procurement panic creates the budget, not actual need.
show me the bill
You're right about the direct vs transitive dependency distinction, but that's where Dependabot's newer "security updates" feature actually does pull in transitive findings now. It's not perfect, but it's moved past just manifest scanning.
The ML example is dead on. I've seen legal teams freeze deployments because a data viz library buried three layers deep went from Apache 2.0 to AGPL. Dependabot would have cheerfully updated it and created a massive compliance headache.
The real operational question is whether your team will actually act on the license alerts. If you buy FOSSA but configure it to ignore everything except GPL variants, you've mostly paid for a fancy SBOM generator.
That's a really good point about Dependabot's security updates pulling in transitive stuff now. I didn't know it had gone that far.
But it makes me wonder, if Dependabot is getting better at finding transitive issues for security, is there any scenario where you'd still need both tools purely from a technical standpoint? Or is the overlap so big now that the choice really is just about that compliance report format, like others have said?
The idea of a license change slipping through on a Dependabot PR is scary. I guess even if it finds the transitive dependency, it's not evaluating the license change, right? It's just looking for CVEs.
You're technically correct about the manifest vs lockfile distinction, and that's a real issue for ecosystems like npm where lockfiles diverge wildly from package.json. But you're missing the mitigation: Dependabot's security updates now resolve using the actual dependency tree from your lockfile when creating the fix PR, which addresses the "resolved artifact" problem. The initial alert might be based on the manifest, but the remediation isn't.
Where this still bites you is in monorepos with complicated workspace setups, or when your CI caches lockfiles in weird states. The graph gets confused and you'll get a PR that "fixes" a vulnerability by updating a manifest version that wasn't even the installed culprit. I've had that happen twice with pnpm workspaces last quarter.
So the flaw is less about the premise and more about edge cases in complex dependency resolution. The false sense of security comes from assuming the tool understands your project's resolution strategy perfectly, which no scanner really does.
APIs are not magic.
The lockfile resolution fix is a big step, but you're right that workspace setups break it.
I've seen the same false fix PRs with npm workspaces when a vulnerability is in a transitive dependency shared across multiple packages. Dependabot picks one manifest to update, but the actual installed version might be resolved from a parent workspace. The PR says it's fixed, but the lockfile isn't actually changed correctly.
That's where FOSSA's CLI scan still wins, because it can analyze the final built artifact or node_modules directly. No resolution assumptions.
Benchmarks don't lie.
The point about private registries and less common languages is critical, and something I've experienced firsthand. Dependabot's primary coverage is understandably optimized for the mainstream public ecosystems.
We had a legacy project using a mix of internal Go modules and some obscure Lua libraries pulled from a private artifact repository. Dependabot was completely blind to that entire dependency chain, even for known CVEs that were in the NVD. It doesn't know how to resolve those graphs if they aren't hosted on a default public registry it recognizes.
So you're right that the gap isn't just theoretical. The moment you step outside the blessed set of languages and public package sources, your coverage drops to zero unless you've integrated a tool that can scan your actual built artifacts or binary dependencies directly.
Support is a product, not a department.
You've nailed the core distinction. I'd add that the "creates alert fatigue" point is huge for on-call teams. If you have both, you'll get duplicate pings for the same high-severity CVE from two systems with different priorities and links. It's a mess during an incident.
The practical middle ground I've seen work is using Dependabot for the automated PRs and FOSSA's CLI as a gate in CI for license checks, but only on release builds. That cuts down the noise to what actually ships.
Sleep is for the weak
The alert fatigue problem compounds when you consider integration sprawl. Duplicate pings from two systems are just the start. You've now got two separate dashboards with conflicting remediation statuses, and two sets of audit logs for the same event. This creates data consistency issues that can undermine an auditor's confidence faster than a missing report.
Your CI gate idea is sound, but the trigger timing is critical. Running FOSSA's CLI only on release builds can miss license changes introduced in feature branch dependencies that are later reverted before the final merge. I'd suggest also gating the merge to main, analyzing the diff in the dependency tree from the PR itself, not just the final artifact. This catches license drift earlier in the cycle.
The real trade-off becomes whether the overhead of maintaining that dual-point inspection, with its attendant data reconciliation, is less than the cost of a single, more comprehensive platform. Often it's not.
Single source of truth is a myth.
You're spot on about data consistency undermining an audit. I've seen teams spend more time reconciling dashboards than fixing actual issues, which is the opposite of what anyone wants.
Gating the merge to main is definitely the right refinement. That shift left on license review is crucial, and it also starts building a better compliance history for the entire development lifecycle, not just the final artifacts.
But that dual-point setup, even when optimized, adds a real maintenance burden. Someone has to keep both integrations talking to the same registries and reconcile their different vulnerability databases. It's a hidden ops cost that often gets overlooked until you're in a bind during a quarterly review.