Improve your cybersecurity with a Software Bill of Materials

The 2021 Log4j vulnerabilities fueled a storm of malicious activity across the internet. Within a week of the disclosure, security researchers were tracking over 100 Log4j attacks each minute. IT teams rushed to deploy patches and other mitigation efforts, but three months later nearly 40% of deployments were still vulnerable to attack. The 2023 Verizon Data Breach Investigation Report (DBIR) shows that 8% of the companies studied still have one or more vulnerable Log4j installations.

It’s not uncommon to have old vulnerabilities go unpatched, especially when the vulnerabilities are embedded in the infrastructure. Log4j is an open-source logging code that developers use in their applications. Patches to application components like this often require an entire application update, which means that IT teams must wait for developers to deliver the security solutions. There are other challenges too, like legacy software that cannot be updated, or application vulnerabilities unknown to the system administrator. The DBIR referenced above reports that the median time to patch critical vulnerabilities is 49 days, and that number hasn’t changed much over the last few years. Attackers only need a few hours after discovery to begin an attack. In some cases, attacks are already underway before the vulnerability is disclosed.

Consultants and IT staffers often think in terms of applications and platforms. Some CVEs will get their attention right away, others might not. Tech teams that are understaffed and/or lack the tools to support the security strategy will struggle more than others.  

The Software Bill of Materials (SBOM)

A Software Bill of Materials (SBOM) gives tech teams a quick way to identify vulnerabilities that exist within their platforms and infrastructures. The SBOM enumerates the existing open-source and commercial software components that are included in an application. This document aids in risk evaluation and risk management throughout the software supply chain. If you’re not familiar with it, here’s an example:

Image taken from The Software BOM Squad, DevOps.com

Software Security in Supply Chains (NIST) has more information, examples, and minimum standards for SBOMs in federal agencies. This document is a good framework for companies to use in their own operations.

Who makes the SBOM?

President Biden’s Executive Order 14028 requires software vendors to provide an SBOM directly to the buyer or publish the SBOM on a website where it can be accessed at any time. This executive order only applies to the U.S. federal government and its vendors. Creating an SBOM is a good practice, even when not required. Developers can integrate SBOMs into their software development lifecycle alongside other security initiatives practiced by DevSecOps teams.

There are also tools like Syft that can create SBOMs of applications that are already running in the environment. These tools create an inventory of software components, libraries, and dependencies in the application even when it is in production and beyond the development cycle. Keep in mind that the resulting SBOM might not be as comprehensive as one generated during the development or build process.

Gartner predicts the number of companies requiring SBOMs will increase from less than 20% in 2022 to 60% in 2025.

If you’d like a better understanding of SBOMs and how to use them, these resources can help:

• Software Security in Supply Chains: Software Bill of Materials (SBOM)
  
• Cybersecurity teams need to enforce SBOM mandates
• National Telecommunications and Information Administration (NTIA), U.S. Department of Commerce
• NTIA - Software Identification Challenges and Guidance
• What are the Best Tools for Generating SBOM (Software Bill Of Materials)? (Mergebase)