Integrating SBOMs into Your DevOps Practice

Estimated time to read: 8 min

A Software Bill of Materials (SBOM) plays a vital security role in modern software development, especially in the context of cloud-native applications. By providing an inventory of software components and dependencies, SBOMs enable effective vulnerability management, ensure license compliance, and promote software supply chain security.

In this post, we’ll explore how SBOMs fit into your DevOps model and practice. We’ll consider definitions, benefits, standards, and tools. Then, we’ll provide in-depth coverage of the steps involved in integrating SBOMs, considering challenges and solutions along the way.

Let’s begin by exploring some core concepts of SBOM for DevOps.

Understanding SBOMs

A SBOM is a structured document that lists all the components used in building an application or system. For each component, the SBOM includes information such as the name, version, and origin, as well as its relationship with other components. A SBOM is like a list of ingredients, but for software.

Simplifying and standardizing systems to dodge challenges

OpenTelemetry enables developers to avoid common challenges that arise when monitoring complex computer systems. In this section, we will study how OTEL counters common challenges, including an increasingly diverse application portfolio, and applications that run on different rules.

Elements of a SBOM

A SBOM consists of several elements:

*Software components: the individual pieces of software that make up your application or system. This includes libraries, frameworks, modules, and any other code used to generate executable files.

*Dependencies: other components or libraries that are required for the software to function correctly.

*Metadata: data that accompanies each component, including details such as the component's name, version, licensing information, and its origin or source.

Benefits of a SBOM

SBOMs offer various benefits to software development and management:

Vulnerability management: SBOMs enable effective vulnerability management by providing a clear view of the software components and their associated vulnerabilities. A SBOM helps identify and track components that have known security vulnerabilities, allowing prioritization and application of necessary patches or updates.
License compliance: SBOMs provide visibility into the open-source and other licenses of the software components used. A license compliance report lets you verify that the licenses align with your organization's policies and legal requirements. The easy identification of components with incompatible or non-compliant licenses provide clarity and guidance for appropriate actions.
Software supply chain security: SBOMs enhance software supply chain security by providing insights into the origin and integrity of software components. With a SBOM, developers can trace the sources of each component, identify potential risks or malicious code, and make informed decisions regarding the trustworthiness of the software supply chain.

SBOM standards and formats

Several standards and formats have been developed for SBOMs, including:

Software Package Data Exchange (SPDX) is a widely adopted standard for sharing SBOM information. It provides a common format for describing software components, their licenses, and related metadata.
CycloneDX is an open standard for describing software components and their dependencies. It aims to simplify the exchange of SBOM data between different tools and systems.
Software Identification (SWID) tags provide a standardized way to uniquely identify and describe software components. They can be used as part of a SBOM to provide additional information and improve software asset management.

Several tools and frameworks facilitate the generation and utilization of SBOMs:

DependencyTrack is an intelligent Component Analysis platform that allows organizations to identify and reduce risk in the software supply chain. The tool is helpful in SBOM analysis by offering continuous integration, continuous insight, and continuous transparency. Cisco uses DependencyTrack to aid in open-source projects.
OmniBOR is a tool that focuses on generating SBOMs specifically for open-source projects. It automates the process of collecting component information, including licensing details and dependencies, to create comprehensive SBOMs.
Trivy is a vulnerability scanner that can be used to check software components and containers for known vulnerabilities. It integrates with SBOMs and can provide vulnerability information based on the components listed in the SBOM.
VMClarity is an open source tool that helps detect vulnerabilities through agentless detection and management of virtual machine SBOM. The tool protects against security threats such as vulnerabilities, exploits, malware, rootkits, misconfigurations, and leaked secrets.
KubeClarity) is another Open-Source Vulnerabilities scanner that detects and manages SBOM and vulnerabilities of container images and filesystems. KubeClarity scans runtime Kubernetes clusters and CI/CD pipelines to enhance software supply chain security.

The Role of SBOMs in DevOps

SBOMs naturally fit into the DevOps (and DevSecOps) model. DevOps focuses on employing software engineering techniques and automation to manage, operate, and secure large-scale systems.

When it comes to a DevOps process for ensuring software supply chain security, the solution can’t be found in a manual process, such as tracking dependencies in spreadsheets. Rather, a DevOps approach to software supply chain security depends on standardized, accurate, and up-to-date dependency metadata. This is what SBOMs provide.

On the other side, DevOps promotes automation, which provides several benefits such as:

Efficiency and Accuracy
Scalability
Continuous Monitoring
Integration with Security Tools
Audit and Compliance
Automated testing

To this list, we can add one more area where DevOps automation can shine: generating and maintaining SBOMs.

Now that we’ve seen how SBOMs fit into DevOps, let’s consider some concrete ways that we can integrate the two.

Steps to Integrate SBOMs into DevOps

In this section, we’ll focus on the actual tasks and activities related to SBOMs and how to integrate them into the DevOps lifecycle.

SBOM generation

Whenever adding a new software component or dependency to your system, you should automatically generate an updated SBOM. This can be done as part of your CI/CD pipeline by running a SBOM generation tool, such as in-toto or OmniBOR.

In-toto

In-toto achieves this by creating a chain of metadata (a layout) that records the supply chain steps and crypto-signed evidence for each software component, ensuring traceability and integrity. In-toto collects information about software artifacts, their sources, and the operations performed on them, which is then used to generate a comprehensive SBOM. The final result captures details such as provenance, pedigree, and integrity.

OmniBOR

Mentioned earlier, OmniBOR is focused on enriching the SBOM aspect of the supply chain (unlike in-toto, which focuses on the security of the entire software supply chain). OmniBOR generates an artifact dependency graph (ADG) that extends existing SBOM formats such as SPDX, CycloneDX, or SWID. OmniBOR also aims for zero developer effort. It generates the Git-based ADG automatically for you when using programming languages and CI/CD systems that incorporate OmniBOR.

Tracking and updating SBOMs

SBOM generation is not a one-and-done process. Whenever any component referenced in a SBOM changes—such as code changes, dependency version upgrades, new build or deployment targets, and even the build toolchain itself — a SBOM must be updated. Again, this process of checking for changes and updating SBOMs can be automated and made a part of your CI/CD pipeline.

Checking for vulnerabilities

SBOMs provide a detailed breakdown of each and every ingredient of your software. For software supply chain security, that’s a great start, but you need to do something with that information. Before you deploy the final artifacts and make them available to your users, you need to make sure no components in your software are compromised or contain vulnerabilities. This is where a tool like Trivy comes into play.

Trivy is a best-in-class, open-source security scanner. In your CI/CD pipeline, you set up Trivy to consume the generated SBOMs of your software components. As Trivy analyzes your SBOMs, it matches each component against its vulnerability database, providing a comprehensive assessment of the security posture of the software.

This tight integration allows Trivy to provide accurate and actionable vulnerability reports, helping organizations identify and address potential security risks in their software supply chain.

License compliance checks

SBOMs are also useful for license compliance checks. Part of the metadata associated with a software component includes its license. An automated process can analyze the license information for all of the components referenced in your SBOM, checking them against a list of approved licenses for your organization. When a non-compliant license is detected, the build process fails, and you receive an alert.

Just like vulnerability scanning, license compliance checks can be integrated as another step in your CI/CD pipeline. Trivy can detect non-compliant licenses, as can OpenChain, which is a project dedicated to consistent and trusted license compliance information.

On-the-fly scanning and integration with incident response

So far, we’ve discussed SBOM generation and security checks before deploying the software to production. However, that leaves us with a gap, in the case of software that is deployed to production by means other than the CI/CD process. One common scenario is a deployed software component that dynamically deploys additional software components. Another common scenario is high-permissioned users who manually deploy software.

In these cases, the CI/CD toolchain is out of the loop. Fortunately, this problem can be mitigated by establishing runtime checks. These checks watch for dynamically introduced components, subsequently verifying their security and compliance.

Let’s consider the case when a compromised component makes its way into the production system, and an incident occurs. Your incident response tools will identify the incident, alert the security team, and assess the potential impact. At this point, SBOMs and OmniBOR Git object IDs (gitoids) can help to assess the overall vulnerabilities and potential damage. This in turn will inform any follow-up action and investigation.

Retaining SBOMs is very important for the following reasons:

By sharing SBOMs with stakeholders (internal or external), you promote trust and transparency.
For compliance and audit purposes, it is very useful to have the historical SBOMs of any version of the system.
When performing root cause analyses of security incidents, you can use a SBOM to identify when a particular component or issue was introduced to the system.

Challenges and solutions

While the benefits of SBOMs are clear, and how SBOMs might integrate into your DevOps flow seem straightforward, integrating SBOMs into existing DevOps practices can pose the following challenges:

Adjusting existing processes and tooling: Incorporating SBOM generation, tracking, and analysis into your existing tooling takes effort. This will likely require changes to build pipelines, CI/CD workflows, and deployment processes.
Ensuring accuracy and completeness: In dynamic and complex software environments, your software components are always changing. The task of keeping your SBOMs up-to-date, accurate, and complete is not trivial.
Resistance to adoption: Organizations may also face resistance from developers or teams accustomed to working without explicit SBOM requirements.

Overcoming these challenges requires careful planning, collaboration, and education. However, once you’ve achieved the successful integration of SBOMs into your DevOps practices, your organization will be more confident that your software—and everything that goes into it—is secure.

SBOMs are essential for secure software development

Modern software applications are built on top of a complex web of dependency components. A SBOM helps to bring clarity to that web, comprehensively and in a standardized format. This makes SBOMs absolutely essential for vulnerability management and ensuring license compliance.

Therefore, integrating SBOMs into DevOps practices is crucial for secure software development. At the CI/CD pipeline level, organizations can leverage automation for SBOM generation and maintenance with tools such as in-toto or OmniBOR. Then, they can use tools like Trivy to analyze SBOMs in order to perform vulnerability scanning or compliance checks.

Although process change aversion and developer resistance may bring challenges to the integration of SBOMs, proper planning and education can lead to a smoother migration and team buy-in. In the end, organizations that integrate SBOMs into their DevOps practices make tremendous strides in ensuring software supply chain security.

Cisco is a reliable and trusted industry leader in the area of software supply chain security, supporting developing, and promoting open standards and tools such as OmniBOR, OpenClarity, and Panoptica. Cisco also offers comprehensive managed solutions with professional support.

Resources

Blog: Container Vulnerability Scanners

Learning Lab: KubeClarity

Site: Cisco Developer FSO Hub

Site: Cisco Full-Stack Observability Solutions