A software bill of materials (SBOM) has become a key element in supply chain security. This list of software components used within a device or system is a topic high on the agenda among regulators, security professionals, and manufacturers.
While device manufacturers and their suppliers face the challenge of creating, maintaining, operating, and distributing accurate SBOMs, regulators are putting effort into finding a harmonised approach to SBOM content, automation, and adoption.
In this article we focus on SBOM and vulnerability management for electronic devices, connected embedded systems, and IoT.
What is an SBOM?
SBOM stands for ‘Software Bill of Materials’. A common definition used by NTIA is:
‘A Software Bill of Materials (SBOM) is a complete, formally structured list of components, libraries, and modules that are required to build (i.e. compile and link) a given piece of software and the supply chain relationships between them.‘
Even though the concept itself is not new, when the FDA released the Pre-market guidance for medical devices in June 2023, the section on SBOM stood out. It was the first time an SBOM became an enforced requirement for medical devices in the United States.
Device Manufacturers stood, and still stand, in front of a great challenge to manage the entire SBOM lifecycle: creating, maintaining, operating, and distributing SBOMs.
The importance of SBOMs
SBOMs are the key building blocks for supply chain security, vulnerability management, and compliance.
Supply chain security
Most vulnerabilities are found in third-party components. To obtain a secure final product, the components used within a device and who is the responsible party for monitoring and updating components must be well understood.
Vulnerability management
An accurate SBOM can be used to look up vulnerabilities in databases, such as the NVD database. This step, as part of the identification of vulnerabilities, is the first step of the Vulnerability Management Process (VMP). Once identified, the vulnerabilities should be triaged, addressed, and disclosed.
The VMP is a continuous process. Identified vulnerabilities should be continuously (re)prioritised and vulnerabilities previously accepted (low risk) or even mitigated should be re-assessed regularly.
To understand the real risk of a vulnerability, it is suggested to have a threat model available, which helps to assess the vulnerability in the intended environment. Other factors, such as the CVSS severity score, are calculated by external bodies without information on the exact use case of the device in scope.
Organisations that implement a strong VMP are more effective in finding, prioritising, and fixing vulnerabilities in their products, leading to more secure products and increased supply chain transparency.
Compliance
SBOMs are currently explicitly requested for FDA’s pre-market application, as well as the (draft) EU Cyber Resilience Act, IEC TR 60601-4-5, and the Radio Equipment Directive (RED). For many other standard, such as ISO 21434, IEC 62443-4-1 and IEC 81001-5-1, an SBOM would be implicitly needed to fulfil cybersecurity requirements as well.
In addition to those standards, there is an increasing number of country-specific initiatives to highlight SBOM best practices, such as
The Dutch SBOM startersgids (‘guide for starters’)
The German BSI Technical Guidelines for SBOM
The Japanese METI’s “Guide of Introduction of Software Bill of Materials (SBOM) for Software Management”
To put SBOMs in use, implementing a Vulnerability Management Process is also required by many standards in the medical, automotive, industrial, or consumer IoT domains.
Elements of an SBOM
A consensus on which elements an SBOM should contain is yet to be reached. However, NTIA has defined a minimum set of SBOM elements, which is widely recognised and adopted. The FDA and IMDRF refer to this set of elements as a baseline for medical devices.
The minimum elements for SBOM as defined by NTIA are:
Supplier name: The name of an entity that creates, defines, and identifies components.
Component name: Designation assigned to a unit of software defined by the original supplier.
Version of the component: Identifier used by the supplier to specify a change in software from a previously identified version.
Other unique identifiers: Other identifiers that are used to identify a component, or serve as a look-up key for relevant databases.
Dependency relationship: Characterising the relationship that an upstream component X is included in software Y.
Author of SBOM data: The name of the entity that creates the SBOM data for this component.
Timestamp: Record of the date and time of the SBOM data assembly.
See NTIA’s Minimum Elements for SBOM for more information and optional elements. Most newer standards define both the SBOM minimum elements and the SBOM format, so it is advisable to refer to the standard of your interest for the exact requirements.
Format of an SBOM
The two main industry-accepted formats are CycloneDX and SPDX. Depending on the exact standard or use case, a specific format might be required.
SPDX, developed under the Linux Foundation, provides a comprehensive framework for documenting metadata about software components, licences, and security vulnerabilities. It aims to facilitate better compliance and risk management across various stages of the software lifecycle.
CycloneDX, created by the OWASP Foundation, is another widely adopted SBOM standard designed specifically for the application security community. It focuses on providing detailed information about software components, including their dependencies and vulnerabilities, to aid in security assessments and vulnerability management.
Both SPDX and CycloneDX contribute significantly to improving the visibility and traceability of software components, thereby enabling organisations to better manage their software ecosystems and mitigate potential security risks.
There is an ongoing effort within the community toward defining either one specific format or improving interoperability between formats. This will help with automation and integration with SBOM tooling.
Which format is right for your organisation depends on the targeted standards and the required level of depth and potential integration with tooling.
The complete SBOM lifecycle
The relevant stages consist of creating, maintaining, operating, and distributing the SBOM.
Creating
To create an SBOM, the supplier should identify the list of components, either manually or (partially) automated. Ideally, the SBOM is considered as part of the software development process.
Maintaining
Every time the code base is adjusted, and a new build procedure activated, the SBOM has to be updated. This scenario happens when
a component has been adjusted
a new component has been added
a component has been removed
This generally happens when a fix or mitigation is implemented, or a new feature is added.
Operating
SBOMs are put to good use when they are used for vulnerability management. As described above, software components can be used to find vulnerabilities by continuously monitoring sources such as public vulnerability and exploit databases.
Distributing
Sharing SBOM information along the supply chain is key. Recently, CISA announced the Sharing Primer, which is a helpful document summarising various SBOM sharing methods and their sophistication level.
How Security Pattern can help
To solve the challenges with SBOM creation, maintenance, and operation, Security Pattern developed the ARIANNA platform. ARIANNA is the product security management platform designed by experts, aimed at Device Manufacturers and their suppliers.
Benefits of the ARIANNA platform
SBOM management: Creation of an accurate SBOM. Automated maintenance of your SBOM with every software update through APIs. Exporting of SBOM in industry-accepted formats such as CycloneDX and SPDX.
Identification of vulnerabilities: Continuous monitoring and reporting of vulnerabilities. SUM can provide more accurate results though improved vulnerability mapping, identifying false positives and automatically closing patched vulnerabilities.
Triaging of vulnerabilities: Automated pre-triage using our proprietary engine reduces the vulnerabilities that need to be analysed to only 10-15% of the total number of identified vulnerabilities. In addition, ARIANNA provides all relevant information to assess vulnerabilities, such as available exploits, severity, and EPSS score.
Management of vulnerabilities: Effectively view the code of available mitigations and fixes.
Compliance: Satisfy requirements from standards and regulations in your industry such as FDA pre-market application, IEC 62443, ISO/SAE 21434, ETSI 303 645, RED, IEC TR 60601-4-5, UL2900 and MDR EU 2017/745.
Want to see the ARIANNA platform in action?
Comments