Question 1

Does govulncheck catch vulnerabilities in indirect dependencies?

Accepted Answer

Yes, with an important caveat. govulncheck ./... will flag any vulnerability in any dependency (direct or transitive) if your code's execution path might reach it. But with caveats: if a dependency exports a method that calls vulnerable code, and you call that method, govulncheck flags it. But if you call the exported method without hitting the vulnerable code path, govulncheck might not flag it (though this is rare). Use govulncheck call graphs for detailed analysis.

Question 2

Can I use go get to patch a transitive dependency directly?

Accepted Answer

Not easily. If you want to force a specific version of a transitive dependency, you add a require directive to go.mod:

go
require (
  github.com/lib/pq v1.10.0           // Direct dependency
  golang.org/x/net v0.0.0             // Forced version (transitive)
)

Then run go mod tidy. But this is a band-aid — the better fix is to update the parent package that brings in the vulnerable transitive dependency. Talk to the parent package maintainers, or consider forking if they're unresponsive.

Question 3

What's the difference between `go.mod` and `go.sum` for scanning?

Accepted Answer

go.mod declares version constraints. go.sum records exact hashes. For scanning, go.sum is authoritative — it represents what actually gets built. If you only have go.mod, scanners must resolve versions (which might resolve differently in different environments). Always scan with both files.

Question 4

My service imports a package that's already deprecated. Is that urgent?

Accepted Answer

Not immediately, but it's a ticking clock. Deprecated packages stop receiving security patches. Check if there's a recommended replacement. Plan a migration. Don't let deprecated packages accumulate — each one is a future vulnerability waiting to happen. The Go team is good about this (e.g., io/ioutil → os), so follow their guidance.

Question 5

How do I handle a vulnerability in a package I use but don't directly control?

Accepted Answer

File an issue on the package's GitHub repo. Provide:
- CVE ID and Go Vulnerability Database link
- EPSS score and KEV status
- Timeline for patching
- Whether you have a workaround

If the maintainer is unresponsive for 30+ days, consider:
- Using a fork with the patch backported
- Replacing the package with an alternative
- Mitigating the vulnerability in your code (e.g., input validation)

Question 6

Can I rely on GitHub's dependency alerts instead of GeekWala?

Accepted Answer

GitHub's Dependabot alerts are good for initial discovery. But they don't include EPSS or CISA KEV signals, which dramatically improve prioritization. If you're managing a large microservice infrastructure with hundreds of dependencies, Dependabot alerts will overwhelm you. GeekWala's EPSS/KEV enrichment makes it actionable.

Question 7

What if a vulnerability appears in NVD but not in the Go Vulnerability Database?

Accepted Answer

This happens occasionally for non-Go packages. The Go DB is conservative and curated by the Go team — they only include vulnerabilities that affect Go code. If a C library has a vulnerability but you're not using CGo to call it, the Go DB might not list it. Use govulncheck for Go-specific coverage. To cross-check against NVD directly, GeekWala queries OSV, the Go Vulnerability Database, and NVD simultaneously — so gaps in one source are caught by another. Alternatively, run govulncheck -json ./... to get machine-readable output you can compare against the NVD API programmatically.

Question 8

Does GeekWala support Go workspaces (go 1.18+)?

Accepted Answer

Yes. Upload the workspace root directory's go.mod (or individual module go.mod files). GeekWala scans all modules and aggregates findings. This is especially useful for monorepos with shared dependencies across multiple services.

For a side-by-side comparison of all ecosystem scanners, see 7 Dependency Vulnerability Scanners Compared.