The C conundrum - generating SBOMs when there's no lockfile

Generating an SBOM for something created in a modern language like Dart, Go, Python or Rust is pretty easy. Dependencies are declared using the language’s package manager, the package manager creates a .lock file, and then an SBOM can be generated from the .lock file. Under the hood sbomify uses Trivy to do that, and other tools like Syft do the same.

There’s no package manager for C though, at least not a universally used one.

That’s a huge problem, because apps developed using modern languages where it’s easy to create SBOMs are the very tip of an iceberg where stuff developed in C is both the rest of the visible iceberg and everything beneath the surface - the apps we know are written in C, and the numerous libraries etc. that they’re built on top of.

How are people going to comply with Executive Order 14028 (in the US) and the forthcoming Cyber Resilience Act (CRA) in the EU if they’re dealing with that iceberg of C?

Where there are package managers we can reasonably expect their maintainers to start churning out SBOMs. The Yocto Project, which builds embedded Linux distributions, has taken an early lead with their machinery for Creating a Software Bill of Materials. It’s also reasonable to expect that major distributions like Debian and Red Hat will follow suit. They do after all have all the metadata that’s needed, and they’ve already spent years on careful curation.

But what about all the apps that aren’t in major distro package managers? There are a few pieces to the puzzle out there, but not yet a complete solution.

• cmake-sbom can add the SBOM creation process to CMake (a popular tool for building C projects), but a lot of the data entry (and subsequent maintenance) is manual. This perhaps provides the boilerplate for NTIA compliance, but doesn’t really help with upstream dependencies.
• Zephyr has the ability to generate SPDX for the embedded systems it creates, based on earlier work in cmake-spdx. But that hasn’t yet been cycled back into a generic tool that could be used by other CMake based projects.
• Conan is a package manager for C/C++, with many popular dependencies already present there. That opens the door to generating SBOMs from conan.lock files, but right now the resulting files (at least those generated by Syft) are of very poor quality, with incomplete CFEs.
• cve-bin-tool can generate an SBOM from the libraries it finds in a binary, but:
  • Only a limited subset of libraries are discoverable to the tool.
  • When generating SBOMs from test binaries they were of poor quality.
  • cve-bin-tool flags binaries and the libraries they contain as being vulnerable even when they’ve been patched to fix the relevant CVE, implying a naive matching mechanism.
• it-depends finds nothing (and it seems it’s a known issue despite the README saying it supports CMake projects).

Thankfully efforts are underway to resolve these problems. C (and C++) is lined up for Phase 3 of the SBOM Generation Reference Implementations within the CISA SBOM Community; and the working group had a call in the past week to look at what’s already working and where effort can most effectively be applied to provide tools for a broader range of projects.

This is a guest post from Chris Swan and Engineer at Atsign who are an early adopter of sbomify.