Since the federal government mandate calling for the creation of a software bill of materials (SBOM) to avoid the next SolarWinds or Log4j exposures, software providers have been scrambling to figure out how to create SBOMs that are both effective and dynamic, given that software changes over time.
Bills of material have long been standard requirements in other industries for decades. Some cybersecurity experts say SBOMs will foster transparency, which will lead to increased security and trust.
The challenges of creating and using an SBOM
While more organizations recognize now that they need an SBOM, that doesn’t mean the process of creating and maintaining one is easy.
Currently, static SBOM tools fail to meet today’s security needs and create too much work. They require manual, single point-in-time scanning to understand changes in the environment. Static SBOMs yield noisy and complex outputs that make focusing difficult.
Static SBOMs are also limited in scope of what they can see and are often only available in specific parts of the software stack. Within this context, delay and uncertainty result in risk.
For SBOMs to work, they need to have component identification and the ability to scale globally across diverse software ecosystems, sectors, and markets. Although component identification is a critical part of an SBOM, the group acknowledged it will be difficult to come up with a universal, global component identification system.
The minimum elements of an SBOM
The National Telecommunications and Information Administration (NTIA) and the U.S. Department of Commerce were recently tasked with publishing the minimum elements for an SBOM along with a description of use cases for greater transparency in the supply chain.
The departments determined that data fields, automation support, and practices and processes should be the foundation for developing software transparency. There should be data fields for supplier, component name and version, as well as dependency relationship, among other areas.
Automation support refers to automatic data generation and machine-readability to allow for scaling across the software ecosystem. Data formats used to generate and consume SBOMs include SPDX, CycloneDX, and SWID tags.
Practices and processes define the operation, generation, and use of SBOM requests including frequency, depth, distribution, and delivery and access control.
The departments acknowledged that an SBOM is a starting point, and that software is dynamic in nature and subject to change.
“The minimum elements that are deemed feasible in today’s environment do not capture the full range of metadata around software source, processing, and use that is likely to emerge from modern software prochanesses,’’ the Department of Commerce stated. “Some of this data will be incorporated into future extensions of SBOM data.”
Noting that SBOMs will not be the sole resource for supply chain security or software assurance, the department advised taking “a linkable, modular approach … to maximize the potential for flexibility and adoption.”
Two Steps for Creating & Implementing an SBOM
Here are two important steps for successfully creating and implementing an SBOM.
#1 Start small
Software composition analysis (SCA) tools and developer IDE plug-ins are being used to produce digestible reports of components for security use cases. Once an SBOM has been generated, the information must be distributed efficiently.
One approach is to forward the SBOMs to your organization’s data lake or knowledge management system. That way, users within the security organization or elsewhere in the organization can access the data from the central repository to ensure they have up-to-date and accurate information.
KPMG advises organizations to start small and deploy SBOMs to development and security teams first. By doing so, they can determine if any roadblocks exist, ensure that the knowledgebase is being utilized effectively, and then seek for areas of improvements.
Once those first steps are completed, the SBOM should then be distributed to the rest of the organization with help from security champions.
#2 Make sure your SBOM is dynamic and continually updated
An SBOM needs to be updated continuously. This is where a dynamic SBOM comes in. To keep data up-to-date, businesses must deploy software with the capability for a dynamic SBOM that will automatically incorporate updates whenever there are changes.
In addition, a dynamic SBOM provides context about how software components are dynamically used and executed (unlike static SBOMs that just inform on what’s there). This dynamic runtime context is critical in distinguishing latent components from active exploitable threats, understanding true risk factors, and focusing remediation efforts on the relevant parts of your SBOM.
Eventually, it will become a requirement to shift to dynamic SBOMs, especially in organizations that develop software on a regular basis. For organizations that have most recently felt the pain of the Log4j vulnerability, integrating SBOMs into the SDLC and making them dynamic is vital.
Leave a Reply