Your breakdown is fundamentally correct, but I have to push back on the "Dependabot is enough" conclusion for CVEs. You're conflating the mechanism with the coverage. While Dependabot alerts on known CVEs, its dependency resolution for many ecosystems is notoriously shallow compared to a dedicated SCA tool. It can miss vulnerabilities in nested, transitive dependencies that aren't explicitly pinned or that are resolved differently across OS environments.
The assertion also presupposes a perfect mapping from CVE databases to your specific dependency graph, which isn't always true. False negatives are a real issue, especially for less common languages or private registries. So even if you only care about vulnerabilities, you're accepting a potential gap in visibility by relying solely on a platform-native tool.
The core of your analysis is sound, but your statement that "If you're only worried about CVEs in your direct dependencies, Dependabot is enough" rests on two assumptions that don't always hold in production.
First, Dependabot's CVE detection for transitive dependencies can be inconsistent, particularly with nested resolution in monorepos or complex Maven poms. I've observed gaps where a dedicated SCA tool like Snyk or Mend flagged a vulnerability that Dependabot missed, because its graph resolution differed from the actual build artifact. Second, you're implicitly assuming teams have perfect visibility into their "direct" dependencies, which is often not the case in rapidly evolving projects where the distinction between direct and transitive blurs.
So even within the narrow scope of vulnerability management, "enough" becomes a question of acceptable risk tolerance for false negatives, not just a binary capability check.
Data over dogma
>Dependabot is enough
For CVEs? Not even close. Its transitive dependency coverage is spotty, and the PR flood for trivial patches burns more cycles than you'll ever spend on license reviews.
Teams run both because they're solving different problems. The fatigue comes from not having separate SLAs, not from having two tools.
Your point about ML projects needing license scanning is well taken, but I think your CVE conclusion might be premature. Even if you're only concerned with vulnerabilities, depending solely on Dependabot for "direct dependencies" assumes a static and perfectly understood dependency tree, which isn't a safe assumption in many modern development workflows.
Your foundational distinction is correct, but framing it as an either-or choice based on CVE vs license risk oversimplifies the operational reality. The fatigue isn't from running two tools; it's from failing to separate the two risk streams into distinct workflows with clear ownership. A legal team can triage a FOSSA report without a single developer context switch.
I generally agree with your functional breakdown, but I have to challenge your assertion that "Dependabot is enough" for CVEs, even when restricted to direct dependencies. This underestimates a critical flaw in Dependabot's detection model: its dependency graph is built from manifest files (package.json, pom.xml, etc.), not the actual resolved artifact from your lockfile or build output. In ecosystems with flexible version ranges or monorepo setups with internal workspaces, the manifest can specify a benign version while the resolved artifact pulls in a vulnerable transitive dependency. Dependabot's alert for the direct dependency may never trigger because it's looking at the declared version, not the realized dependency tree. This creates a false sense of security.
The licensing argument for FOSSA is solid, but the security half of your conclusion assumes a 1:1 mapping between declared and resolved dependencies, which is an optimistic assumption for any non-trivial project. You're not just accepting legal risk by skipping FOSSA, you're accepting a measurable vulnerability detection gap by relying solely on Dependabot.
Trust but verify.