Cybersecurity teams need to enforce SBOM mandates

Cybersecurity managers would be well-advised to demand starting now that every application being deployed comes with a software bill of materials (SBOM).

One of the things that have become apparent in the wake of the Log4j cybersecurity crisis that arose following the disclosure of a series of zero-day vulnerabilities affecting Java applications is that many organizations were not entirely sure just how many instances of the code in question are being employed. The open source Log4J tool for managing logs has been copied and pasted into thousands of Java applications. Many IT organizations have spent weeks looking for code that might only take them a few minutes to remediate with a patch update. It would be a lot simpler if IT teams had access to SBOMs that reliably told them what components are included in any given application.

There are, of course, tools that IT teams can employ to analyze binaries to automatically create an SBOM. However, an SBOM created as the application is deployed provides a simpler mechanism for tracking down components when time is of the essence. Cybercriminals have become much more adept at exploiting vulnerabilities within hours of disclosure. That’s why the executive order issued by the Biden administration includes a provision requiring any application used by a federal agency to have an SBOM. Most enterprise IT organizations are likely to follow suit. IT teams should also expect that every cybersecurity insurance policy is likely to have a similar requirement as part of an effort to limit liabilities by reducing the time required to patch an application.

The Linux Foundation, Joint Development Foundation, and the open-source SPDX community are behind a Software Package Data Exchange (SPDX) specification for creating software bill of materials (SBOMs) is now recognized as the ISO/IEC 5962:2021 international standard. There is also CycloneDX, a lightweight SBOM standard based on an open source project that originated via the Open Web Application Security Project (OWASP) community, and a Software Identification (SWID) standard for tags that some organizations employ to create SBOMs.

A Manifest for Modern Cybersecurity posits that organizations should track everything since you cannot protect what you can’t see. SBOMs are the first critical step toward securing any application environment. The challenge now is explaining to developers that just want to write code why they need to create an accurate SBOM for their application. Of course, the simplest thing to do is to tell developers their applications won’t be allowed to run in a production environment without an SBOM. Cybersecurity teams will be amazed how quickly the process of creating an SBOM will subsequently become automated within the context of a DevOps workflow.

The best cybersecurity incident, naturally, is the one that never occurred. A simple SBOM will prevent a lot of software components with known vulnerabilities from ever being deployed in the first place. Inevitably, there will be zero-day vulnerabilities that are discovered after an application is deployed in a production environment. An SBOM, however, will make all the difference between those vulnerabilities being the latest in a series of ongoing annoying events versus what is now often a flat-out IT operations catastrophe.