Gayatri Prakash, the vice president and general manager for Compliance at CloudBees, explains how to make SBOMs more valuable through better data collection.
There is a world of difference between believing something to be true and knowing beyond a shadow of a doubt. When it comes to software bills of materials (SBOMs), most organizations are presented with a list of software components that, given the highly dynamic nature of software development, may vary considerably from what’s actually being used in an application. Developers continuously update components, so the only real single source of truth is the underlying continuous integration/continuous delivery (CI/CD) platform used to create and deploy apps.
In the wake of the discovery of the now-infamous zero-day Log4j vulnerability, many organizations found themselves struggling to find where every instance of the open source Java log management tool was running. Even today, years after the initial discovery, IT teams are still finding vulnerable instances of Log4j —simply because a developer inadvertently downloaded an older version of the tool from a public repository.
To facilitate remediation of vulnerabilities, organizations of all sizes are now requiring software providers to provide an SBOM to simplify identification of which software components exist in their applications and where they are running. In fact, guidance by the Cybersecurity and Infrastructure Security Agency and the National Security Agency issued in 2023 included Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption, which “provides software developers and suppliers with industry best practices and principles, including managing open source software and software bills of materials, to maintain and provide awareness about the security of software.” Most assuredly, extensions to existing mandates will also require that SBOMs be made available.
There are, of course, myriad tools for creating SBOMs, but most SBOMs are a best guess. The only way to ensure 100% accuracy is to rely on metadata continuously tracked by a modern CI/CD platform and update SBOMs in real-time as any change to an application is made. IT leaders need to not only require SBOMs but also truly understand how the provenance of an application’s “list of ingredients” has been established.
The two most widely used SBOM formats are software package data exchange (SPDX), overseen by the Linux Foundation, and CycloneDX, created by the Open Web Application Security Project (OWASP). SPDX was originally built to address software licensing issues, while CycloneDX is a lighter-weight alternative designed specifically for creating SBOMs.
Many organizations have already embraced SPDX to manage licensing, so a single format to address both licensing terms and software components has its appeal — but in the age of cloud native applications, others prefer a lighter-weight approach to tracking increasingly frequent updates to components.
Regardless of which format is employed to identify components and their associated dependencies, organizations around the world are following a Biden administration executive order that requires providers to include SBOMs. The goal of the legislation is to make it easier to discover where every instance of a software component might be running.
Making the DevOps journey
No organization can ever accurately determine in real-time the level of risk they face without knowing what version of any given software component is running in a production environment.
Historically, many organizations allowed developers to aggregate software components without always checking to see if they were compromised. Cybercriminals, unfortunately, have become more adept at injecting malware into software components in the hope that they will be able to compromise any number of downstream applications that depend on the compromised component.
In the absence of an SBOM, it could be months before all the instances of a malware-infected software component are discovered and remediated. The only way to mitigate that issue is to make sure SBOMs are automatically generated each time any application component is updated — and ensure that the process can be validated during a software compliance audit.
An SBOM, however, is only as useful as the data it provides. And a static snapshot of source code is insufficient. SBOMs require continuous analysis of the source code, binaries and runtime environment. A modern DevSecOps platform can provide the single source of truth needed to generate SBOMs and, beyond that, enable IT teams to address cybersecurity issues as they arise. Just as importantly, SBOMs can enable IT teams to address compliance mandates in ways that don’t result in fines being levied. In effect, the only way to ensure peace of mind is to generate an SBOM based on data that is only available in the CI/CD platform.
It’s clear that more rigorous best practices need to be applied to the way software is built and deployed. The days when developers were free to aggregate software components as they saw fit by, for example, relying on unvetted open source software downloaded from a repository are now at an end. The expectation is that organizations will be held accountable for the integrity of all components used within an application, regardless of who originally wrote the code.
Each organization will naturally need to decide for itself whether it makes sense to retrofit their existing DevOps workflows to address modern application security requirements. However, as the number of applications built and deployed continues to accelerate, the need for DevSecOps platforms that address cybersecurity issues before applications are deployed is becoming ever more apparent.
As part of that effort, SBOMs must become an extension of a DevSecOps workflow that enables the SBOM to be regenerated as software components change. This enables organizations to better prioritize remediation efforts—both before and after an application is deployed.
Gayatri Prakash, the vice president and general manager for compliance at CloudBees, is a serial technology entrepreneur, with a deep understanding of software design and engineering. She is an expert in all things related to cybersecurity and compliance.
Modern CI/CD platforms provide SBOM peace of mind
Gayatri Prakash, the vice president and general manager for Compliance at CloudBees, explains how to make SBOMs more valuable through better data collection.
There is a world of difference between believing something to be true and knowing beyond a shadow of a doubt. When it comes to software bills of materials (SBOMs), most organizations are presented with a list of software components that, given the highly dynamic nature of software development, may vary considerably from what’s actually being used in an application. Developers continuously update components, so the only real single source of truth is the underlying continuous integration/continuous delivery (CI/CD) platform used to create and deploy apps.
In the wake of the discovery of the now-infamous zero-day Log4j vulnerability, many organizations found themselves struggling to find where every instance of the open source Java log management tool was running. Even today, years after the initial discovery, IT teams are still finding vulnerable instances of Log4j —simply because a developer inadvertently downloaded an older version of the tool from a public repository.
To facilitate remediation of vulnerabilities, organizations of all sizes are now requiring software providers to provide an SBOM to simplify identification of which software components exist in their applications and where they are running. In fact, guidance by the Cybersecurity and Infrastructure Security Agency and the National Security Agency issued in 2023 included Securing the Software Supply Chain: Recommended Practices for Software Bill of Materials Consumption, which “provides software developers and suppliers with industry best practices and principles, including managing open source software and software bills of materials, to maintain and provide awareness about the security of software.” Most assuredly, extensions to existing mandates will also require that SBOMs be made available.
There are, of course, myriad tools for creating SBOMs, but most SBOMs are a best guess. The only way to ensure 100% accuracy is to rely on metadata continuously tracked by a modern CI/CD platform and update SBOMs in real-time as any change to an application is made. IT leaders need to not only require SBOMs but also truly understand how the provenance of an application’s “list of ingredients” has been established.
Need help on your SCRM journey? We’ve gathered advice from federal and industry experts in our new ebook, sponsored by Carahsoft. Download today!
SBOMs: A brief history
The two most widely used SBOM formats are software package data exchange (SPDX), overseen by the Linux Foundation, and CycloneDX, created by the Open Web Application Security Project (OWASP). SPDX was originally built to address software licensing issues, while CycloneDX is a lighter-weight alternative designed specifically for creating SBOMs.
Many organizations have already embraced SPDX to manage licensing, so a single format to address both licensing terms and software components has its appeal — but in the age of cloud native applications, others prefer a lighter-weight approach to tracking increasingly frequent updates to components.
Regardless of which format is employed to identify components and their associated dependencies, organizations around the world are following a Biden administration executive order that requires providers to include SBOMs. The goal of the legislation is to make it easier to discover where every instance of a software component might be running.
Making the DevOps journey
No organization can ever accurately determine in real-time the level of risk they face without knowing what version of any given software component is running in a production environment.
Historically, many organizations allowed developers to aggregate software components without always checking to see if they were compromised. Cybercriminals, unfortunately, have become more adept at injecting malware into software components in the hope that they will be able to compromise any number of downstream applications that depend on the compromised component.
In the absence of an SBOM, it could be months before all the instances of a malware-infected software component are discovered and remediated. The only way to mitigate that issue is to make sure SBOMs are automatically generated each time any application component is updated — and ensure that the process can be validated during a software compliance audit.
An SBOM, however, is only as useful as the data it provides. And a static snapshot of source code is insufficient. SBOMs require continuous analysis of the source code, binaries and runtime environment. A modern DevSecOps platform can provide the single source of truth needed to generate SBOMs and, beyond that, enable IT teams to address cybersecurity issues as they arise. Just as importantly, SBOMs can enable IT teams to address compliance mandates in ways that don’t result in fines being levied. In effect, the only way to ensure peace of mind is to generate an SBOM based on data that is only available in the CI/CD platform.
It’s clear that more rigorous best practices need to be applied to the way software is built and deployed. The days when developers were free to aggregate software components as they saw fit by, for example, relying on unvetted open source software downloaded from a repository are now at an end. The expectation is that organizations will be held accountable for the integrity of all components used within an application, regardless of who originally wrote the code.
Read more: Commentary
Each organization will naturally need to decide for itself whether it makes sense to retrofit their existing DevOps workflows to address modern application security requirements. However, as the number of applications built and deployed continues to accelerate, the need for DevSecOps platforms that address cybersecurity issues before applications are deployed is becoming ever more apparent.
As part of that effort, SBOMs must become an extension of a DevSecOps workflow that enables the SBOM to be regenerated as software components change. This enables organizations to better prioritize remediation efforts—both before and after an application is deployed.
Gayatri Prakash, the vice president and general manager for compliance at CloudBees, is a serial technology entrepreneur, with a deep understanding of software design and engineering. She is an expert in all things related to cybersecurity and compliance.
Copyright © 2024 Federal News Network. All rights reserved. This website is not intended for users located within the European Economic Area.
Related Stories
DHS units partner to improve SBOM transparency
SBOMs are just the start, not the end, of the software supply chain conversation
Why the SBOM is just the beginning of software supply chain cybersecurity