owasp-dep-scan/dep-scanNext-generation dependency vulnerability scanner with reachability analysis, SBOM generation, license audit, and container image scanning for CI/CD integration.
OWASP dep-scan is a next-generation security and risk audit tool based on known vulnerabilities, advisories, and license limitations for project dependencies. Both local repositories and container images are supported as the input, and the tool is ideal for integration with ASPM/VM platforms and in CI environments.
Detailed data flows to identify both reachable and non-reachable paths in your application based on the full context.
dep-scan computes reachability for seven language ecosystems through four slicers. A vulnerable package whose code is actually on an executed path is marked Reachable, while a package that is merely declared in the BOM but never called is not. Every slicer feeds the same shared, purl-keyed reachability engine, so the behavior is uniform across languages. Reachability is on by default (--reachability-analyzer FrameworkReachability); SemanticReachability additionally attributes reached services, endpoints, and post-build (binary/container) reachability.
| Language / ecosystem | Reachability engine | Default analyzer |
|---|---|---|
| Java / JVM (Groovy, Kotlin, Scala) | atom | FrameworkReachability |
| JavaScript / TypeScript | atom | FrameworkReachability |
| Python | atom | FrameworkReachability |
| PHP | atom | FrameworkReachability |
| Rust | rusi | FrameworkReachability |
| Go | golem | FrameworkReachability |
| .NET (C#, VB, F#, R) | dosai | FrameworkReachability |
For the concepts behind reachability and prioritization, read the reachability model and prioritization chapters. For per-language worked examples, see the Language Guides. For the compliance story (VDR and CSAF VEX), see the VDR guide and the CSAF VEX guide.
Reachability is on by default under --profile research, which is what dep-scan uses when reachability is on. The commands below are enough to get started; the per-language guides cover binary resolution, backend and network safety, restore requirements, and worked examples on the in-repo fixtures.
Rust (rusi). cdxgen runs rusi and persists its report, which dep-scan converts into the shared pipeline, so a crate that is actually called (for example time::now() for RUSTSEC-2020-0071) is Reachable while one merely present is not. See the Rust reachability guide.
depscan -i ./my-rust-app -o ./reports --profile research
Go (golem). dep-scan invokes golem directly for Go projects (needs go on PATH), marking a module Reachable when its functions are on a traced path. Use --go-analyzer-network offline for untrusted repos with a warm module cache. See the Go reachability guide.
depscan -i ./my-go-app -o ./reports -t go
.NET (dosai). cdxgen runs dosai, which emits an explicit per-package reachability verdict (PackageReachability with ReachabilityKind and Confidence) that dep-scan treats as authoritative, so a NuGet package actually called (for example JsonConvert.DeserializeObject on a controlled input) is Reachable. Scan a restored tree for versioned purls. See the .NET reachability guide.
depscan -i ./my-dotnet-app -o ./reports -t dotnet
JVM, JavaScript/TypeScript, Python, and PHP (atom). These four ecosystems share the atom slicer, which builds a language-agnostic intermediate representation and performs static slicing. See the JVM, JS, Python, and PHP reachability guide.
depscan --profile research -t java -i ./my-java-app -o ./reports --explain
To move beyond framework-forward reachability to endpoint, service, and post-build tiers, pass --reachability-analyzer SemanticReachability with a --bom-dir of lifecycle BOMs. See the semantic reachability guide.
Understand CVEs clearly without having to read through the description.