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
Disclosure: This draft was prepared with AI assistance from public project documentation. It has not yet received the author's final factual and editorial review.
Top comments (0)