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?
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.
A Software Bill of Materials (SBOM) is a formal record containing the details and supply chain relationships of various components (e.g., libraries, open-source components, proprietary code) used in a IT system.
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.
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.
- 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.