SBOM and its role in cybersecurity

A recent survey revealed how organizations plan to increase software supply chain security in 2022 to protect against attacks that exploit vulnerabilities.

Conducted in December 2021 with 428 leaders and executives in IT, security, and development roles, the study coincided with a period close to the disclosure of the Log4j vulnerability, an open-source Java library developed by the Apache Foundation and widely used by application and service developers on the Internet. The impacts observed by respondents immediately after the incident were reported as significant or moderate to software supply chain cybersecurity.

Software supply chain security will be an important, if not the main, center of attraction in 2022 for 54% of respondents. Already, 76% of large organizations will increase their use of the so-called Software Bill of Materials (SBOM), evidence that SBOM practices are expected to gain traction with the goal of improving software supply chain security. However, only 18% of respondents have complete SBOMs for all applications, and less than a third follow best practices on how to maintain an SBOM repository and request SBOMs from vendors.

“The most important action now is to generate and store SBOMs for the applications that organizations develop and use. This fundamental foundation ensures visibility into the software components they depend on and must monitor for application security post-deployment. With SBOMs, organizations will be ready to respond quickly to the next zero-day vulnerability,” said Josh Bressers, vice president of security at Anchore, the company that conducted the research.

SBOM – importance and challenges

SBOM can be considered the set of components and libraries and their respective licenses and dependencies that make up a software application. They are documents that can be interpreted by machines and are considered a natural by-product of the most modern development process. The SBOM concept has been circulating around the IT world for a decade now, but has received more attention as more resources are sought to ensure the security of the software supply chain.

“For years, we’ve been debating the idea that software and cloud services should have reliable SBOMs that make it easy to find out which bugs might be considered critical to the product we use,” commented Paul Ducklin, principal security researcher at Sophos.

Even the US government seems to be paying attention to the SBOM issue lately. Among other requests, an executive order from President Biden related to cybersecurity calls for the development of guidelines on what SBOMs should include.

“A widely used, the machine-readable SBOM format ensures more benefits through automation and integration via tools. SBOMs gain more value when stored collectively in a repository that can be easily referenced by other applications and systems. Understanding the software supply chain, developing SBOMs and using them to analyze vulnerabilities is critical for risk management,” highlights the executive order.

Government initiatives around the SBOM theme are being led by Allan Friedman, senior consultant and strategist at CISA (Cybersecurity and Infrastructure Security Agency) and include four workstreams: cloud and online applications, tools and implementation, sharing and exchange of SBOMs, access and adoption.

But why is it that SBOM-associated measures have yet to take off? For Eric Byres, chief technology officer at aDolus, it is simple to generate SBOMs at the point of development, but what about the applications (in binary code only) that are already installed and in use around the world? That category represents about 95 per cent of the software used in critical systems today, he says. Furthermore, today’s SBOMs are static documents, which are not able to automatically incorporate updates.

Converting a huge volume of SBOM data into intelligence is also a big challenge, in Byres’ view. You have to do what the executive calls SBOM enrichment: use the lists of raw software components, determine the risk factors for each one, and stipulate priorities.

To help with the new task of managing SBOMs, approaches to creating, managing, and using them are already being released, covering the key stages of the software life cycle:

1. Store and manage SBOMs in a central repository;

2. Adopt SBOM standards. Software Packet Data Exchange (SPDX), used for over a decade to document software components, is now an internationally recognized SBOM standard;

3. Require SBOMs for all software integrated into the organization;

4. Generate SBOMs at each step of the development process and for each build;

5. Create comprehensive SBOMs for each version of software deployed or provided;

6. Use automation tools for policy enforcement and alerts.