Software Bill of Material

When building IT systems DevOps teams often use third party components. These include frameworks, libraries that provide specific functionality, but also code from other teams.

This reuse of components from others speeds up the development of an IT system and brings consistency to the way applications are developed within organizations. Reusability (as part of maintainability) is an important quality attribute and is a sign of properly built components.

We can no longer consider these components as a black box that provides a certain functionality. It is important that we know more about the component that we include or use in our IT system, for example:

• What does the component do?
• What is the purpose for which we need the component in our IT system?
• What are the building blocks that make up the component?
• What is the version of the component?
• Are there conflicting versions of components?
• Are there restrictions on use due to licensing?
• Does a component itself use other components?
• etcetera

Major security incidents, such as the log4j vulnerability in 2021 [Apache 2022], have shown how important it is to have insight into what components your IT system consists of. With the right insight you can react adequately and focus on the right IT systems.

The Software Bill of Materials (SBOM) is the deliverable that provides such insight. The SBOM is increasingly adopted by DevOps teams, and the presence of an SBOM is a sign of the right quality in that area.

Every DevOps team that creates an IT system must build an SBOM. It is a labor-intensive task to do this manually and to keep it up-to-date with every release or change requires a lot of discipline from the DevOps team. Therefore including the (automated) creation of an SBOM from the IT system in the CI/CD pipeline is a good practice which ensures that the SBOM is always up-to-date with the latest version of the IT system. Including an SBOM in the Definition of Done ensures that it is not forgotten, and it is a standard part of the release notes. 

Note with this example: Although the order-management-services don’t use the guava component explicitly, it is used in the application through the usage of the order-utils component. A so-called transitive component. 

Benefits of an SBOM

The benefits of the Software Bill of Materials are endless, three major benefits are:

• Provides insight into used components and dependencies
• Life-cycle management
• Effective security management

Provides insight into used components and dependencies

Often DevOps teams don’t know exactly which dependencies and components are used by their IT system. This problem is easily remediated with the use of an SBOM. 

Life-cycle management

Applying effective LCM requires DevOps teams to know all the version information from dependencies, but also from transitive dependencies. An up-to-date SBOM is the single source of truth for LCM. Assessment of compliancy regulations and policies set by the organization can be validated against the SBOM. 

Effective security management

The SBOM combined with information from security and vulnerability databases can reveal security threats. The impact of newly discovered threats and vulnerabilities can be identified and remediated easily with the insight the SBOM gives.  

Other BOM’s 

• Hardware Bill of Materials (HBOM): Inventory of hardware components for IoT, ICS and other types of embedded and connected devices.
• Operational Bill of Materials (OBOM): Full-stack inventory of runtime environments, configurations, and additional dependencies.
• Software-as-a-Service Bill of Materials (SaaSBOM): Inventory of services, endpoints, and data flows and classifications that power cloud-native applications. 

Sources:
- [CycloneDX 2022] CycloneDX Capabilities (accessed in August 2022) 
- [Apache 2022] Apache Log4j Security Vulnerabilities (accessed in August 2022)