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

Software underpins modern business, but the way it is built has introduced hidden risks that are difficult to detect and manage.  

Most applications are no longer written from scratch; they are assembled from open-source libraries, commercial components, frameworks, and containers, often maintained by third parties far removed from the final product. 

These complex supply chains introduce risk, frequently through vulnerabilities that organisations cannot see. As a result, governments and regulators are now asking a direct question: do companies know what’s inside the software they build, sell, and use? 

If the answer is “no”, Software Bills of Materials (SBOMs) provide a clear path forward and are rapidly moving from good practice to regulatory expectation. Much like ingredient labels on food, SBOMs offer transparency into software composition, helping organisations quickly assess risk. 

By providing centralised visibility, tracking, and reporting, SBOMs enable organisations to understand security and supply chain risks, manage licence compliance, and respond quickly to newly disclosed vulnerabilities.  

This is why SBOMs are now appearing in regulations such as the EU’s Cyber Resilience Act and are strongly encouraged 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 SBOMs? 

There are six essential steps to applying SBOMs in a meaningful way. Which we’ll be exploring at our Future Networks LIVE event on 28th April at Green Park, Reading. From defining scope, to embedding to software lifecycles and everything in between, we’ll cover the steps required for ensuring successful roll-outs and on-going application. 

Click here for more information and registration.