FOSSA Manual Dependency Types Explained
When automatic detection doesn’t catch everything, FOSSA allows you to declare dependencies manually using a fossa-deps.yaml
file. There are four types of manual dependencies, and each is used for a different situation.
📁 1. Vendored Dependencies
"The open-source code is copied into my project."
Use when you've included the source code of an open-source dependency directly in your repo (common in embedded/C/C++ environments).
- ✅ Best for: C/C++, SDKs, firmware, embedded projects where deep license scanning is needed.
- 🔍 FOSSA will scan the actual source code for licenses only
🌐 2. Remote Dependencies
"I’m using a dependency hosted somewhere else (like GitHub)."
Use when the dependency is external and not in your codebase, but publicly accessible via a URL (GitHub, GitLab, etc.).
- ✅ Best for: External open-source dependencies not included in your repo
- 🔍 FOSSA pulls metadata like version, license, etc.
🧩 3. Custom Dependencies
"This is proprietary or private code we use internally."
Use when a dependency is internal, closed-source, or vendor-provided — something not found in a public package manager.
- ✅ Best for: Internal libraries, commercial packages
- 🔍 FOSSA just tracks the name/version/license you specify — no scanning
🔗 4. Referenced Dependencies
"FOSSA has already scanned this package via a supported package manager — just reference it here."
Use when you want to explicitly reference a dependency that FOSSA already understands through a supported package manager (e.g., npm, Maven, Go modules, etc.).
- ✅ Best for: Declaring supported-package-managed dependencies explicitly
📊 Comparison Table
Type | Where the code is? | FOSSA behavior | Use Case |
---|---|---|---|
vendored-dependencies | Copied into your repo | Scans source code in that path | Embedded/firmware projects, C/C++ - for licenses |
remote-dependencies | Hosted on GitHub, GitLab, etc. | Fetches metadata and license remotely | Public open-source not included in repo -for licenses |
custom-dependencies | Internal or proprietary source | No scan; user-defined metadata | Internal libraries, vendor code - for licenses |
referenced-dependencies | Used where a supported package manager is used | Looks up the package from the package manager repository | Monorepos, shared libraries across projects - for licenses & vulnerabilities |
📝 Sample fossa-deps.yaml
fossa-deps.yaml
version:3
vendored-dependencies:
- name: zlib
version: 1.2.11
path: third_party/zlib
remote-dependencies:
- name: fmtlib/fmt
version: 9.1.0
url: https://github.com/fmtlib/fmt
custom-dependencies:
- name: my-internal-crypto-lib
version: 2.4.1
license: MIe
referenced-dependencies:
- type: gem
name: iron
- type: pypi
name: Django
version: "2.1.7"
FOSSA solution architects have written a variety of scripts which can help transform a variety of different formats of dependency docs into a fossa-deps.yaml file. Let us know if you’d like help generating this from an existing project structure or integrating it into your CI pipeline!
Updated about 15 hours ago