Mediated Dependencies
How FOSSA handles transitive dependencies whose version is resolved by the package manager when multiple constraints conflict.
Overview
Most build graphs contain transitive dependencies that appear more than once at different required versions. When this happens, the build tool applies a resolution algorithm to select a single version, a process known as dependency mediation.
How package managers mediate versions
The version selected for a shared transitive dependency varies by ecosystem:
| Ecosystem | Resolution strategy |
|---|---|
| Maven | Nearest-wins, the version declared closest to the root of the dependency tree is selected |
| Gradle | Highest-wins by default, the highest requested version across all constraints is selected |
| npm / yarn | Historically nested (each package gets its own copy); modern lockfiles consolidate to a single version where possible |
| Go modules | Minimum version selection, the lowest version that satisfies all constraints |
For example, if your project depends on library A and library B, and both require different versions of library C, the package manager picks one version of C based on its algorithm. That selected version is the mediated dependency, the one actually present in your build.
How FOSSA captures mediated dependencies
The accuracy of FOSSA's dependency graph depends on how the project is analyzed:
CI/CD scanning (fossa analyze); the FOSSA CLI runs inside your existing build environment and captures the dependency graph after the build tool has already resolved all version conflicts. FOSSA receives the exact set of mediated versions that your build tool selected. This is the most accurate method.
Quick Import (FOSSA reconstructs the dependency graph by reading package manifest files (e.g. pom.xml, package.json, go.mod). Because FOSSA applies its own resolution logic rather than running your build tool directly, the mediated versions it selects may differ from what your actual build produces) particularly for complex graphs with many conflicting constraints.
Why it matters
The version of a dependency that ends up in your build determines which licenses apply and which CVEs are relevant. If FOSSA's resolved graph differs from your actual build graph, you may see issues for versions you don't actually use, or miss issues for versions you do.
Using CI/CD scanning eliminates this class of false positives by ensuring FOSSA analyzes the same dependency graph that your build tool produced.