In recent years, the software supply chains at SolarWinds and Kaseya, among others, have been targeted, along with identified vulnerabilities in widely used open source libraries, including Heartbleed in 2014, a vulnerability in OpenSSL, and Log4j in 2021. In both cases, innumerable systems were affected.

Back in May 2021, the United States introduced an obligation to provide a software bill of materials (SBOM) in a Presidential Executive Order on Improving the Nation's Cybersecurity [1]. The European Parliament recently adopted (March 2024) the Cyber Resilience Act (CRA), which also calls for an SBOM [2].

The need for action by all companies that produce and distribute software as a standalone product or as part of products such as electrical appliances or machines is real. At the same time, the SBOM offers every company the opportunity to better understand and manage the attack surface and respond more quickly to threats.

Software Bill of Materials

The vast majority of modern software is no longer coded from scratch and then compiled; rather, it makes extensive use of standard libraries such as those already mentioned or frameworks such as OpenSSL or Log4j, which provide functions such as SSL/TLS encryption or logging. A very large proportion of these libraries are open source and freely available. In addition to the basic libraries, other services are also used in software, whether in technical goods, as standalone applications, or in the form of cloud services. For cloud applications in particular, these are typically platforms as a service (PaaS), from databases to artificial intelligence (AI).

Today's reality is characterized by complex, multilayered software from a variety of sources, which creates the challenge, thus far difficult to understand, as to what exactly a piece of software contains and whether your company is affected by a new vulnerability. In the production of physical goods, the bill of materials (BOM) lists the products used to create a product. In the event of faults in a specific component of a product, a BOM makes it is easier to find the parts it contains and rectify the faults.

An SBOM aims to do the same thing for software by providing well-defined and complete information about the "software in the software," enabling companies quickly to identify software and services in use that are potentially affected by a vulnerability (e.g., in an open source library). In turn, targeted countermeasures can be introduced far more quickly.

Supply Chain Attack Scenarios

The various threats that have affected many companies by way of software supply chains in recent years can be broken down into four groups (with the fourth only being included here in a broad sense):

• Vulnerabilities in standard libraries
• Vulnerabilities in third-party software components
• Infection of commercial off-the-shelf software (COTS) to attack its users
• Attacks on cloud services and their tenants

The vulnerabilities in OpenSSL and Log4j are examples of the first group. When vulnerabilities arise in standard libraries and frameworks, a large number of software products and their users are typically affected – possibly millions of affected systems. One major difference is that patches from commercial providers such as Microsoft are automatically provided to the affected systems, which allows for automated installation. This process sometimes takes place later than desired by the IT manager, and not everyone uses the automatic installation process. However, two important aspects are (1) that it is known which systems are affected and (2) that automatic patch deployment and installation is possible.

Of course, patches are also developed and made available for open source components as soon as vulnerabilities are identified. The challenge, however, is that IT managers do not have the described automations for the affected systems and often do not know which components are being used.

A second factor is that the vast majority of today's commercial software products and cloud services contain third-party software components in addition to open source components. This fact also applies to Microsoft, for example, which uses free software in many areas of its products and cloud services. Dashboards are another example: Who knows on what technical basis they are based in a piece of software or cloud service? You can be fairly certain that the provider did not develop the functionality underlying a dashboard for displaying diagrams, but that a different solution was used that could in turn rely on other components, including open source libraries and frameworks. Vulnerabilities in third-party software components and services also represent a software supply chain risk. The SBOM is again intended to provide insights here.

The third case (e.g., scenarios such as the aforementioned incidents at SolarWinds and Kaseya) is a little different. The SolarWinds and Kaseya attackers used widespread software to open a door to the developers' customers. The main difference is that an attack was initiated by provisioning the software (i.e., along the software supply chain); however, in this case the infected software was no longer part of other applications, but the end product on the customer side. Of course, attacks by deliberately implemented vulnerabilities in standard libraries and frameworks cannot be ruled out.

Compared with vulnerabilities in software libraries and third-party products, the advantage in this scenario is that a company is usually aware it is using the software. On the other hand, and especially if the attack is carried out by management software for IT infrastructures, the damage may already have been done, and the bad guy might already have access to other systems before such a vulnerability is discovered and the patches are distributed.

The fourth case (e.g., the Microsoft Exchange Server Data Breach in 2021) is about attackers successfully attacking a cloud service or other critical systems and gaining the opportunity to attack the clients or customers of such services. Even if the problem is similar, it is not a software supply chain attack in the narrower sense, because the attack does not target the supply chain of basic components through PaaS services, for example, to the finished cloud service but targets the supplied cloud application and its users.

A Path to Cyber Resilience

All scenarios clearly show the complex challenge posed by today's software production methods. Just as cars are created by assembling in-house parts and components such as brakes from suppliers that are often of critical importance, software, whether in its traditional form or as a cloud service, is now typically a combination of in-house code and components from the open source sector and third-party providers.

Whereas some parts of a car, at most, cause functional errors, every single component of software is critical because it not only provides functionality, but can also be targeted. Some components (e.g., OpenSSL and secure communication) are more sensitive than others, but ultimately each poses a risk.