Using Software Bill-of-Materials to drive change and reduce risk

The practice of software engineering has changed dramatically over the last 20 years. Aside from technological advancements and improved agility, software has morphed from being pure creations to being assembled.

Modern software is assembled using open source components, glued together in complex and unique ways, and integrated with original code to provide the desired functionality. The amount of open source software used can vary dramatically based on the type and size of application, and the technology stack used in the softwares creation. Software containing hundreds or thousands of open source components is not uncommon.

The use of open source software is critical to continue the velocity of technological advancement. Modularity and reuse are valued over re-invent, especially when time-to-market is crucial for success.

While open source software provides the necessary building blocks, it also comes with risk. Organizations ultimately take responsibility for code they did not write. Fear of license compliance, vulnerabilities, and open source projects being abandoned, are real. The Open Web Application Security Project (OWASP) has an article on Component Analysis that provides an overview about the various types of risk organizations should be cognizant of.

Component Analysis is the strategy and process of identifying potential risk in third-party and open source software and hardware components. Component Analysis takes into consideration the entire supply chain and acknowledges that components are created, forked from other projects, distributed, combined, modified, re-distributed, and so on. Tracking and analyzing component pedigree is necessary in order to have comprehensive understanding of inherited risk. The term Software Composition Analysis (SCA) is widely used to describe the practice of analyzing open source components used during the creation of software. The term is a subset of Component Analysis with limited scope. Both practices are part of the wider Cyber Supply Chain Risk Management (C-SCRM) domain.

Market forces and an increased awareness of open source risk have resulted in a need for greater transparency. Globally, governments are attempting to define what that means. Software Transparency is achieved through Bill-of-Materials (BOM). A BOM is synonymous to the list of ingredients on food packaging. Both are an implementation of transparency designed to provide consumers with information they can use to evaluate risk. The terms Software Bill-of-materials (SBOM) and Cyber Bill-of-Materials (CBOM) are widely used to differentiate from traditional BOMs which focused primarily on physical goods.

There are a growing number of organizations utilizing SBOMs. The generation of SBOMs from modern software build environments is easily achievable, even for complex software with thousands of open source components. Financial services, independent software vendors, manufactures, and cyber-security service providers are among the types of organizations utilizing SBOMs today. Much like cyber-security itself, Software Transparency is a journey, not a destination. Organizations first need to be transparent and honest with themselves. They need to collect and analyze the components they’re using. They need to track component pedigree, license compliance, project and technical risks. And they need to have strategy, policy, and governance to reduce risk to a level that is acceptable to market forces, regulation, and compliance. Software Transparency requirements will ultimately come knocking on their door.

There are a handful of SBOM specifications available today including CycloneDX, SPDX, and SWID. We’ll focus on CycloneDX as it’s the newest, it’s lightweight, and it focuses on software security use-cases. Some of the achievable use-cases include:

• Vulnerability analysis (software and hardware)
• Outdated component analysis
• License identification and compliance
• File verification
• Hierarchical representation of component assemblies
• Document a components pedigree including ancestors, descendants, variants, and commits, representing a components lineage from any viewpoint and what attributes make it unique
• Analyze modified open source libraries without any loss of fidelity
• Human and machine readable format designed to be simple to use, extensible, and easily adoptable

The CycloneDX specification is an open source project without a standards organization or committee. The specification has benefited from this approach which has allowed the community around the project to foster and innovate at a rate comparable with the technological change around it. The specification has grown rapidly since its launch in 2017 and has been adopted by several thousand organizations, many of which are automatically creating SBOMs during the development process.

In CycloneDX, everything is a component. Components can be included within other components, and the level of granularity can be defined by the organization utilizing it. This is similar to the system, sub-system, parts assembly that is common in physical supply chains. In general, a component will be the name and version of an open source application, library, or framework. However, a component may also be an operating system or file.

The process of generating CycloneDX BOMs varies slightly depending on the technology stack used, but the approach remains the same; generate one automatically when the software is built. Once the BOM is produced, the components within can be tracked and continuously analyzed throughout the softwares lifecycle. Applications such as Dependency-Track, a flagship OWASP project, are specifically designed for this purpose.

The following is an example BOM with two components. One of the components has been modified and contains pedigree information.

With the introduction of Software Bill-of-Materials into the development process, the traditional SCA approach of scanning build-time dependencies has changed slightly. Organizations may opt to generate BOMs after the fact from their SCA solution, or adopt a BOM-first approach where they can include build-time, runtime, environmental, and other kinds of dependencies and their pedigree, providing a more holistic view of inherited risk. This approach provides a pathway to greater Software Transparency.

Organizations concerned with cyber supply chain risk should investigate the benefits of a BOM-first approach to Component Analysis as well as the available specifications themselves. Correlating the capabilities of each to organizational concerns, should be part of an overall open source strategy.

Cyber supply chain risk affects us all. Collectively adopting a Software Transparency mindset may be our secret weapon to protect our applications and the Critical Cyber Infrastructure they’re built on.

About the author

Steve is a senior security architect for a large SaaS provider and is passionate about helping organizations identify and reduce risk from the use of third-party and open source components. He is an open source advocate and creator of the CycloneDX BOM specification and OWASP Dependency-Track. He’s also a core member of the Package-URL specification, OWASP Dependency-Check, and participates in multiple working groups on Software Transparency. When not devoting time to community projects, he likes to have fun with his family in Chicago.