• tl;dr sec
  • Posts
  • BoMs Away - Why Everyone Should Have a BoM

BoMs Away - Why Everyone Should Have a BoM

In this talk, Steve describes the various use cases of a software bill-of-materials (BOM), including facilitating accurate vulnerability and other supply-chain risk analysis, and gives a demo of OWASP Dependency-Track, an open source supply chain component analysis platform.

Author

Clint Gibler
June 10, 2020

In this talk, Steve describes the various use cases of a software bill-of-materials (BOM), including facilitating accurate vulnerability and other supply-chain risk analysis, and gives a demo of OWASP Dependency-Track, an open source supply chain component analysis platform.

A software bill-of-materials (BOM) is the software equivalent of a nutrition label on food: it tells you what’s inside, so you can make an informed decision. This is a relatively new area of focus in the security and tech industry in general, but it is quite important, as it helps facilitate accurate vulnerability and other supply-chain risk analysis.

Steve is the creator of OWASP Dependency-Track, an open source supply chain component analysis platform, a contributor to OWASP Dependency-Check, and is involved in a number of other software transparency-related projects and working groups, so he knows the space quite well.

There a number of factors contributing to the increased emphasis on BOMs, including:

  • Compliance

  • Regulation - The FDA is going to start requiring medical devices to have a cybersecurity BOM, including info on used commercial and open source software as well as hardware.

  • Economic / supply-chain management, market forces - Companies may want to use fewer and better suppliers, BOMs are sometimes required during procurement.

An interesting anecdote Steve mentioned is that in some cases, a vendor not being able to provide a BOM has lead the purchasing company to demand a 20%-30% discount, as they’ll need to take on this operational cost of determining the software’s BOM and it indicates a lack of SDLC maturity, and thus increased risk.

BOMs have a number of common use cases, including:

  • License identification and compliance

  • Outdated component analysis

  • Vulnerability analysis (software and hardware)

  • Documenting direct, transitive, runtime, and environmental dependencies

  • File verification (via hash checking)

  • Hierarchical (system, sub-system, etc) representation of component usag

  • Tracking component pedigree (ancestors from which a component is derived from)

There are several older BOM formats, including Software Package Data Exchange (SPDX) and Software Identification (SWID): ISO/IEC 19770-2:2015. However, these did not fulfill Steve’s desired use cases so he created the CycloneDX) spec, which is lightweight and focuses on security.

CycloneDX uses a Package URL to uniquely identify a version of a dependency and its place within an ecosystem. It looks like this: 

pkg:maven/org.jboss.resteasy/[email protected]?type=jar

The Package URL identifies all relevant compopnent metadata, including ecosystem (type), group (namespace), name, version, and key/value pair qualifiers.

One great aspect of this approach is that it’s ecosystem-agnostic: it can support dependencies on Maven, Docker, NPM, RPM, etc.

Examples of a CycloneDX BOM for a Maven Java dependency and hardware.

At 15:17, Steve does a demo of Dependency-Track, showing how it can be integrated into Jenkins and used to create a combined BOM for Java and NodeJS dependencies.

Dependency-Track is Apache 2.0 licensed, source code is available on GitHub, has social media accounts on Twitter, Youtube, and Peerlyst, and see the following links for its documentation and homepage.

More than just third-party libs
One thing I found interesting, that I hadn’t thought of before, is that you can capture a number of aspects of piece of software in a BOM, beyond just third-party dependencies; for example, the app’s environment, runtime, and hardware dependencies.