FOSSA Manual Dependency types explained

When automatic detection doesn’t catch everything, FOSSA offers a powerful fallback: the fossa-deps.yaml file.

This flexible and extensible feature lets you manually declare dependencies that may not be picked up by traditional SCA tools — such as embedded code, internal libraries, or third-party archives. It’s especially useful for cases like firmware, SDKs, or highly customized build environments where standard scanning falls short.

With fossa-deps.yaml, you can ensure these otherwise “invisible” dependencies are included in your SBOM — helping you stay compliant, complete, and audit-ready.

FOSSA supports four types of manual dependencies, each designed for a specific use case — giving you full control over how your software supply chain is captured.

📁 1. Vendored Dependencies

"The open-source code is copied into my project."

Use when you've included the source code, or vendor-provided 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

"Uses 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, Monorepos, shared libraries across projects - for both licenses & vulnerabilities

📊 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`

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: MIT

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!