Organizations from startups to government agencies use opaque software code that could put them at risk of executing malicious programs. This code largely comes from open-source repositories without sufficient security processes.
A software bill of materials, or SBOM, plugs that gap by acting as an evolving list of ingredients for software, increasing transparency into the components at the beginning of a program’s lifecycle and serving as the basis for continued vulnerability monitoring. SBOMs can help governments and businesses manage risk, but only if they know how to use them.
There are four key steps that every organization must take to use this tool to improve security.
SBOM Development
The US government, industry, and academics have worked together over the past five years to develop guidance on how to generate and exchange SBOMs between vendors and their customers.
After the December 2020 revelations about a years-long Russian cyber espionage campaign that penetrated US government agencies by compromising software provider SolarWinds, the White House kicked this collaboration into high gear in May 2021.
This included tasking the National Telecommunications and Information Administration with developing a standard for the minimum elements SBOMs should include, and the National Institute of Standards and Technology with providing guidance on how to secure the software supply chain by using SBOMs.
After completing this task, NIST also published updated guidance on supply chain risk management, which noted that SBOMs can help manage organizational risk by improving the transparency of software assets.
These standards and guidelines have clarified what information SBOMs should provide to customers and how software companies can implement processes to ensure the security of their code during its development process.
Fallout From Log4j
In the meantime, however, researchers discovered what US cyber chief Jen Easterly called likely the “most serious” software vulnerability she had ever seen, embedded in hundreds of millions of devices around the world. The Log4j vulnerability underscored the urgency of SBOMs which would inform users if their products contained it, she explained.
And earlier this spring, private cybersecurity firms discovered yet another software supply chain compromise—this time by North Korea—likely affecting hundreds of thousands of multinational corporations.
While the public-private collaboration is popularizing the idea of SBOMs and answering important questions around standardizing their creation and distribution, the guidance fails to answer some of the most important questions around SBOM use:
- How should recipients of SBOMs consume and integrate them into their existing business processes?
- With a software ingredient list in hand, how can organizations effectively use SBOM to improve their security?
While the details of the process will vary by company, there are ultimately just four steps every recipient of an SBOM needs to do to make effective use of this tool.
Step One: Validate SBOM
After receiving an SBOM for a custom-made software, the first thing an organization should do is validate that the SBOM they received contains the information they asked for in the contract with the software supplier.
For example, a contract could specify that SBOMs must use a specific naming convention for identifying software components. The company receiving the SBOM must first confirm the vendor actually did as instructed.
Part of this first step should also be a confirmation of the SBOM’s integrity through a chain-of-custody-like process.
Organizations might also receive SBOMs when purchasing commercial, off-the-shelf software. In that case, the organization can’t make specific demands of the seller.
When purchasing a Sony television from Best Buy, the standard instruction manual is all the buyer gets. In those scenarios, step one may include adapting or modifying the SBOM so that it matches and can easily feed into the organization’s existing systems.
Step 2: Analyze Vulnerabilities Before Deployment
Next, organizations must review what the SBOM reveals about the software’s components. The SBOM will indicate the number of known vulnerabilities contained in the software, the percent that is open-source code, and the history of maintenance of the various components. The SBOM will also reveal whether there are any critical pieces that were developed by foreign entities.
There is no such thing as risk-free software. The question the organization will need to consider is whether—using pre-established criteria—the risks are acceptable. If yes, and only if yes, the company will add the software to its systems.
Step 3: Ongoing Risk Assessments
Cyber risks are not static. New vulnerabilities are discovered,…
Read More: Four Steps to Mix SBOMs—Softwares’ Recipe—Into Risk Management