SBOMs: Essential for Embedded Systems Too!
Kate Stewart, The Linux Foundation[Open Source Summit EU 2022]

Software supply chain attacks are growing. SBOM (Software Bill Of Materials) helps controlling them.

Supply chain attack is when an attacker either injects or exploits something in a small package that is used as a dependency on the target project or product. It is now mostly a topic in cloud, but embedded is certainly vulnerable as well.

SBOMs in general are recently required by various security standards and regulations. But its definition was still a bit vague. Also formats are not standardized, which makes tooling for producing and evaluating them impossible.

Current definition of SBOM is: formal record containing the details and relationships (= dependencies) between components (what exactly a component is is essentially left vague). One additional important aspect is known unknowns: make it clear in which parts you’re not sure, where something may be missing.

“Dependency” is too clear cut, you have several kind, e.g. only used during test.

Ideally, every actor in the supply chain consumes the SBOM of the components they use, and produces and SBOM of what they publish/sell.

For open source, a challenge is that you don’t (can’t) know who the consumers are. So if there’s a vulnerability, there’s no way to warn consumers.

Minimum SBOM tracks of each component: name, supplier, version, dependency relations ship, author of SBOM data, and timestamp.

Many SBOM formats exist, one of them is SPDX.

There are different classes of SBOMs from different parts of the lifecycle. Source is the stuff you consume, analyzed SBOM is the same but based on analyzing the generated code instead of the inputs. Build SBOM is the additional stuff you use during build, and maybe also remove stuff that you don’t actually use in the build. Deployed SBOM is the same but then for the deployed project, e.g. if you configure it not to use something, then that something is no longer part of the SBOM.

Zephyr and Yocto have a way to generate SBOMs. E.g. Zephyr produces two source SBOMs (one for the kernel and one for the app) and a build SROM (based on what actually gets linked into the final elf file).