Exploring the Plurality of SBOM
The expansive cyber threat surface of the modern software solution is driving the recent interests in software bill of materials (SBOMs). In recent events, the Solar Winds supply chain attack and the Log4J security vulnerability left many wondering how they could gain greater transparency into the software supply chain. The answer has been there for a while, given that the Software Package Data Exchange (SPDX) had been introduced back in 2011, but logistic, programmatic, and frankly the will to invest time and money in SBOMs had fallen below the threshold for most teams.
The tipping point for SBOMs is linked to President Biden’s Executive Order (EO) 10428, Improving the Nation’s Cybersecurity, Section 4(e). In the EO it offers guidance for software producers, including a requirement that they are “providing a purchaser a Software Bill of Materials (SBOM) for each product directly or by publishing it on a public website.” With the stroke of a pen, the Biden Administration brought the generation of SBOMs to the forefront of cybersecurity conversations. The 20-word sentence is easy to read and understand, but the activities, the implications, and the true gem, finding cybersecurity value in the SBOM, are complicated and elusive.
Let us start by quickly reviewing what is in an SBOM. At the highest level it is just a collection of metadata describing the software components "delivered” by a supplier. According to the National Telecommunications and Information Administration (NDIA), an SBOM “should include coverage for all software components delivered by a supplier, whether these are internally incorporated components of a software application, runtime dependencies, or the contents of a container.” For example, the integrated development environment (IDE) and the debugger are not “delivered" to a software consumer, and so they are not typically represented in an SBOM. NTIA also notes that SBOMs from a Managed Service Provider are ill-defined. For our purposes, SBOM in this post will be narrowly defined to software distributed to a software consumer.
Further, NTIA has captured a recommended set of minimum elements that should be included in every SBOM: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of the SBOM Data, and Timestamp. In this list, supplier means the originator or manufacturer of the software component. For example, in a Softrams produced SBOM provided to a purchaser it would state that the supplier is CNCF for the component fluentd. There are many other highly valuable fields to include in an SBOM, like integrity verification fields that capture the hash of the component to prove that it has not been tampered with. There are also two leading formats to pick from, including SPDX and CycloneDX.
And this is where things start to get a bit hairy.
The EO stipulated guidance on providing but not mandating. In fact, the draft NIST SP 800-218, Secure Software Development Framework (SSDF) attestation form published by CISA last month doesn’t include any fields or definitive guidance stipulating that a corresponding SBOM submission is required.
Moreover, the EO, NTIA, CISA, NIST, the media, and industry pundits often tend to speak of SBOM and its collection of fields in the singularity. Acquisition personnel will make statements like we will require that the software producer provide us with an SBOM for the application. When this statement is reconciled against modern microservice architectures, the cardinality is actually plural, not singular. In practice, an application designed against a large microservice architecture may require the software vendor to assemble and distribute dozens of SBOMs. One might consider coalescing the data into a single SBOM, but doing so results in a loss of fidelity that most advise against. Yet, ironically, to answer a trivial question like “How many software components are in application XYZ” you must aggregate and de-dupe the data.
If we pivot further into the plurality of SBOMs, CISA guidance captures six distinct types of SBOMs: design, source, build, analyzed, deployed and runtime. Design represents a conceptual collection of software components that could be used to respond to an RFP. Source and build are generated from software composition analysis (SCA) and build process ephemeral data, respectively. Analyzed is the creation of an SBOM by inspecting the post-build artifacts. Deployed and Runtime differ in that the former looks at what was physically placed on a system while the latter looks at what components are used during execution, which are not always identical.
The value proposition of SBOMs diminish dramatically if they are treated as a point in time compliance checkbox operation. What we mean is that if submitting an SBOM is only required upon initial delivery of the software to the purchaser, the data will become stale quickly since we all know that software is never done. Now, contrast this against mature agile teams like those found here at Softrams that successfully deliver multiple releases of the software per day through the CI/CD pipeline. Even in a minor release with non-breaking API changes the version number of a package could change or the log aggregator library could be completely replaced with a different provider. The logical conclusion is that SBOM submissions to the software consumer must either be on-demand pull by the purchaser or automated and pushed out to a specific API endpoint. It also implies that historical versions of the SBOM must be maintained because not all systems are upgraded at the same time, especially in cyber-physical systems where the deployment number is in the thousands.
Reflecting on the plurality of the SBOM, we quickly realize that the combinatorics of six distinct types of SBOMs, a modest sized application’s microservice architecture, and the frequency of releases through a modern CI/CD pipeline creates wave of SBOM data. Given the relative ease of automating the creation and distribution of SBOMs, the generation side of the equation is straightforward to understand. In contrast, the realization hits that SBOM consumption is the greater challenge. The industry is still exploring how cybersecurity and infosec teams can effectively leverage this wave of data to improve the overall cybersecurity posture. The next time you hear someone speak about requiring an SBOM, pause to consider the actual plurality of that statement!
In the next blog in this series, we’ll take a deeper dive focused on SBOMs consumption.
