Find vendored C/C++ code that has no package manifest to scan
Most SCA tools read a lockfile. C and C++ firmware, SDK drops, and board-support packages rarely have one — the code is copied into the tree, not installed by a package manager. O3's snippet engine reads the source itself: it tokenizes and fingerprints your codebase, matches it against a corpus of known open-source libraries, and tells you which library a vendored file actually came from.
Manifest-based SCA needs a manifest. Most C/C++ doesn't have one.
Snyk, Dependabot, and Syft all work the same way: read a package-lock file, resolve the dependency graph, check each entry against a vulnerability database. That works when your dependencies were installed by a package manager.
A lot of C/C++ code isn't. A vendored third_party/zlib/ directory, a silicon vendor's SDK drop, a board support package pinned to one SDK release, a bootloader nobody has rebuilt since launch — none of it has a lockfile. A manifest-only scanner sees nothing there at all, not even an empty result. It just never looks.
Read the source, not the manifest
1. Tokenize and fingerprint
Every scanned C/C++ file is parsed and broken into overlapping token windows, fingerprinted with a winnowing algorithm — the same family of technique used by plagiarism detectors and Black Duck's own signature scanner.
2. Match against a known-library corpus
Fingerprints are checked against a corpus built from real open-source C/C++ projects. A match doesn't require an exact byte-for-byte copy — reformatted or partially modified vendored code still matches at the snippet level.
3. Resolve the real library, not just a hit
The same file often appears in many corpus projects that happen to vendor it too. O3 resolves which library the code actually is — using how much of that library is present, and how your own tree names the vendored directory — rather than reporting every project that also contains it.
Black Duck makes a person confirm every match. This is automatic.
Black Duck's own documentation is explicit about this: components found by snippet matching are "not automatically added to the BOM"— each match has to be individually reviewed and confirmed by a person before it counts. Their own blog goes further: signature-style matching "can lead to unintentional misidentifications," so "a human auditor is required to verify and correct the results," citing an audit with over 1,000 matches needing manual correction. That review burden is the exact complaint we hear most from teams who've tried snippet-based SCA at any real scale.
The reason a match needs confirming at all is a real, structural one: a short code fragment usually doesn't belong to only one library or one version. Most of a library's source is unchanged release to release, so a single matched file can honestly match a dozen versions at once. There's no lockfile to break the tie the way there is for manifest-based dependencies.
O3 resolves this without a review queue. Every matched file gives a lower bound — "unchanged since at least version X" — and the true version is the highest bound across every file that matched. Tested against 16 real vendored checkouts across three libraries, that method landed on the exact version in every case where the corpus held it, and correctly reported an honest range ("0.2.3 or later") rather than a wrong guess in the two cases where it didn't. On the same worked example, Black Duck's documented tie-break (KB rank, then earliest release date) and SCANOSS's (oldest match in the corpus) both land on the wrong, older version.
Upstream CVEs, not distro-package noise
Black Duck's own documentation states that snippet matches are excluded from vulnerability counts and reports entirely — positioned as a license-compliance feature, not a vulnerability one. Querying a resolved library and version by package name is also a real trap: a plain query for zlib 1.2.11 returns over 100 advisories, and every one of them is a Debian, Ubuntu, or Alpine distro-package advisory that doesn't apply to a vendored source copy at all.
O3 queries by the resolved upstream repository instead, which returns the library's own CVEs and nothing else — five real advisories for that same zlib copy, not 101 rows about a package manager it never used.
We're direct about the limit here too: only matches where the version resolves with confidence get promoted to a real vulnerability row your team triages. The rest stay visible on the dependencies page as an unconfirmed finding rather than get filed as a vulnerability we can't actually stand behind.
What it does, and what it doesn't do yet
A snippet-matching engine has real, known failure modes. Here's where ours currently stands, stated plainly rather than left for you to discover during a trial.
Does today
Matches vendored C/C++ code against known open-source libraries at the snippet level, including partially modified or reformatted copies.
Resolves which library a matched file actually is, not just every project that also happens to contain it.
Resolves the vendored version automatically from the code itself, and rolls thousands of raw matches into a short list of dependency rows — no manual match-by-match review queue.
Attaches upstream, component-level CVEs to a resolved match — filtered to the library you vendored, not distro-package noise — and promotes version-confirmed ones to real vulnerability rows automatically.
Runs as an opt-in scan type alongside SAST, SCA, and secret scanning in the same pipeline.
Doesn't do yet
Version resolution for every match. The corpus records which project it saw a file in, not always which exact upstream release it came from — when the evidence only supports a lower bound, it's reported as a range, not promoted to a confirmed vulnerability.
Line-level confirmation that the specific vulnerable lines were the ones copied. Today's CVE attribution is component-level: "the library you vendored has these CVEs at this version," not "the vulnerable function itself is present."
Exact whole-file matching as a separate, faster path. Every match today goes through snippet-level fingerprinting, even for a file vendored byte-for-byte.
Reliable detection of vendored code whose identifiers have been renamed. Snippet fingerprints are sensitive to identifier text, so a renamed copy of a known-vulnerable file can go undetected.
For codebases a package-manager scanner can't see into
Firmware and embedded Linux
Board support packages, RTOS integrations, and driver code that arrive as a vendor drop with no build-time package manager involved.
Vendored source trees
A copy of zlib, OpenSSL, or a compression library checked directly into third_party/ rather than pulled by a package manager at build time.
SDK and toolchain drops
A silicon vendor's SDK, pinned to one release and never touched again, with its own bundled open-source code baked in.
Legacy C/C++ services
Code old enough to predate the project's current build system, where dependencies were copied in by hand and the history of what came from where has been lost.
See what's vendored in your own C/C++ codebase
Snippet matching runs as an opt-in scan type alongside O3's SAST, SCA, and secret scanning. Talk to us about running it on a real codebase.
Talk to us