Software Bill of Materials: from security best practice to regulatory preparation

Software has become the backbone of modern business, but the way it’s built has quietly introduced risks that can be hard to find and address.  

Today’s applications are rarely written from scratch, they are assembled from a range of open-source libraries, commercial components, frameworks, and containers, often maintained by third parties who are several steps removed from the final product. 

As these supply chains can introduce risks, often due to vulnerabilities for which we have zero visibility, governments and regulators are now posing a simple but pointed question: do companies know what’s inside the software they build, sell, and use? 

If the answer to the question is currently ‘No’, help is now at hand in the form of Software Bill of Material management platforms (SBOMs), and they are already shifting from good practice to a regulatory expectation.  

And if you’re wondering what an SBOM actually is, think of the ingredient contents found on food packaging. Some of us ignore them, others look for the traffic light system on the front, with green, amber and red indicators for fat, sugar, and salt, helping us make a quick assessment as to whether we want to buy it.  

Software today lacks that equivalent shorthand, which is precisely the problem that SBOMs are designed to solve. They provide centralised storage, tracking, and reporting, that let you assess the cyber security and supply chain risks of software, monitor its licence compliance, and quickly respond to newly disclosed vulnerabilities. 

And it’s for this reason that you’ll see them included in regulations such as the EU’s Cyber Resilience Act, and strongly advised in the UK, as follows: 

For software vendors: 

Principle 1.2 of the Software Security Code of Practice outlines baseline security expectations, which includes maintaining an accurate inventory of software components – effectively, a Software Bill Of Materials.  

For critical services and public sector suppliers: 

For companies and organisations that provide critical services, guidance from The National Cyber Security Centre (NCSC) includes the usage of SBOMs as best practice for managing software supply chain risks. 

For essential public services: 

The Cyber Security and Resilience Bill, expected to receive Royal Assent in 2026, is projected to enforce supply chain security measures for utility digital service providers, data centres, and managed service providers, that SBOMs will support with compliance.  

And as always, regulations should be viewed, not as a hindrance, but as a strong nudge to apply measures that should be seen as best practice anyway.  

Who has responsibility for SBOMs? 

SBOMs sit at the intersection of engineering, security, legal, and commercial strategy. The organisations that treat them as a narrow technical task will struggle, but those that embed them into product governance will gain resilience, credibility and compliance. 

How do you apply the use of SBOMs? 

While no two organisations are identical, the process of adopting and operationalising SBOMs follows a broadly consistent set of steps. These steps apply to both product producers (organisations that develop and ship software-enabled products) and product consumers (organisations that procure, deploy, or operate those products), although the objectives and responsibilities may differ. 

Step 1: Establish SBOM scope, objectives, and governance.

Organisations must first define which products, systems, or services require SBOM coverage, such as firmware, software applications, or containers, and whether they are acting as a product producer, a product consumer, or both. The objectives for using SBOMs should be clearly documented, whether driven by regulatory compliance, vulnerability management, customer requirements, procurement risk, or internal governance. This step should also establish ownership, approval criteria, data retention policies, and rules for sharing SBOMs internally and externally. 

Step 2: Deploy an SBOM management capability.

Once scope and governance are defined, organisations can deploy an SBOM management platform or capability that supports secure storage, lifecycle management, and controlled access to SBOM data. Role-based access should enable collaboration across engineering, security, compliance, and procurement teams. 

For product consumers, this step is especially important to support the ingestion, normalisation, and management of SBOMs received from multiple suppliers at scale, with auditability and traceability over time. 

Step 3: Enable SBOM generation or ingestion.

Product producers must establish repeatable mechanisms to generate SBOMs as part of their development and release processes, using techniques appropriate to their environment, such as build-time generation, binary analysis, or post-build inspection. Product consumers, by contrast, should define processes to collect SBOMs from suppliers, validate their structure and completeness, and associate them with specific products, versions, or deployed systems. This ensures SBOMs are consistent, reliable, and maintained over time rather than created as one-off artefacts. 

Step 4: Standardise SBOM formats, identification, and metadata.

To ensure SBOMs are usable and interoperable across tools and organisations, accepted formats must be defined, along with consistent naming conventions, versioning schemes, and product identifiers. Minimum data quality and completeness requirements should be established so SBOMs can be correlated with vulnerability, licensing, and compliance information. Standardisation is particularly critical for product consumers managing large and diverse software supply chains. 

Step 5: Use SBOMs for risk, vulnerability, and compliance management.

SBOMs should be actively used to identify known vulnerabilities in software components, track licensing obligations, and understand component reuse across products. Product producers use this information to support secure release decisions and customer disclosures, while product consumers use it to rapidly assess exposure to newly disclosed vulnerabilities, prioritise remediation actions, and inform procurement and supplier risk management. At this stage, SBOMs transition from documentation to an operational security control. 

Step 6: Embed SBOMs into the software and product lifecycle.

Finally, SBOMs must be integrated into ongoing development, release, deployment, and operational processes. This includes updating SBOMs as software changes, monitoring newly disclosed vulnerabilities over time, assigning responsibility for response actions, and communicating updates to relevant stakeholders. Treating SBOMs as living artefacts ensures they remain accurate, actionable, and effective throughout the lifecycle of the product or system. 

What now? 

Once an organisation has defined how SBOMs fit into its governance and operational processes, the next step is to adopt a solution that can support SBOMs as a full lifecycle capability rather than a static compliance artefact.  

Our Keysight SBOM Manager is designed to support both SBOM producers and SBOM consumers by enabling SBOM generation, ingestion, validation, and lifecycle management across software-enabled products.  

It focuses on discovering what’s actually present in delivered OS image, software and firmware, particularly compiled binaries and native code, providing accurate visibility even when source code or build systems are unavailable. This allows organisations to generate high-quality SBOMs in standard formats that more closely reflect the software and devices deployed in real environments. 

Beyond SBOM creation, Keysight SBOM Manager provides a centralised platform for operationalising SBOM data over time. It enables secure storage, versioning, sharing, and controlled distribution of SBOMs and related artefacts, while continuously correlating SBOM components with vulnerability intelligence from multiple authoritative sources.  

This allows organisations to assess cybersecurity and supply chain risk with context, reduce vulnerability noise, support scalable VEX generation, and respond rapidly to newly disclosed or actively exploited vulnerabilities.  

By unifying accuracy, vulnerability monitoring, controlled sharing, and consumer visibility in a single platform, Keysight SBOM Manager helps organisations move beyond checkbox compliance and establish SBOMs as a trusted, actionable foundation for software supply chain security. 

Download the Keysight SBOM Manager datasheet. 

We at Red Helix provide and support the Keysight SBOM Manager for companies and organisations in the UK. For more information or to talk to us about your needs, please contact us here, and we’ll get straight back to you.  

Richard Clothier. Senior Product Marketing Manager, Red Helix.