Exploring the software equivalent to an ingredients list By Tim Mackey

A foundational element of application security is understanding the components that make up the software that powers your business. After all, you can’t work to secure something you don’t know you’re using.

That is where the value of a software Bill of Materials (SBOM) comes in. An SBOM is an inventory of all the libraries, components and dependencies that make up a software application. You can think of it being similar to the ingredients list on any packaged food product. Say, for instance, you buy a mass-produced cheesecake from your local supermarket. You might expect to see soft cheese, graham cracker crumbs, butter and sugar on the ingredient list; dig a little deeper though, and you will find that some ingredients have their own list of ingredients too. In this case, graham crackers introduce flour, honey, salt, soy lecithin, soybean oil, artificial flavoring and so on, into the mix.

Now imagine we learn that one of these ingredients, say the flour used in the graham crackers, had been contaminated. To protect the public a recall should be issued, but to do so first requires knowing there is a contamination, what the source of the contamination was, where else that contaminated ingredient might be used, and so on. Even if the contamination is minor, it still needs to be addressed, and what the resolution process is going to be specific to the type of contamination, where it originated from and how the contaminated ingredient is used.

Bolstering security

But then, the question emerges: how are the consumers protected from purchasing and eating this botched batch of cakes? And who is responsible if such spoiled ingredients are incorporated into the cake’s batter? This ambiguity can quickly take the situation from bad to worse, and therefore, requires organizations to be intentional about the ingredients they use; knowing what is being used and where they come from.

To circle this back to software security, manufacturers also need to be attentive to the software components they use within their applications. The reasons for doing so are multi-fold. On one hand, it is fundamental to building and protecting trust associated with your brand. If your cheesecake is found to be the source of widespread food poisoning, or your broken software leads to a massive breach of sensitive data, it goes without saying that you will lose existing and potential customers. Equally, it is crucial in ensuring you are protected legally. Failing to dedicate the necessary time and resources into bolstering an application’s security can lead to significant financial losses in the form of lawsuits or regulatory fines. In truth though, a moral responsibility to protect end-users from using software components that may contain software security vulnerabilities or software license concerns should be factored in too.

Trust and transparency

Interestingly, the 2023 Open Source Security and Risk Analysis (OSSRA) report found that 91 percent of audited codebases contained outdated versions of open source components, and that most commercial software is based on open source components. Unless an organization maintains an accurate and up to date SBOM, an outdated component can easily be forgotten until it becomes vulnerable to a high-risk exploit.

Where a cheesecake recipe might have a dozen ingredients, modern software can have over 600 components in its ingredient list – even if there are only a dozen explicitly declared components to the software recipe. When dealing with such a large number of components, identifying each component by name becomes particularly difficult.

For example, was the version of openssl used in the application downloaded from GitHub, compiled from an official source tree, distributed with an operating system or embedded in a commercial software package? Each of these versions likely have different authors, or suppliers, and could easily have different configurations and features. Uniquely identifying each version is critical when addressing a risk, such as patching a vulnerability.

The good news is that steps are being taken globally and initiatives are already underway to strengthen software security practices through supply chains. Standard SBOM formats such as Software Package Data Exchange (SPDX) and CycloneDX allow organizations to exchange information as well as build trust and transparency in the way software is created, distributed and used. SPDX is also known as ISO/IEC 5962:2021, which makes it an international open standard.

While most of the recent attention paid to SBOMs can be traced to President Biden’s 2021 Executive Order 14028 on Improving the Nation’s Cybersecurity, the reality is that SBOMs have been quite common with regulators like the FDA or IMDRF as a means to validate the software risks present in medical devices. This same use case is maturing within automotive supply chains and isn’t just an American phenomenon.

Software supply chain

Having said that, there is still some way to go in the maturity of the SBOM market. Although standards do encourage the sharing of information, most organizations are struggling to generate accurate and complete SBOMs and recipients of SBOMs often don’t have processes to benefit from the information in an SBOM. It is also easy to fall into the perception that having a list of components is enough, but really, organizations need to actively engage and manage their software supply chain. One way to overcome these challenges and the complexity of tracking all the components making up an application is to employ an automated software composition analysis (SCA) tool. Automation ensures your SBOM is accurate and up-to-date, taking measures to protect the software your customers depend on. That way, when guidance suddenly becomes law, as happened in the US with Congress passing the Consolidated Appropriations Act 2023 modified the Food, Drug, and Cosmetics Act to require makers of connected medical devices to submit SBOMs with their regulatory filings, the SBOMs for your applications are already accurate and complete.

For a list of the sources used in this article, please contact the editor.