Supported languages and reachability matrix
dep-scan uses cdxgen internally to build a CycloneDX Software Bill-of-Materials (SBOM), then layers vulnerability matching and reachability analysis on top of it. The matrix below is the single reference for which package ecosystems are supported, how the BOM is generated for each, and which reachability engine backs each language. Refer to the Reachability analysis hub for the concepts behind the analyzers, and to the per-language guides under Language Guides for worked examples.
Language and reachability matrix
| Language / ecosystem | purl type | BOM generation path | Reachability engine | Default analyzer |
|---|---|---|---|---|
| Java / JVM (Groovy, Kotlin, Scala) | pkg:maven | cdxgen (Maven, Gradle, jars) | atom | FrameworkReachability |
| JavaScript / TypeScript | pkg:npm | cdxgen (package-lock, node_modules) | atom | FrameworkReachability |
| Python | pkg:pypi | cdxgen (requirements, Poetry, uv, Pipfile) | atom | FrameworkReachability |
| PHP | pkg:composer | cdxgen (composer.lock, requires PHP >= 7.4) | atom | FrameworkReachability |
| Rust | pkg:cargo | cdxgen (Cargo.lock) | rusi | FrameworkReachability |
| Go | pkg:golang | cdxgen (go.mod, vendor, module cache) | golem | FrameworkReachability |
| .NET (C#, VB, F#, R) | pkg:nuget | cdxgen (.csproj, packages, restored tree) | dosai | FrameworkReachability |
The four atom-backed ecosystems (Java, JavaScript/TypeScript, Python, PHP) share a single slicer, so they behave consistently and accept the same workflow. Rust, Go, and .NET each have a dedicated native slicer (rusi, golem, dosai) that produces a language-specific report, which dep-scan converts into the same purl-keyed slice format the shared reachability engine consumes. From the analyzer's point of view every language is equal: a reachable finding is a versioned purl that appears on an executed data-flow or call-graph path, regardless of which slicer produced the evidence.
cdxgen supports many more project types for BOM generation and vulnerability scanning (Docker, Jenkins, Dockerfile, Terraform, and more). Reachability, however, requires source-level slicing and is therefore limited to the languages listed above. See the official cdxgen project types reference for the full BOM-generation list.
Choosing an analyzer
Every reachability-capable language defaults to FrameworkReachability, which is fast and answers the question "is the vulnerable package actually called." Switch to SemanticReachability when you need endpoint-level, service-level, and post-build (binary/container) reachability on top of the framework-forward result. Pass --reachability-analyzer off to disable reachability entirely and run a plain version-based scan. The trade-offs between the two analyzers are covered in the Analyzers category, starting with Framework reachability and Semantic reachability.
Where to go next
If you are new to reachability, read the reachability model concept page first, then the guide for your language. If your goal is compliance output, jump to the VDR guide and the CSAF VEX guide.