Without a central package manager, scanners find C and C++ dependencies through a lockfile where one exists, or through commit level data for submodules and vendored copies. Coverage is real but less complete than for npm or PyPI, so treat a clean C or C++ result with more caution.
Why C and C++ are different
Most ecosystems have a registry and a manifest that names every dependency and version. C and C++ projects often copy a library into the tree or pull it in as a Git submodule. The dependency exists, but no file says "this is version 1.2.3".
The OSV-Scanner documentation states this directly: C and C++ have no central package manager, so dependencies are usually bundled, and its support is based on commit level data.
The three routes a scanner can take
| Situation | What a scanner can use | Confidence |
|---|---|---|
| Conan lockfile present | Package names and versions from conan.lock | High |
| Git submodule | The commit hash from Git history | Good, if the commit is in the data |
| Vendored copy with no history | An estimate of version and commit from file contents | Lower, best effort |
For submodules, the OSV-Scanner docs say to run a submodule update and then scan the folder. For vendored code they say it uses OSV's determineversion API to estimate the version and commit.
The limits to write down
The same documentation warns that vulnerabilities in C and C++ dependencies "could be excluded" from results because commit level data does not cover everything. That is an honest statement of a coverage gap, and it applies to the approach in general, not just one tool.
Two practical limits follow:
- A vendored library that was edited, trimmed or renamed may not match the fingerprint.
- A library installed by the operating system is covered by the distribution's data instead, which is a different route. See why Linux scans track source package names.
How to test coverage on your project
- List every third party library in your tree by hand, including vendored folders. This is your ground truth.
- Run your scanner and list the components it reports.
- Mark each hand listed library as found, found with a wrong version, or missing.
- For missing ones, check whether a lockfile or a submodule would make them findable.
- Record the gaps in your coverage matrix and decide who reviews those libraries manually.
Where you can, adopt a lockfile such as Conan's, because a resolved list beats an estimate.
Safeguard's SBOM and dependency scanning builds a component inventory, and the free scan at https://gold.safeguard.sh/scan shows what it detects in a manifest you upload.
Try it yourself
Open the demo and notice how each component lists a source for its version. Imagine which of yours would be missing.
Click through it at your own pace, or open it full screen.
Quick check
Can a scanner read versions of vendored C libraries?
Sometimes. Tools may estimate the version and commit from file contents, but the documentation calls this best effort.
What improves C and C++ scan accuracy most?
A resolved lockfile or a Git submodule with history, since both give the scanner a concrete version or commit.
Sources
Last reviewed: 19 October 2026.
