Question 1

Do I need to replace my ecosystem's native scanner?

Accepted Answer

No. Keep npm audit, pip-audit, govulncheck, and the rest in your CI pipeline. They're fast, free, and catch issues at development time without requiring any account or API setup. They should be your first line of defense. The gap is prioritization: native tools give you a ranked list based on CVSS severity, but can't tell you which findings are being actively exploited right now. A cross-ecosystem tool with EPSS and KEV data adds that layer on top of — not instead of — your native scanners.

Question 2

Why don't the native tools include EPSS?

Accepted Answer

EPSS is maintained by FIRST.org and updated daily for 200,000+ CVEs. Integrating it requires fetching, caching, and correlating EPSS data with each advisory database. Most native tools are designed to be fast, dependency-light, and capable of running offline. Adding EPSS would require daily network calls and a caching layer that conflicts with these design goals. It's not that ecosystem tool maintainers think EPSS is unimportant — it's an architectural tradeoff.

Question 3

Which ecosystem has the best native vulnerability scanning?

Accepted Answer

Go's govulncheck is the standout. Its call-graph analysis distinguishes between "this package is installed and has a CVE" versus "your application actually calls the vulnerable function." This meaningfully reduces false positives. RustSec (the advisory database behind cargo audit) is also exceptionally well-curated with low false positive rates. At the other end, Java's CPE-matching approach in OWASP Dependency-Check produces more noise and requires more manual triage, particularly with shaded JARs.

Question 4

How should I scan a monorepo with multiple languages?

Accepted Answer

Scan each manifest or lock file separately. Most lock files are small (a few hundred KB even for large projects), so the overhead is minimal. In CI, run native tools in parallel: npm audit, pip-audit, govulncheck, etc. Run a GeekWala scan on all lock files to get a unified prioritized view. For monorepos with dozens of services, the GeekWala API lets you automate this — submit lock files programmatically and gate deploys on KEV status or EPSS threshold.

Question 5

What's the best starting point for a team that's currently running no dependency scanning?

Accepted Answer

Start with the native tool for your primary language — it takes 5 minutes to add to CI and requires no account. Then add composer audit or pip-audit or cargo audit for any secondary languages. Once you're running native scans consistently and have a process for reviewing findings, add a cross-ecosystem scan to get EPSS and KEV prioritization. Don't try to do everything at once — running one ecosystem's native tool reliably is more valuable than running eight tools sporadically.

Question 6

Does scanning dependency files expose our codebase or proprietary information?

Accepted Answer

Manifest and lock files (package-lock.json, go.sum, Cargo.lock, etc.) contain package names and version numbers — no source code. They're structured lists of public package identifiers. Submitting them to a scanner doesn't expose business logic, database schemas, or API keys. The only information disclosed is which open-source packages you use — the same information that would be visible in your nodemodules directory or any compiled artifact.

Question 7

How often should I run multi-ecosystem scans?

Accepted Answer

Run native ecosystem scans on every CI build. Run cross-ecosystem scans (with EPSS and KEV enrichment) at least weekly on your production lock files. EPSS scores change daily as exploit code appears, threat intelligence feeds update, and malware analysis data arrives. A package that was EPSS 0.04 last week can spike to 0.85 this week without any changes to your codebase. Scheduled scans catch this drift between deploys.