What Is Dependency Scanning?
Dependency scanning checks your third-party libraries for known vulnerabilities. Here's how it works, what it misses, and how to actually use it well.
Most modern applications are, by volume, mostly code the development team didn't write. A typical project pulls in dozens to hundreds of third-party packages, each with its own dependencies. Dependency scanning — also called software composition analysis (SCA) — exists to check all of that inherited code against known vulnerabilities.
What dependency scanning actually checks
A dependency scanner inventories every library and package used by an application, directly and transitively (dependencies of dependencies), and compares that inventory against databases of known vulnerabilities — most commonly the CVE database and similar sources. When a dependency version matches a known-vulnerable version, it's flagged.
Why this matters more than it might seem
Given how much of an application's actual code is third-party, dependency-related vulnerabilities represent a significant share of real-world exploited issues — and unlike a custom application logic flaw, the vulnerability is often already public, documented and sometimes has working exploit code available, because it was found and disclosed in the open-source project itself.
This creates a specific risk pattern: the vulnerability isn't undiscovered — it's disclosed and known — but the application using it hasn't been updated to a patched version. That's a meaningfully different (and more avoidable) risk than a novel, undiscovered flaw.
Direct vs. transitive dependencies
Most attention goes to direct dependencies — the packages explicitly listed in a project's manifest. But those packages bring in their own dependencies, which bring in more, several layers deep. Vulnerabilities in transitive dependencies are just as real, and harder to notice, because they're not something the development team consciously chose to include.
A good dependency scanner covers the full dependency tree, not just the top-level list.
What dependency scanning doesn't tell you
- Whether the vulnerable code path is actually used — a library might have a known vulnerability in a function your application never calls, which changes real-world risk significantly
- Vulnerabilities in your own code — dependency scanning only covers third-party code, not custom application logic
- Supply chain compromise that isn't yet a known CVE — a newly compromised package won't be flagged until the vulnerability is disclosed and added to a database
How to actually use dependency scanning well
- Run it continuously, in CI, not periodically — new CVEs are disclosed constantly, and a dependency that was clean last month may not be today
- Prioritize by reachability, not just presence — a vulnerability in an unused code path is lower priority than one in a function actively called by your application
- Set policy for update cadence — decide how quickly critical, high and lower-severity findings need to be addressed, rather than handling each ad hoc
- Watch for abandoned dependencies — packages no longer actively maintained won't receive security patches even for newly discovered issues, which is itself a risk signal worth tracking
Balancing update speed against stability
Updating dependencies immediately on every disclosure isn't always practical — updates can introduce breaking changes. A reasonable policy distinguishes: critical, actively exploited vulnerabilities warrant immediate action; lower-severity or low-reachability findings can go through normal update cycles with appropriate testing.
How does Averto fit in?
Dependency risk is continuous by nature — new CVEs are disclosed constantly, independent of anything your team changes. Averto includes dependency scanning as part of continuous testing, and — consistent with how we handle other finding types — prioritizes based on reachability and real exploitability, not just presence in the dependency tree.
Frequently asked questions
What's the difference between dependency scanning and SAST?
Dependency scanning (SCA) checks third-party libraries against known-vulnerability databases; SAST analyzes your own source code for insecure patterns. They cover different code.
Do I need to worry about transitive dependencies?
Yes — vulnerabilities in indirect dependencies are just as exploitable and often less visible than direct, top-level dependencies.
How often should dependency scanning run?
Continuously, ideally as part of CI on every build, since new vulnerabilities are disclosed on an ongoing basis independent of your own code changes.
Is every flagged dependency vulnerability actually a risk?
Not necessarily — reachability matters. A vulnerability in a code path your application never executes carries far less real-world risk than one in active use.