Manufacturing and the food industry have long provided information about products’ ingredients and constituents. F-TAG asks whether it is time the software industry did the same.
Using pre-written software components as part of application code is not new. The problem is, of course, can you vouch for those components’ security and integrity? Can you really trust them?
Last year’s Log4j vulnerability, a critical flaw in a widely used open source logging library, saw organisations across the globe scrabble to work out if they were open to resulting exploitation. The result saw firms embroiled in costly, time consuming and manual work to identify and isolate systems which relied on Log4j.
In its wake, the Log4j incident left many asking about how we can avoid similar problems. One answer might be a software bill of materials or a SBOM for short.
What are SBOMs and how do they work?
Organisations like Component Source have been around for over 25 years, offering over 2,000 different software components of different types on a fully commercial basis. Similarly, there is a thriving community of open source software component development represented by sites like GitHub where active contribution in creation and evolution of components as well as consumption of them is carried out at huge scale.
Recent research has shown that the majority of software produced today uses existing software components to some extent. An anonymised study of over 1,100 commercially available applications as far back as 2017, showed that 96% of the applications contained significant numbers of open source components in combination with proprietary code. There was an average of 257 components per application, making up over half of the code base.
SBOMs and open source
Organisations rely on open source and third-party software applications and components to successfully deliver their services, yet there is an issue in the lack of basic visibility into the quality, security and composition of the software components.
Today’s lack of transparency makes software supply chains an easy vector for attack. With increasing numbers of supply chain vulnerabilities surfacing such as the recent Log4J issues (4) it is too often a reactive, manual and very costly exercise to mitigate with an all-hands-on-deck process being adopted by organisations.
An improved industry approach is needed as cyber security is a commercial and national imperative. Cracks in security can have profound consequences including:
- Service loss
- Financial loss
- Reputational harm
- Breach of legal obligations.
Indeed, the application security community has recognised for a long time that using software components with vulnerabilities is a real risk. The OWASP Foundation (Open Source Web Application Security Project), has using components with vulnerabilities at number six in its top 10 security risks of 2021.
Software bill of materials (SBOMs) providing visibility is the first step in getting to an improved security posture by supplying details on what libraries and frameworks software and services use. A better understanding of potential risks when the products and services are deployed enables proactive rather than reactive management of the software estate. It also enables an increasing use of automation.
How SBOMs need to mature and develop
The software industry needs to mature so that supplying SBOMs becomes the norm when purchasing software, with the security annex for new contracts containing an entry to require a full SBOM for any service to be consumed.
Additionally, an argument can be made for legislative intervention to mandate adopting and publishing SBOMs enabling effective identification and description of software components. This will improve the key national infrastructure supply chain and mitigate risks from future cyber-attacks.
A SBOM needs to contain:
- Unique identifiers for the component and data describing version information
- Supplier details
- Dependencies
- Open-source licenses
- Date of generation
- Tool used to generate
- Checksums / hashes to ensure integrity and artefact specific metadata.
SBOMs could be produced for artefacts covering the complete software development lifecycle (SDLC) including:
- Source code
- Libraries
- Application executables
- Container images
- Published software.
As SBOMs are intended to be shared, consistent standardised formats are required. Ideally, they need to be both human and machine readable. Several standards have been suggested with the following formats gaining some popularity and acceptance:
These three standards have been developed by different open-source projects and governments to solve particular use cases and differ in terms of scope of coverage and roadmaps.
SBOMS in operation
Modern DevSecOps practices utilise continuous integration pipeline tooling to automate functions such as testing and code quality. Software composition analysis (SCA) tools are used to monitor for known third-party and open-source vulnerabilities and control what is permitted for use.
For you
BCS members can read the very latest F-TAG technical briefings and reports.
They provide inventory capability, offering a clear picture of third-party and OSS components in use in vulnerability management and mitigation. The generation of such data during the SDLC process forms an ideal basis for the generation of SBOMs, which can then be published alongside the software, as long as standards can be agreed.
An analogy can be drawn with common vulnerabilities and exposures (CVE) databases and services today, which provide data on cyber security vulnerabilities to organisations and governments. It is plausible to see the similar evolution of SBOMs as a service (SBOMaaS) type capabilities as a suite of SBOM services that provides visibility into the open source and licensed software that could be relied upon by the public, organisations and governments.
This, in turn, would support fully integrated software supply chains providing full end-to-end transparency, visibility, and traceability.
Within organisations, application portfolio management typically works at the granularity of the application but technology lifecycle management (TLM), technical debt and risk management programmes need to work at the component level of applications to be fully effective.
SBOMs enable proactive obsolescence management and risk management from the presence of individual obsolete technology components rather than just at the granular application level. Service management tooling could then continuously monitor, identify, assess, and respond to risks from components that may negatively impact business operations.
The Linux Foundation recently published an extensive report into the state of SBOM and cyber security readiness. It recognised the extensive potential benefits of widespread SBOM adoption, but commented on the current difficulties of evolving and disparate data formats, unique identifiers being a work in progress and the lack of consolidation around a methodology and tooling workflow.
It called for greater visible support from the software and services vendor community to support SBOM adoption. The manufacturing industry has used bill of materials to itemise the contents of products for decades. This allows future component traceability and facilitates product recalls when in-use issues are identified. Similarly, the food industry is legally obliged to list ingredients to enable customers to understand what they are eating.
Isn’t it time the software industry adopted a similar approach and used SBOMs to allow customers to better understand the constituent parts of their product purchases?
