Part 1: Using SBOMs for enhanced visibility and control
The dynamic nature of software development exposes the software supply chain to countless sources of both known and unknown vulnerabilities. These can take multiple forms, from insecure open-source software to zero-day exploits.
The connected product software revolution’s growing reliance on open-source software increases the risk and potential impact of supply chain attacks through methods, such as malicious injections. Finally, firmware presents a large and ever-expanding attack surface as the number of electronic devices grows nearly as quickly as the chain’s complexity.
To ensure product integrity throughout, automotive and medical device manufacturers are doubling their product security efforts. The search for a standardized process gave rise to the SBOM framework, which is gradually becoming ubiquitous in all product security industries
But, generating SBOMs is only the first step.
To reap the full benefits of this framework, we need to first understand how it benefits the entire organization, and how it can be used throughout the full product security workflow– not just at the beginning. A few case studies that have been published recently, show the many ways to use and leverage an SBOM, that solve more problems than manufacturers previously thought.
Integrating SBOMs into the full product SDLC
A few frameworks exist today for implementing SBOM processes throughout the development lifecycle.
One of the most promising ones is what’s called “Dynamic SBOMs”. Dynamic SBOMs represent a new approach to continuous security which is integrated, automated, streamlined, and enforced at predefined stages within the development workflow. This way, developers don’t waste time and product security teams reduce friction to speed up time-to-market. It’s a win-win for both product security and developers.
Another interesting approach is implementing SecDevOps into the process. According to a recent report by the NCSC and Capgemini titled Using the Software Bill of Materials for Enhancing Cybersecurity, “SecDevOps essentially combines the perspectives on production and operations. DEVops, where it’s all about developing the software, is linked to the Producing Perspective. Where the devOPS is linked to the Operation, because it is about bringing the (new) software into the operation through release, deploy, operate and monitor”.
They further explained, “During development, the SBOM can describe specific libraries (or identify the libraries to exclude), character sets, etc. An SBOM would be made available for any released version of a software product, as part of product documentation. It is important that parts of the SBOM information will be tested every sprint as well. During operations, the SBOM should be monitored and updated on the findings discovered. These could be based on feedback from the field, but they can also be discovered through monitoring.”
Source: Capgemini
Staying up to date with SBOM regulatory requirements
During the past few years, a greater number of standards and regulations have begun to embrace SBOMs. For example, the US government mandates that all current and future government contractors must have produced product SBOMs to avoid potential compliance issues.
SBOMs are also a way to meet prominent industry standards, such as the ones from NIST. Looking at some of the main categories in NIST’s guidelines, we see many standards can be met using SBOMs:
Source: NIST
SBOMs are also a way to meet prominent industry standards, such as the ones from NIST. Looking at some of the main categories in NIST’s guidelines, we see many standards can be met using SBOMs:
However, there are many security standards and frameworks– each with its own flavor of SBOM requirements.
The FDA Cyber SBOM (SBOM) for example differs from the requirements of the ISO. Not only that, but all of these compliance standards are also changing over time and across geographies, requiring manufacturers to continuously update their requirement validation process to stay in business. A lot can be learned from these standards, and how SBOMs can be used to improve both the security and the development processes.
Here are some standards and their mention of SBOMs:
BSA Framework for Secure Software
This industry-drafted framework offers guidance on secure development of software, the security capabilities of the software, and a secure lifecycle, citing standards and other authoritative guidance. It makes repeated references to the importance of cataloging third-party code, including advising “to the maximum feasible through the use of manual and automated technologies, subcomponents integrated into third party components are documented, and their lineage and dependencies traced.”
Building Security in Maturity Model
BSIMM (Building Security in Maturity Model) is a large group of software developers in
academia, government, and industry that benchmark best software development practices.
They create guidelines for organizations benchmark themselves against and assess where
they are relative to their peers in their industry or overall.
Version 9 of the BSIMM contains several SBOM-related requirements.
CISQ Trustworthy System Manifesto
The Council on IT Software Quality (CISQ) has published the “CISQ Trustworthy System
Manifesto” on holding senior executives accountable for cybersecurity. Section III is “Traceable
Properties of System Components” which includes requirement #2: “Evidence of provenance and trustworthiness should be carried forward with components and shared across the supply chain”. This requirement also contains the following description: “When developers incorporate open source components, external APIs, or microservices, they should document their source and related data for inclusion in a System Bill of Materials (SBOM).”
FDA Premarket Guidance
The US Food and Drug Administration (FDA) has published a Pre-Market Guidance draft for
medical device manufacturers seeking FDA certification. This guidance maintains that: “the
device design should provide a CBOM in a machine-readable, electronic format to be consumed
automatically” where Cybersecurity Bill of Materials (CBOM) is defined as “a list that includes
but is not limited to commercial, open source, and off-the-shelf software and hardware
components that are or could become susceptible to vulnerabilities.
FS-ISAC Third Party Governance
The Financial Section Information Sharing and Analysis Center (FS-ISAC) published
“Appropriate Software Security Control Types for Third Party Service and Product Providers” in
- It includes Control Type 3B, “A Bill of Materials (BOM) for Commercial Software to Identify
Open Source Libraries Used”.
ISO
ISO/IEC 27002:2005 and 27002:2013 have relevant sections that highlight the importance of
best practices to ensure adherence to information security control objectives for an organization.
The perspectives identified in this document can be aligned with this international standard to
show its relevance to a broad number of industries that use/produce information systems.
Linux Foundation OpenChain
The Linux Foundation OpenChain project mentionson the use of open source, stating: “A process exists for creating and managing a FOSS component bill of materials which includes each component (and its Identified Licenses) from which the Supplied Software is comprised.”
Manufacturers Disclosure Statement for Medical Device Security
The Manufacturer Disclosure Statement for Medical Device Security (MDS) was originally
developed by the Healthcare Information and Management Systems Society (HIMSS) and the
American College of Clinical Engineering (ACCE), then standardized through a joint effort
between HIMSS and the National Electrical Manufacturers Association (NEMA). The MDS
Form provides medical device manufacturers with a means for disclosing to healthcare providers the security-related features of the medical devices they manufacture.
MITRE Deliver Uncompromised
MITRE, in its report on the national security supply chain, “Deliver Uncompromised”
recommends SBOMs as part of supply chain integrity. It notes, “If done properly, an SBOM can
estimate the overall risk of the ensemble of software elements based on the risk of the individual
elements.”
NIST’s Mitigating the Risk of Software Vulnerabilities by Adopting a Secure Software
Development Framework (SSDF)
A 2019 draft white paper recommends a core set of high-level secure software development
practices. Among these, it recommends that organizations seeking to protect their software
“Create and maintain a software bill of materials (SBOM) for each piece of software stored in the repository.”
OWASP Component Analysis Project
This industry expert group’s guidance on component analysis recommends “SBOMs from vendors and embed their acquisition in the procurement process” and a list of best practices using the SBOM to improve security
Making SBOMs standard
Looking ahead, organizations that proactively examine and assess code that enters their ecosystem via a robust SBOM program will be better prepared for impending government regulations on software supply chains, while keeping their IT infrastructure and customers safer. Strong SBOM programs allow organizations to build secure code in a cost-effective and efficient manner in the face of increasing cyber threats.
There’s still a way to go before SBOM becomes an integral part of the entire product development lifecycle. But new frameworks, regulations, and best practices show how beneficial SBOM integration is to the business. Implementing an SBOM management process, such as the one facilitated by Cybellum’s Product Security Platform will lead to enormous benefits and allow manufacturers to stay compliant and secure in the long run.
This article is part of a series by Ronen Lago, Cybellum Advisor. Read Part 2: How SBOMs Can Forecast Product Security Storms
