What we still need to verify : 2 points in this profile are not yet confirmed against vendor documentation.
- Self-hosted deployment availability and constraints: confirm with vendor
- Current module list including vulnerability and container coverage: verify against vendor documentation
Treat these points as unconfirmed. They are open items in the catalog's verification queue, and this note stays until each is checked against the vendor's documentation.
What it does
FOSSA's dependency resolution runs through the build system rather than around it. Its command line analyzer detects the build tools present in a project and invokes or reads them directly, Gradle, Maven, npm, Cargo, Go modules, Bundler and the rest, to obtain the dependency graph the build actually produces, including transitive components and the path by which each was pulled in. That path matters for license work, because an obligation attaches differently depending on whether a component is linked, bundled or merely a build-time tool.
The analysis then focuses on licenses. FOSSA maintains license data for open source packages and detects declared and discovered licenses at the file level, catching cases where a package's stated license differs from what is in its source tree, or where one package contains several licenses. On top sits a policy engine expressed in obligations rather than allow and deny lists, plus generation of the attribution notice files shipping software legally requires. Vulnerability matching, SBOM export and container analysis extend the platform, but license compliance is the core competency.
Where it fits
This runs in CI, through the analyzer binary invoked after dependency resolution, with results in a hosted or self-hosted console. Ownership splits between engineering, who wire up the pipeline, and a legal or open source program office, who define policy and consume reports. It is most useful where you ship software to third parties, because that is when attribution and obligation compliance stop being theoretical. If your software only runs on your own servers, much of the license machinery is overhead.
Strengths
- Build-system-native analysis produces dependency graphs that reflect what ships, including build-time versus runtime distinction.
- File-level license detection catches mismatches between a package's declared license and its actual contents, which manifest-only tools miss.
- Attribution notice generation solves a genuinely tedious release task rather than just reporting on it.
Limitations
- The analyzer needs a working build in the scan environment, so projects with complex or environment-dependent builds produce incomplete graphs, sometimes without an obvious failure signal.
- Vulnerability management is present but is not the product's center of gravity, with no reachability analysis to prioritize findings.
- License detection surfaces ambiguity honestly, which means real review work lands on someone. Without legal capacity to absorb it, that backlog just sits there.
Who it suits
A solid choice for companies distributing software, whether on-premises products, mobile applications or embedded systems, that need defensible license compliance and attribution, and for organizations preparing for acquisition or customer audits. Less compelling for a SaaS-only team whose main concern is patching vulnerable dependencies, where a vulnerability-first tool does more with the same effort.
Used FOSSA? Recommend it under your own name and title.
Recommend this tool