Manage how you protect your assets at scale with SBOMs

By Michael Isbitski, Sysdig

The topic of software bill of materials (SBOMs) has gained more attention through recent efforts such as the formation of OpenSSF in August 2020 and the publication of the US National Cybersecurity Strategy in 2023. Large-scale security events such as the SolarWinds hack that was disclosed in December 2020 also spotlighted the issues of software security and its potential ramifications to cybersecurity. 

However, in practice, a distinction must be made between the general concept of bills of materials and digital artifacts, or manifests, that can work for software. While many in industry realize the value of having a software bill of materials, creators still need to generate high-fidelity SBOMs, and software consumers must ingest and enforce actions based on a given SBOM for it to be a useful endeavor. Otherwise, we’re just adding more to the pile of potentially useful but not entirely actionable data that plagues many cybersecurity programs.

The Importance of SBOMs in Software Security

Software is made up of multiple components and dependencies. The concept of knowing what’s in the components you assemble and use within a larger system isn’t new. It’s existed within physical supply chains and the manufacturing industry for over a century. As builders, we need to know what we are putting into machines, vehicles, homes, and more. The software parallel is obvious. We need bills of materials to support development and also ensure integrity, security, and safety. 

Common use cases for SBOMs include:

• Promoting security hygiene – check if a published software component has known vulnerabilities, usually in the form of CVE-IDs. Some recent and well-known examples include known issues with OpenSSL, Apache Struts, Apache Log4j, and Spring Framework. If a vulnerability exists, it’s also useful to know its relative risk, which is often scored using CVSS. Risk factors used in a CVSS score include how difficult a vulnerability is to exploit, whether known exploit code exists, and potential impacts if a vulnerability is exploited. 
• Mitigating legal risk – software licenses are critical when considering user consumption and distribution patterns. Often, this comes up in external consumer scenarios. Attribution and re-distribution may be restricted based on the original license for a given component. Components may be useful within internal lab environments, but production environments may need to use something else entirely as mandated by the commercial or open-source licenses in play.
• Verifying quality – when development teams source components, they’re likely to pick the code that is most functional for their use case. For governance and security though, it’s useful to know more of the history and metadata for a project such as who contributed code, when code was last updated, frequency of code commits, and whether the project is actively maintained.

Software tooling and SBOMs

Unfortunately, software make-up is still often disclosed within terms and conditions (T&Cs). While these documents are human readable, and useful for procurement or legal activities, they are effectively useless in modern DevOps practices where many components are employed with diverse technology stacks. Cloud adoption spawns more heterogeneous environments and component diversity. Cloud-native design patterns and the use of containerization technology make these old approaches untenable. 

This laundry list of components would be quite lengthy, but it would also be stale by the time teams draft the documents let alone get legal approval. Software and infrastructure is delivered at a rapid pace, making manual creation and analysis of such T&Cs impractical. 

CycloneDX, SPDX, and SWID are the most common SBOM data formats. It’s worth stating that the gold standard is still yet to be determined. SWID often makes an appearance in NIST Special Publications, and it’s one of the oldest standards that was defined within ISO/IEC 19770-2 in 2009. SPDX often makes an appearance on the license compliance fronts, and the format has been expanded to support CVE-IDs. CycloneDX is the most recent standard, created by the Open Web Application Security Project (OWASP). 

You’ll commonly find SBOM support in the following breeds of tools: 

• Software composition analysis (SCA) – these tools analyze binaries (or executables) post-build or analyze source code during code commit, build, and delivery. The binary-focused approach is often used for supplier attestation and compliance. The source-code focus is often used within DevSecOps practices and is frequently used in tandem with static application security testing (SAST) and dynamic application security testing (DAST) tools. SCA is the most mature breed of tooling listed here and also the most likely to contain SBOM support. 
• Container image scanning – these tools function similar to SCA, but the target artifact here is container images. Containers are a modern approach to packaging up dependencies and powering applications and infrastructure. Rather than focusing on binaries in file systems or source in code git code repositories, this category of tooling focuses on container manifests and images that move through CI/CD pipelines and are stored within container registries.
• Version control systems (VCS) – these systems cover git-centric workflows and tooling that underpin DevOps and GitOps practices. Engineers commit application source code and infrastructure-as-code to source code management (SCM) or VCS. These days, git is the de facto standard for decentralized VCS, and the VCS is the “last stop” of sorts before something moves through a CI/CD pipeline for delivery. It’s also an ideal spot to implement SCA-like capabilities that can support export of SBOMs. 
• Cloud native application protection platforms (CNAPP) – the newest kid on the block, think of CNAPP as the combination of all of these approaches that are useful for securing modern applications. The goal is to provide analysis and prevention capabilities for code (i.e., shift-left security) as well as protective and threat detection capabilities for running workloads (i.e., shield-right security). A CNAPP should support container and Kubernetes environments as well as serverless functions, virtual machines, and traditional hosts. A CNAPP doesn’t provide VCS functions itself, but it should integrate into VCS, CI, and CD services to provide appropriate security analysis and protection.

Putting SBOMs into practice

Support by vendors within tools is currently a mixed bag, even for just one SBOM standard. The standards may also not support all types of dependencies. For example, REST and GraphQL APIs are fundamental building blocks of modern applications and infrastructure, but they’re notably absent from SBOMs. This obviously leaves many organizations with piecemeal insight into all their software components, requiring manual work to get any SBOM together, let alone keep it up to date. Below, you can observe an example based on the CycloneDX standard focused on traditional packages and libraries. Common platform enumeration (CPE) is useful for quickly identifying component versions and related, known vulnerabilities in the form of CVE-IDs from MITRE.

In practice, you will have to plan for extra engineering effort to make the numerous  tools work in tandem. Putting an SBOM together is not just about printing out a list of components. Presuming you can settle on a format, you’ll still need to export data or integrate the disparate tools via command-line interfaces or APIs. This is a necessary evil by virtue of how software is built and delivered. There’s a required and complex symphony of code repositories, artifact repositories, package managers, CI/CD services, and hosting infrastructure. Not all of those elements will exist in environments you control, particularly as you work with other partners or suppliers and source dependencies elsewhere. 

Many organizations describe this collection of delivery mechanisms and processes as a “software build factory,” and the combination of it all is a software supply chain unto itself. If one component changes at any point in the chain, which happens inherently by virtue of agile methodologies and DevOps practices, ripple effects are created downstream for all consumers of that piece of code. The dilemma is often alluded to as the transitive dependency problem and creates accountability issues with third parties. 

For SBOMs to succeed, we have to deal with all these issues, and we have to make it easier to maintain the relevant data over time.

Get ahead on supply chain security, or else

The US Executive Order 14028, Improving the Nation’s Cybersecurity, makes SBOMs a requirement for US federal entities and their suppliers. NIST’s guidance is also extensive on this front. The US National Cybersecurity Strategy expands further on the criticality of SBOMs as a component of vendor and software transparency. SBOMs are foundational in enabling security and resiliency in critical infrastructure. We can expect movement on the legislative and regulatory fronts which will spur innovation and development of new tools to address the growing cybersecurity risk and hold suppliers accountable. Other nation states will likely follow. 

To meet these requirements, organizations must ensure all their partners and suppliers are doing the “right” things with respect to software transparency. For now, this pertains specifically to those US entities operating critical infrastructure, but expect other organizations and suppliers to follow suit as a way to improve their security maturity. This is similar to how many organizations started following prescriptive standards like PCI-DSS, even if it was unnecessary for their data and environments. SBOMs are a great way for an organization to validate what a supplier is asserting. In practice however, this remains a difficult endeavor where contractual obligations and concerns over intellectual property often inhibit sharing of such information. 

Trustworthy suppliers should at least be able to provide documentation about how they source componentry, validate the security of code, and verify integrity of software as it’s delivered. Ideally, they also provide mechanisms to retrieve the SBOMs for the software they provide, but anticipate that it may still be spotty. We must remember that tooling is still relatively immature and standards are unsettled for the time being; at the same time, preparing your processes and your developers for these changes will pay off in faster adoption over time.

Alongside this, we also have to recognize that digital manifests extend further in technology. We’ve seen the expansion of SBOM concepts into broader software supply chain security where there is a desire to verify all componentry and the linkages between them. This type of manifest is useful for assessing the integrity of a complete package that includes software, all its dependencies, and the infrastructure used to power it. Examples include open-source projects like In-Toto or the combination of Kritis and Grafeas, while commercial efforts include the likes of Google Software Delivery Shield. In reality, this is what many practitioners think of when they refer to an “application.” 

If your CIO or CISO asks whether a given package is in use anywhere in the organization’s environments, many of us would be unable to provide accurate data. The desire to know the current state of all aspects of your environment, in real-time, is fundamental to prioritizing risk and running an effective cybersecurity program. As SBOMs get more standardized and processes get adopted more widely, the goal should be to stay ahead of regulatory changes, and press suppliers for transparency in how they ensure software security. As the supply chain for software continues to grow in complexity, and as attacks on those components grow, SBOMs will provide the groundwork to manage how those assets get protected at scale.

About the Author 

Mike Isbitski is Director of Cybersecurity Strategy, Sysdig. Mike has researched and advised on cybersecurity for over 5 years. He’s versed in cloud security, container security, Kubernetes security, API security, security testing, mobile security, application protection, and secure continuous delivery. He’s guided countless organizations globally in their security initiatives and supporting their business. Find him on LinkedIn.