Software Bill of Materials (SBOMs) are becoming more and more important. . .

We are all very familiar with one aspect of the software supply chain – updates.  New features, bug fixes, and performance upgrades are a regular occurrence to any device’s lifecycle, however what if these kinds of updates also include deliberately malicious code? There are plenty of examples of this in the past few years, one being the infamous Solarwinds Attack where a Russian APT compromised the popular IT-management tool SolarWinds Orion which affected 18,000 customers.  ENISA suggested supply chain attacks would multiply four-fold in 2021.

The U.S. government recognizes the need for improved supply chain security, of which include the use of Software Bill Of Materials (SBOMs) in “monitoring operations and alerts and responding to attempted and actual cyber incidents”. See last year’s Sec. 4 of Executive Order 14028 ‘Improving the Nation’s Cybersecurity‘ :

“Software Bill of Materials” or “SBOM” means a formal record containing the details and supply chain relationships of various components used in building software.  Software developers and vendors often create products by assembling existing open source and commercial software components.  The SBOM enumerates these components in a product.  It is analogous to a list of ingredients on food packaging.  An SBOM is useful to those who develop or manufacture software, those who select or purchase software, and those who operate software.”

A Software Bill of Materials (SBOM) is an inventory of all software components used to build software applications. A useful addition to your IT asset inventory strategy, the review of SBOMs can quickly identify vulnerable software affected by a supply chain attack.

While not considered a supply chain attack, Log4j provides a good use case for identifying vulnerable software using SBOM; while it was easier pinpointing which applications were running certain versions of Java, it was much more difficult identifying which applications included vulnerable Log4j libraries. A quick SBOM inventory of all Java applications would remedy this, allowing fast identification of vulnerable Log4j libraries throughout your organization. In a complete and updated SBOM database, these libraries could be identified with a query for Component Name ‘Log4j’ and Version String ‘2.17.1’ for all applications running Java 8. Our example query below follows the syntax of a SBOM standard being used.

The future of supply chain risk management involves SBOM ingestion. Most zero-day disclosures identify software versions affected by a vulnerability. Having a collection of SBOMs to rapidly identify vulnerable software will become the new standard, bringing clarity to your supply chain risk assessment, and improving the speed of your incident response.

Original article by Steven Jakubin. Data Security Analyst, infotex