Every engineering team lead at an embedded device OEM will have experienced their version of that scene in the movie Toy Story, when Rex the anxiety prone dinosaur is urged to calm down in the face of imminent mortal danger with the advice that “this is no time to panic”. “But this is the perfect time to panic!” counters Rex.
When a Common Vulnerability or Exposure (CVE) makes the headlines on CNN or the BBC, embedded software engineers have discovered their perfect time to panic. From the CEO downwards, everyone wants to know, “Are we affected?” and if so, “What are we going to do about it?”.
There are many reasons to maintain a Software Bill-of-Materials (SBOM), but a security breach is the most immediate and powerful.
According to the US government’s Cybersecurity and Infrastructure Security Agency (CISA), an SBOM is “a nested inventory, a list of ingredients that make up software components”.
An SBOM provides the answer to:
- What software packages is a device running?
- What are their sources; are they open source or proprietary?
- Which versions of the software is the device running?
- Under which licenses is software used?
This information enables engineering executives to make informed and intelligent decisions about whether a device is at risk from a CVE, and if it is, how best to eliminate the risk.
An SBOM has other benefits as well, including protection from litigation of infringing licensing terms, and facilitating due diligence by potential investors or acquirers.
Yet the embedded software industry has not been in the habit of creating and maintaining SBOMs. This is in contrast to the practice of hardware developers. In the automotive industry for example, a bill-of-materials is associated with every vehicle’s chassis number, enabling manufacturers to identify every vehicle at risk if a safety flaw is discovered. The information in the bill-of-materials enables the recall of affected vehicles for inspection and repair.
Impetus is growing, however, for device OEMs to implement SBOMs. Fueled in particular by President Biden’s executive order requiring SBOMs for software used by or supplied to the federal government. Worldwide concern in the wake of the recent Log4J Java vulnerability highlights the urgent need to take SBOMs seriously. Legislation under consideration by both the US and the European Union will mandate SBOMs for regulated products.
As well as being an antidote to corporate panic attacks, an SBOM is set to become a legal requirement. Forward-thinking embedded device OEMs are anticipating the change and figuring out how best to implement SBOMs in the now.
Absence of Agreed Industry Standard
The need for SBOMs has given rise to a growing market of tools and utilities—and this creates uncertainty for device OEMs. In the absence of a single agreed standard for classifying and exchanging SBOM data, software engineers are understandably wary of committing resources to a tool or standard that might fail to be adopted industry-wide. Creating and maintaining an SBOM can also be a dauntingly laborious, expensive, and—to be frank—tedious task.
A Solution That Automates It All
The solution to both problems is available and ready to deploy now for users of the FoundriesFactory® deployment accelerator. FoundriesFactory provides a secure-for-life application deployment system where any device OEM can avoid the cost and difficulty of developing, securing, and maintaining its own Linux®-based platform.
Included is a built-in SBOM generator. Because FoundriesFactory is a completely integrated development-to-deployment system, this SBOM generator provides not only an inventory of all the software on a device, but the development history. This history includes any commentary attached to a commit decision for each version of the deployed software. This gives OEMs full traceability of the software running on every production unit.
When using FoundriesFactory, OEMs do not have to commit resources to generating and maintaining an SBOM—it does this for them.
Users also do not have to worry about which standard their SBOM implementation is going to comply with. This is because the FoundriesFactory SBOM generator is future-proof: it currently supports the Linux Foundation’s SPDX® project, yet can be modified to support any project—such as CycloneDX—which might emerge as the dominant industry standard.
Equally important, the generator provides a comprehensive SBOM output in a Comma-Separated Values (CSV) format. The CSV file provides the software package’s source, version number and license type. Each of these parameters can be sorted in classic spreadsheet style.
The question “Are we affected by a new CVE?” can be answered with just a few clicks.
Accelerated Deployment of Security Patches
FoundriesFactory fully automates the generation of an SBOM, providing full traceability through the development process, and ties an individual SBOM to every production unit. It also accelerates an OEM’s response when a vulnerability is detected. Thanks to the deep integration of the FoundriesFactory development-to-deployment workflow, the process of developing and deploying a patch is seamless and simple. Traditionally, deploying a patch to embedded devices would have been a development project in its own right, requiring multiple engineers and months of anxious work. With FoundriesFactory, even a certain T-Rex wouldn’t panic.
Be SBOM-Ready the Easy Way
SBOMs are coming to the connected embedded device industry, like it or not. Forward-thinking OEMs and their developers will like it. And the FoundriesFactory integrated and automated SBOM generator will make them like it even more.
You can trial FoundriesFactory free for 30 days to find out for yourself how easy SBOM management can be. Experience the benefit of ensuring your full range of products are secure for their entire lifecycle.
Linux® is the registered trademark of Linus Torvalds in the US and other countries.