Everyone focuses on the direct deps. The real party is in the transitive chain, where you inherit the world's problems.
Most SCA tools just flatten your `go list -m all` and call it a day. That's useless noise. You need to see *why* a vulnerable lib is there, and if you can actually fix it. `go mod why` is your friend, but automating that across a fleet is the trick.
Here's the hack. First, get the graph:
```bash
go list -m -json all | jq -r '.Path + " " + .Version'
```
Then, for each flagged module, trace it:
```bash
go mod why -m
```
If the output doesn't show a direct import path from your main module, you're likely looking at an indirect dep you can't upgrade directly. Means you're stuck pressuring your direct dep's maintainers or using a `replace` directive, which brings its own special kind of pain.
The tools that understand this distinction are few and far between. They also tend to cost a fortune.
Prove it.
I'm a backend engineer at a fintech startup with about 40 devs. We run a dozen Go microservices in production, so I've been through this exact transitive dependency headache while trying to meet our security compliance.
Here's how I see the main contenders for real transitive scanning:
1. **Deep vs Shallow Scanning**: Most SCA tools we tried (like Snyk and Mend) treated indirect deps as a flat list, which was overwhelming. Dependabot would open 30+ PRs for a single CVE deep in the chain. Only one tool we tested, JFrog Xray, could actually map the full dependency graph and show the specific `go mod why`-style path a vulnerability took to reach our code, which cut our triage time by about 70%.
2. **Real Pricing & Hidden Costs**: The accurate graph-based scanners are enterprise-tier. We got quotes from $30-50 per developer per month for the platforms that do this well. The hidden cost is engineering time - the "free" or cheap tools required so much manual `go mod graph` and `why` analysis that it was a full day a week for someone.
3. **Deployment & Integration Effort**: If you're on GitHub, Dependabot is trivial to enable but it's the "noise generator." A platform like Snyk required about two days to roll out across our repos and pipelines. The biggest config gotcha was managing internal private modules - some tools just couldn't follow those links without a custom GOPROXY.
4. **Where It Breaks**: These tools fall down on "replace" directives. They often see the replaced module version and flag it, but miss that it's been swapped locally. We had several false positives a week because of this. Also, if your direct dep is stale and pinned, you'll get constant alerts for its transitive vulnerabilities you can't fix, which erodes trust in the alerts.
My pick for our startup is actually a hybrid: we use Dependabot for the direct dependency PRs (it's good at that) and run a weekly script that dumps `go list -m all` and cross-references with the govulncheck DB, tracing paths only for high/critical CVEs manually. It's not perfect, but it's free. For a team that can afford it, I'd point you to JFrog Xray.
To make a clean call, tell us your budget per dev per month and whether you're in a regulated industry that needs audit trails for every ignored CVE.
That pricing point is exactly what I'm worried about. At $30-50 per dev, it gets steep for a small team fast.
You mentioned JFrog Xray showing the specific path. Did you find that the graph visualizations actually helped devs understand the chain, or was it still a complex output that only a few specialists could use?
We're currently using a homegrown script around `go mod why`, but scaling it is the real problem, like you said.