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.

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)

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

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.

BoMs Away - Why Everyone Should Have a BoM

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.



Source link