The evolving threat landscape and the imperative for transparency
The scenario of a major vulnerability discovered on a Friday afternoon is every security professional’s nightmare. But when there is a vulnerability, do we know exactly what to do, or is it another weekend wasted? As software is now very complex, the need to understand what it is composed of and properly manage it has become fundamental. Following the infamous SolarWinds attacks in 2019, US and UK governments recognised the urgent need for supply chain transparency in complex federal systems. On a broader scale, the European Union’s Cyber Resilience Act (CRA) extends this, setting baseline requirements for all digital products across their full lifecycle, not just development.
The CRA requires software to “be made available on the market without any known exploitable vulnerabilities”. But what does that mean? Software inherently has defects, but not all of them are exploitable vulnerabilities. Critically, vulnerabilities are tied to components, and these components directly contribute to the overall attack surface. So, in order to effectively protect digital products, we need to know what components are being used.
Consider a restaurant asking about allergies before you order. This is their initial risk management. To answer, they need to know precisely what is in every meal, and where the ingredients come from. Unfortunately, software is more like a generic burger with no ingredient list. This is precisely where the Software Bill of Materials (SBOM) becomes indispensable.
The Software Bill of Materials (SBOM) explained
An SBOM is far more than a simple document. It is a machine-readable, detailed description of your application, designed for sharing across internal teams, with customers, and even regulators. It is a crucial part of risk strategy.
An SBOM fundamentally consists of three vital parts. The first is metadata or information about the SBOM itself, such as who created it, how it was created, and when it was created. The second is information about component and their attributes. Lastly, there are the relationships between those components. The latter is key because there are different types of relationships within software. Some parts of an application are directly used, and some are implicitly brought in.
Two primary international standards govern SBOMs. SPDX (Software Package Data Exchange) is developed from the open-source licence world and the Linux Foundation, and CycloneDX, which is developed by OWASP community. Cyclone DX is evolving, very community-led while SPDX is a little slower in its evolution. They are meant to cover the same scope and deviate somewhat, but tools should be able to interoperate between the two standards.
SBOM types and lifecycle
The type of SBOM you need will depend on what you can do with the data within it, on your own use case and phase in the SDLC. At the design level, an SBOM will probably be used to specify dependencies. For example, “I am going to use React”. At this stage, you are not specifying which version of React. Further down the SDLC, the SBOM will get much more precision, specifying particular versions, the operating system, and hardware platform. Vulnerabilities are usually identified towards the end of the process. While vulnerabilities can be found in the development process, ultimately, the vulnerabilities on your product as deployed to market are key.
Historically, generating an SBOM was seen as the end goal, like a last-minute release note. However, generation is just the first step of the SBOM lifecycle, and it has its own challenges. For one, different SBOM generators can produce vastly different results based on language, environment, and target, potentially missing hundreds of components. Therefore, relying on a single tool is ill-advised. Instead, due diligence is to be performed, as well as testing against “ground truth” scenarios, and comparing outputs. The community actively works to improve SBOM generation quality, but industry-wide consistency remains a challenge.
Analysing and consuming SBOMs
Generating an SBOM is just the first step; the real value lies in its analysis and use. This transforms SBOMs from static documents into dynamic tools for security and risk management. First, it is crucial to assess the quality of the components included – particularly looking at whether each package’s licence is clearly identifiable and how current the packages are. Performing this analysis regularly allows teams to catch errors, track changes over time, and even predict when updates are likely to occur, which is useful for deployment planning (e.g., avoiding updates or releases on Fridays).
One of the more complex aspects of SBOM analysis is dealing with dependencies. Each ecosystem handles dependencies differently, meaning every version of a project may require a uniquely structured SBOM to accurately reflect its components. Effective SBOMs clearly delineate direct (explicitly used) from implicit dependencies. Tools that visualise these relationships are essential, especially for diverse audiences like compliance teams and regulators who may not read raw JSON or XML.
It is obvious that SBOMs bring bad news. When they do, it is about prioritizing the known unknowns as not every vulnerability is critical. Prioritisation is to be risk-based, tailored to your business context and customer impact, rather than rigid metrics. It is also a continuous process, requiring regular regeneration and new baselines.
The naming challenge and precision
A challenge in the realm of SBOMs is managing diverse software languages and accurately naming components. Many widely used programming languages, like C, C++, and COBOL, lack modern dependency management ecosystems. A major hurdle is the ambiguous naming of software components, which can exist in multiple language-specific versions. This lack of precision makes it difficult to decide if a system is affected by a vulnerability in a specific component.
To address these issues, the industry is moving towards more precise naming conventions for software components. As an identification standard like CPE (Common Platform Enumeration) is often inconsistent and reactive, Package-URL (PURL) is an emerging standard that aims to provide a more consistent and detailed way to identify software, including its version, operating system, and architecture.
Open-source software is ubiquitous and invaluable, but its widespread use necessitates clearly understanding its components and, crucially, their licences. Again, precision in licence identification is indispensable as SBOMs must use precise identifiers (e.g., “Apache-2.0” instead of “Apache 2”). Knowing the ultimate supplier, even a “one-man band,” is critical for deep supply chain diligence required by compliance standards like ISO 27001.
Beyond developers: the many consumers of SBOMs
The utility of SBOMs extends far beyond development teams. Operations, CISOs, CIOs, CEOs, and CFOs all have a vested interest in SBOM data for understanding risk, managing assets, and protecting reputation. Furthermore, customers should also be active consumers of SBOMs. When SBOMs are generated, they should also be used and not merely filed away. It is important to ensure they are available for sharing. Various initiatives are currently working to make this sharing process more effective and streamlined.
The bigger picture
SBOMs are not a new concept. They exist in a wider context of security and integrity initiatives, next to HBOMs for hardware, SaaSBOMs for software as a service, CBOMs for crypto, MLBOMs for machine learning, and many more. Hooking the SBOM into the CMDB (Configuration Management Database) allows you to start getting a different viewpoint of where your software is situated and seeing the bigger picture of the supply chain. SBOMs integrate with tools like Sigstore and SLSA Supply Chain Levels for Software Artefacts, addressing supply chain integrity issues.
While SBOMs are most commonly associated with vulnerability management and licence compliance, their applications are much wider, including support for ESCROW, mergers and acquisitions, and of course increasing regulatory compliance requirements.
Vulnerability management with SBOMs
When a vulnerability is flagged, common responses range from ignoring it to dismissing it as irrelevant. However, the CRA, for one, will mandate a more rigorous approach: you must analyse and communicate the impact of vulnerabilities. SBOMs, being a “moment in time” snapshot, require an ongoing triage process. Not all detected vulnerabilities are material or exploitable in a specific context. This requires documenting decisions – explaining why a vulnerability, though present, does not apply due to specific architecture, build environment, or other factors.
This communication and documentation are core to Vulnerability Exploitability eXchange (VEX). VEX provides a standardised way to share information on a vulnerability’s exploitability likelihood, enabling organisations to triage vulnerabilities, determine if they are truly affected and document any suitable countermeasures.
Understanding exploitability is indeed a spectrum, from no evidence of exploitation to active exploitation. Crucially, vulnerabilities often relate to specific functions within components, not just the components themselves. The industry is still developing ways to precisely document which functions are used to inform exploitability.
Click here to contact Anthony Harrison (cf. infra-picture)
