Supported Languages

The languages, package managers, and platforms FOSSA can analyze, and how each is imported, authenticated, and enriched.

5 min readUpdated Jul 9, 2026

Overview

FOSSA analyzes dependencies across dozens of language ecosystems. Each page below covers, for one language, how FOSSA imports your project through Quick Import (in the web app) versus the FOSSA CLI, how to authenticate to private registries, and what package data FOSSA collects. The CLI's per-strategy detection model (static vs. dynamic strategies and strict analysis) is covered under Analysis strategies below.

Support matrix

Quick Import runs server-side when you import a repository through a connected source host; the CLI runs in your build environment (local or CI) for the most accurate results. Analysis type describes how the CLI detects dependencies; see Analysis strategies below for details.

Language / platformQuick ImportCLIComplianceSecurityAnalysis typeVendored code
Python (conda, pipenv, setuptools)Dynamic + fallback
Python (poetry, pdm, uv)Static
JavaScript / Node.jsRecommendedStatic
Java: MavenPartialRecommendedDynamic + fallback
Java / Kotlin: GradleRecommendedDynamic
Scala: sbtDynamic
Go (dep, glide)Static
Go (gomodules)Dynamic + fallback
RubyDynamic + fallback
PHPStatic
.NET (C#, F#, VB)Static
RustDynamic
Dart / FlutterDynamic + fallback
PerlStatic
HaskellDynamic
ElixirDynamic
ErlangDynamic
ClojureDynamic
FortranStatic
NimStatic
RStatic
iOS (Objective-C, Swift)Static
C / C++Custom
System packages----

A blank cell means that path is not available for that ecosystem; pick the other column. Where the CLI is marked Recommended, the language's builds are complex enough that CI/CD scanning gives materially better results than Quick Import.

Beyond package managers

FOSSA can also analyze code that no package manager describes:

  • Vendored code: fingerprint copied-in open source to identify it even after minor edits.
  • Snippet scanning: detect open source copied at the snippet level, where no manifest exists.
  • System packages: OS-level packages (apk, dpkg, rpm) discovered during container scanning.
  • Git submodules: imported as first-class dependencies when you analyze a repository that uses them.

Analysis strategies

The FOSSA CLI detects dependencies using one or more strategies per ecosystem: a primary strategy that yields ideal results and zero or more fallbacks. Each language page above documents its own strategies; this section explains how those strategies are classified and selected.

Static and dynamic strategies

Within the strategies for a language, we distinguish static and dynamic strategies. Static strategies parse files to find a dependency graph (example: parse a package-lock.json file). Dynamic strategies are required when analyzing package managers that do not offer complete lockfiles, such as Gradle or Go. Dynamic strategies require a working build environment to operate in.

Running the tool with all possible strategies enabled is recommended, but if you need to limit the CLI to only static strategies it offers the --static-only-analysis flag. This flag prevents the CLI from using any third-party tools, such as npm, pip, or maven plugins. With this option enabled, strategies that don't offer a way to analyze statically will fail with an error.

Neither type of strategy has an inherent benefit when detecting dependencies. If a supported language has only a static or only a dynamic strategy, that does not make it less supported than a language that has both.

The Analysis type column in the support matrix above classifies each ecosystem by the strategies it offers:

  • Static: only static strategies. Dynamic analysis is not required for ideal results, so a working build environment is not needed.
  • Dynamic: a dynamic strategy is required for ideal results, so the CLI needs a working build environment.
  • Dynamic + fallback: a dynamic strategy with a static fallback. The fallback provides worse results and is only used when the dynamic strategy fails.
  • Custom: strategies (such as C/C++) that work very differently from standard package-manager analysis; read their language page for details.

When the CLI is forced to use a fallback strategy, it emits a warning in the scan summary after running fossa analyze.

Strict analysis

Strict analysis enforces the use of the most accurate strategy for detecting dependencies, rejecting fallback methods that may be less reliable. For example, in Maven projects the CLI attempts analysis in this order:

  1. The mavenplugin strategy, which provides the most accurate dependency information.
  2. If that fails, the treecmd strategy, which parses the output of mvn dependency:tree.
  3. Finally, the pomxml strategy, which scans pom.xml files.

With the --strict flag, only the mavenplugin strategy is used; if it fails, the CLI does not fall back. Invoke strict analysis with the --strict flag when running fossa analyze.

© 2026 FOSSA, Inc.support@fossa.com