Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
C/C++ Open Source Detection

See the open-source code copied into your C/C++ codebase

Most SCA tools only see dependencies your build system installed. In C and C++, a lot of open source never goes through a build system at all — it's copied straight into the codebase. O3 reads the source itself, identifies exactly which open-source project and version that code came from, and tells you what it's exposed to.

Talk to us How it works
The gap

Same repository. Two very different answers.

A manifest-only scanner checks the dependencies your build system knows about, so anything copied directly into third_party/ sits outside its view entirely — not flagged, not unknown, just never looked at. O3 reads every file and resolves what's actually there.

Manifest-based scan
src/
main.c
network.c
third_party/
zlib/
inflate.cnot tracked
deflate.cnot tracked
mbedtls/
aes.cnot tracked
sha256.cnot tracked
O3 scan
src/
main.c
network.c
third_party/
zlib/
inflate.czlib 1.2.11
deflate.c2 CVEs
mbedtls/
aes.cmbedtls 2.28.0
sha256.cmbedtls 2.28.0
How it works

Read the code, not just the manifest

Step 1

Scan the actual source

Every C/C++ file in your codebase is analyzed directly, independent of whether a package manager knows it exists.

Step 2

Match it to real open-source projects

Your code is compared against a large, continuously updated index of known open-source C/C++ projects. Reformatted or partially modified copies still match.

Step 3

Pin the exact library and version

The same code often shows up in more than one open-source project. O3 works out which one it actually came from and which version, automatically.

Step 4

Land as one confirmed finding

No review queue. What reaches your team is a short, usable list of what's in your codebase, with the CVEs that actually apply to it.

No manual triage

A short, confirmed list — not a queue to review by hand

A short code fragment can genuinely match more than one library, or more than one version of the same library, since most of a library's source barely changes between releases. That's exactly why tools built for this often hand the ambiguity to a person. O3 weighs the evidence across every matching file and resolves it automatically — when the evidence only supports a range rather than one exact answer, it says so instead of guessing.

CVE accuracy

Vulnerabilities that actually apply to what you shipped

Looking up CVEs by package name alone is noisier than it looks — a popular library's name is often reused across dozens of Linux distribution packages with their own unrelated advisory history. O3 looks up vulnerabilities against the specific upstream project it identified, so what your team sees is the real CVE history for the code you actually shipped.

zlib
third_party/zlib/inflate.c
version confirmed
Version1.2.11
Upstream CVEs2 found
CVE-2018-25032High
CVE-2022-37434Medium
Queried against the zlib upstream project. 100+ unrelated Linux-distribution advisories excluded.
Where it fits

For the C/C++ code your build system doesn't know about

Firmware & embedded Linux

Board support packages, RTOS integrations, and driver code with no build-time package manager involved.

Vendored source trees

A compression, parsing, or crypto library checked directly into the repository rather than pulled by a package manager.

SDK & toolchain drops

A hardware vendor's SDK, pinned to one release, with its own bundled open-source code baked in.

Legacy C/C++ services

Code old enough to predate the current build system, where the record of what came from where has been lost.

See what's really inside your C/C++ codebase

This runs alongside O3's SAST, SCA, and secret scanning in the same pipeline. Talk to us about running it on a real codebase.

Talk to us
FAQ

Questions,
answered.

Everything teams ask before rolling this out. Still stuck? Reach our team.

  • O3 scans C/C++ source files directly and compares them against a large, continuously updated index of known open-source projects. This finds code that was copied straight into a repository, such as a vendored library, that a manifest-based scanner has no way to see because there is no dependency entry pointing to it.
  • Traditional SCA reads a package manifest to build a dependency graph. Most C/C++ firmware, board support packages, and SDK drops have no package manager involved at all: the code is copied directly into the source tree, not installed by a build tool. A manifest-only scanner does not flag this code as missing; it simply never looks at it.
  • No. O3 automatically works out which library and version a piece of code actually came from, weighing the evidence across every matching file, and rolls the results into a short, confirmed list of what’s in your codebase rather than a queue of individual matches to review by hand.
  • O3 looks up vulnerabilities against the specific upstream open-source project it identifies, rather than by package name alone. A name-only lookup often pulls in unrelated advisories from Linux distribution packages that share the same name but have nothing to do with a vendored source copy.
  • It detects code that has been reformatted or partially modified. Code whose function and variable names have been extensively renamed is harder to match and is an active area of ongoing improvement.
  • No, it runs alongside it. Manifest-based scanning still covers dependencies your build system installs; this covers the vendored, no-manifest code that manifest-based tools can’t see at all.