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.
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.