The newest buzzword: SBOM

Yeah, we have a new buzzword - SBOM. We start talking about it but we are not fully sure what we talk about.

But the fact is, it is not a buzzword after all. And it is not new, really.

The law

We all heard about log4j or SolarWinds. This (and many other factors) led Biden's administration to set the Executive Order on Improving the Nation’s Cybersecurity. published in 12 of May, 2021. It contains regulations related to many things like Zero-trust architecture, but also to SBOMs. Every software sold to federal units must contain SBOM. This clearly means that it is not buzzword anymore and it become standard element of the delivery chain. Here is the Executive order. So...

It is time to start learn about SBOMs.

Early stage

I built some picture of current situation during my discussions with experts. We are in the beginning of the road at this moment. Yes, the approach, the tools are with us for some time, but the problem lies in the place where we need to put all puzzles together and have a complete picture.

Software Bill of Materials

So, what is the SBOM? It is an abbreviation (and we, DevOps, we love abbreviations! :) ), it means Software Bill of Material.

SBOMs are kind of ascendants of BOMs - Bill of Materials. According to Wikipedia

A bill of materials or product structure (sometimes bill of material, BOM or associated list) is a list of the raw materials, sub-assemblies, intermediate assemblies, sub-components, parts, and the quantities of each needed to manufacture an end product. A BOM may be used for communication between manufacturing partners or confined to a single manufacturing plant. A bill of materials is often tied to a production order whose issuance may generate reservations for components in the bill of materials that are in stock and requisitions for components that are not in stock.

SBOM is nothing else than BOM for software systems.

NTIA describes it as

A "Software Bill of Materials" (SBOM) is a nested inventory for software, a list of ingredients that make up software components.

So, SBOM contains list of all dependencies, libraries, their licenses, collected from every element of the system.

Standards

Standard here is about the format of the report. The structure and data which are included. As far as I am concerned, there are three most popular standards

• Software package data exchange - SPDX - open source, prepared as machine-readable format, originated in Linux and curated by Linux Foundation
• CycloneDX - CDX - also open source and machine-readable format. Originated in OWASP community
• Software identification tags - SWID - as ISO related project, it is a commercial standard

SPDX and SWID are not new. Yes, the SBOM started to be visible between engineers and technologists (maybe even going to its hype now), but these standards are on market from around 2010. CDX history started around 2017. It is a long time in IT world.

CDX seems to be more tailored to modern needs. One of the significant differences is that CDX contains also information about vulnerabilities. Quite important is the support on the market. CDX is supported and surrounded by many very well known organizations and projects, like RedHat, Aqua, Gitlab, Google, Bridgecrew, OWASP, to mention only a few.

The CycloneDX model on the top level is constructed with 7 layers

• BOM metadata information
• Components information
• Services information
• Dependency relationships
• Compositions
• Vulnerabilities
• Extensions

(Based on CycloneDX webpage)

SBOMs and DevOps

Well, these two looks quite separated from each other. Nothing more misleading than that :)

First, let's take a look on SBOM classification

We have three main categories

• Produce - how SBOMs are created
• Consume - view, understand changes, generally - understand what is in the report :)
• Transform - transformation of the data from one or multiple reports into another type of file with preserving the quality of data.

These three elements should give us a connection to DevOps processes. How to implement SBOMs in the chain? How to differentiate CI from CD parts? How to preserve data and make the data usable?

In this series we will explore the tools and approaches. How to generate SBOMs and what we can do with them. I am not an expert in this field, not yet, anyway. But as Security is one of pillars of DevOps (I see Security not Sharing as 'S' in CALMS), I strongly influence it in our DevOps mindset.

Please, remember that these tools must have one very peculiar functionality. You must know what is unknown. Another words, the software must mark packages, dependencies, vulnerabilitites, etc as uknown, if these cannot be resolved. It is important, as you have to know what you have to do manually.

The series will have some theoretical parts too, it is kind of unavoidable :)

So, let's get started then!

Cover image by Suzy from Pixabay