Product Development
Data Services
About Us
September 23, 2025
3 mins read
A Software Bill of Materials is an itemised list of all the components that make up a piece of software. Think of it like a list of ingredients on a food label — it tells you what’s inside, where it came from, and how it fits together.
An SBOM typically includes details such as:
The name and version of each software component
Origin (e.g. open-source repository, vendor, or internal module)
Licensing information
Dependency relationships between components
While that might sound straightforward, the reality is that most modern software is built from dozens or even hundreds of third-party components. These include open-source libraries, frameworks, operating system packages, drivers, and more. Without a clear SBOM, it’s almost impossible to track all those elements, let alone understand their security posture.
The security landscape has shifted dramatically in recent years. Many major vulnerabilities — from Log4Shell to Heartbleed — didn’t come from bespoke code, but from dependencies deep in the supply chain.
An SBOM enables you to:
Identify vulnerabilities quickly – When a new CVE is announced, you can immediately see if you’re affected and where that component is used.
Reduce attack surface – By understanding your dependency tree, you can remove unused or outdated libraries that might introduce risk.
Strengthen incident response – In the event of a breach, knowing exactly what’s in your software helps you respond faster and more effectively.
A well-defined SBOM can be especially useful for particular areas of technology such as IoT products, where devices are often deployed in the field for years and updates are infrequent, having this visibility is even more critical. A well-maintained SBOM can significantly reduce long-term security risks.
Legislation is catching up with the reality of modern software supply chains. Requirements to produce or maintain an SBOM are increasingly appearing in procurement standards, government guidance, and cybersecurity frameworks.
For example, the EU’s Cyber Resilience Act (CRA) — which we’ve covered in detail in our Understanding the EU Cyber Resilience Act (CRA): The New Standard for Digital Product Security blog post — is set to make software supply chain transparency a legal requirement for many products.
Under the CRA, manufacturers of connected devices will need to demonstrate how they manage vulnerabilities and ensure ongoing product security — and an SBOM is one of the most effective ways to do that.
Even beyond legal compliance, many enterprise customers now expect an SBOM as part of procurement or due diligence. Being able to provide one isn’t just about ticking a regulatory box — it’s about building trust.
Creating and maintaining an SBOM doesn’t have to be an onerous task. Most modern build pipelines and dependency management tools can generate them automatically. The key is to treat the SBOM as a living document — it should evolve as your software does.
Some best practices include:
Automate generation as part of your CI/CD pipeline.
Store SBOMs in version control alongside your code to maintain a historical record.
Integrate vulnerability scanning tools that use SBOM data to alert you to risks.
Share SBOMs securely with customers, regulators, or auditors when required.
In an increasingly regulated and security-conscious world, a Software Bill of Materials is no longer optional. It’s a foundational part of building secure, trustworthy, and compliant software — especially in the IoT space, where the impact of vulnerabilities can be significant and long-lasting.
At The Curve, we help organisations design, build, and deploy software with security and compliance built in from day one. Whether you’re developing connected devices, digital platforms, or large-scale IoT solutions, integrating SBOM practices into your development process is one of the smartest moves you can make.