As with many zero-day vulnerabilities, organizations are striving to identify and address the impact of the Log4Shell vulnerability in Log4j. This particular vulnerability is very dangerous because it is found in a widespread library and is easy to exploit. One crucial element here is that it was already actively tapped before the details were announced, making time of the essence.
Once security and application teams catch their collective breath after around-the-clock repair efforts, they will conduct rollbacks and reviews to determine ways to better prepare for the next zero-day vulnerability, because there are will Be next. In this new environment, the Software Bill of Materials (SBOM) has become a vital security necessity that allows visibility as software moves through the supply chain. Organizations must now act to create an important new capacity: SBOM . management.
Create a comprehensive SBOM
Currently, the best practice adopted by industry leaders is to create a list of software materials for each version delivered or published of an application. In fact, the latest US executive order on the nation’s cybersecurity will require software suppliers to provide federal agencies with an SBOM for the software they sell or provide.
If we take a broad look here, creating an SBOM is only the first step. As shown by Log4Shell, we need the ability to easily take advantage of and search SBOMs when a new zero-day occurs. Creating an SBOM is easy, but managing and tracking hundreds or thousands of SBOMs is challenging, but also a challenging requirement to address the changing threat landscape.
While it is common today to search for vulnerabilities before an app is delivered, this is simply not enough. Scanning applications to identify relevant components and vulnerabilities should be an ongoing process that doesn’t just run once, but runs regularly. Each time the application is scanned, the results must be recorded and analyzed. In order to move from an ad hoc system to a continuous one, tools and automation are important.
Applications developed by your organization typically include a large amount of open source code along with internally developed code and third-party commercial libraries. SBOM builders can scan the code you write as well as open source code, but scanning commercial libraries may not be possible depending on the packaging. In this case, you should order SBOM from commercial suppliers. Once you have the SBOMs for all of your components, you will need to combine them and produce a bundled SBOM that covers the entire application.
Critical capabilities needed to manage SBOM
Using SBOMs as a basis for securing your software supply chain will create an extension of SBOM over time as more and more SBOMs are created and ingested. Tools and automation will be needed to solve a problem SBOM . management. Search capabilities include:
- Central repository for SBOM storage across product and application teams.
- Search capabilities to quickly find applications with problematic components.
- Ability to create SBOMs or import SBOMs provided by software vendors and open source projects.
- Compile SBOMs at the component level to create a comprehensive SBOM for an entire application.
- Support for rich SBOM formats as well as lightweight SBOM standards such as SPDX.
- The ability to store multiple SBOMs for multiple versions of an application, multiple versions, or different stages in the development process.
- Comparisons of SBOMs to detect drift and policies to alert potential tampering.
SBOMs speed response
Once you have a specific and accurate set of SBOMs for an application release, you need to store these SBOMs in a central repository to allow the contents of the SBOM to be quickly scanned and searched. The centralized approach means that security teams do not have to waste time trying to determine which components are deployed in their applications. When the next major vulnerability appears, the SBOM management tool should return results immediately. The Policy Engine and Policy Rules application will allow notifications and alerts to be generated for all affected application teams. Knowing what is affected and how to treat it should be measured in minutes, not weeks.
The new facts of SBOM
When you hit the air after Log4Shell’s short-term remediation efforts, it’s critical to prepare for the new realities of supply chain vulnerabilities and attacks. If your organization is not already Generate SBOMsIt’s time to start. But creating an SBOM is only the first step. You should also put in place processes to store and manage SBOMs. Then create workflows that enable you to quickly access and search that data when the next zero-day vulnerability appears.
Log4j was a very costly lesson to remind us why we not only need SBOMs, but also the ability to manage them as part of a complete software supply chain management strategy. Now is the time to be proactive about the security of your software supply chain. Implementation of SBOM management is a crucial requirement that will pay dividends when the next zero day comes.
Josh Pressers is the Vice President of Security at anchor.
The New Technology Forum provides a place to explore and discuss emerging enterprise technology with unprecedented depth and breadth. The choice is personal, based on our choice of technologies that we believe are important and of great interest to InfoWorld readers. InfoWorld does not accept marketing guarantees for publication and reserves the right to edit all Contributed Content. Send all inquiries to firstname.lastname@example.org.