Source-present is not the same as shipped: reviewing an embedded C/C++ SBOM

JIE SONG — Thu, 22 Oct 2026 15:31:20 +0000

Draft for author review. The example below is based on the project's documented workflow; this preparation session did not execute a firmware build or reproduce its benchmark results.

An embedded C/C++ source tree tells you which files are available. It does not, by itself, establish what reached the shipped firmware. SDKs may include optional dependencies, vendor forks and code discarded during linking.

Keep three kinds of evidence separate

Evidence	What it helps establish	What it does not establish alone
Source tree	Candidate components and identification evidence	Participation in a particular build
Compilation database	Translation units and compiler commands for that build	Final retention in the linked image
Linker map	Link-time object and section information	Complete upstream identity and version

A compilation database and a linker map complement component identification. None should silently substitute for the others. Linker formats and incomplete build inputs can also introduce ambiguity.

A concrete documented workflow

Gangmu is an open-source tool I initiated to work on this problem. Its documented workflow combines component identification rules with build inputs and exports CycloneDX or SPDX SBOMs.

For a project that already has the required build artifacts, the README gives this pattern:

gangmu scan ./firmware \
  --compile-db build/compile_commands.json \
  --link-map build/firmware.map \
  --format cyclonedx -o sbom.json

The paths are illustrative: replace them with your own project's inputs. Before relying on the output, inspect component identity, version evidence and whether the relevant code was linked. Source-only scanning remains useful, but a source inventory should not be presented as proof of the shipped contents.

Test identification separately from build inclusion

The repository includes a controlled example based on GmSSL 3.0.0. It renames a directory, removes a version header, changes some symbols, inserts vendor functions and deletes some source files. The reproduction script is examples/disguise.sh.

This experiment asks whether identity and version evidence survive those particular modifications. A separate experiment is needed to test whether a compiled dependency that is discarded at link time is represented appropriately. Success on either example does not establish accuracy across other SDKs or toolchains.

For a useful experiment report, record:

Tool and rule-pack versions.
Upstream release and source provenance.
Compiler, linker and relevant flags.
Exact inputs and reproduction commands.
Expected identity, version and build status.
Observed output, mismatches and unresolved evidence.

Treat gaps as review work

Rule coverage and build evidence are finite. An unidentified directory, ambiguous object or uncertain version should remain visible to a reviewer. Generating a valid SBOM file is also distinct from establishing that its inventory is complete or that a product meets a regulatory requirement.

The next editorial step for this draft is to add an experiment reproduced by the author, including actual output and a concrete explanation of any mismatch. No new benchmark or accuracy claim is made here.

Sources