By Dr. LaTrea Shine, Director of Supply Chain Security, Lenovo
Conversations around software supply chain security are today dominated by calls for generating Software Bills of Materials (SBOM) which, while well-intentioned, can be counterproductive. The list of ingredients reflected in an SBOM – the components, dependencies, and metadata in software – when integrated with a vulnerability management tool, can provide an “X-ray” of applications to identify software which may present a risk to users across a wide array of sectors, including critical infrastructure. While only representing a small subset of software security measures, vendors are nevertheless hyper-focused at the moment on fulfilling the SBOM aspects of recent regulatory efforts, including the US Executive Order 14028[1] and the EU’s (pending) Cyber Resilience Act (CRA)[2].
Indeed, SBOMs are vital in an evolving software ecosystem. If developed properly, they can allow consumers to quickly identify vulnerable software within their environment. However, the increasing pressure and rush to meet government deadlines unfortunately drives immature SBOM production and consumption, without a leading industry standard. Absent such a standard, the impact an SBOM will have on software transparency, and on identifying the source of open-source software (OSS) throughout the supply chain, will remain low. Preoccupations with meeting minimum government requirements, together with unresolved challenges around effective SBOM generation, production, and distribution, means they will remain ill-equipped to remediate software provenance concerns in the near term.
Why SBOM?
The criticality of software transparency[3] has consumed supply chain stakeholders ever since the infamous 2021 Apache Log4j vulnerability, “Log4shell”, was unleashed. Attackers exploited an unsecure java lookup feature (JNDI) to send malicious requests to targeted servers and perform remote code execution instructions under the guise of trusted LDAP and RMI command strings[4]. Log4shell’s popularity among many applications, operating systems, and tools meant that developers had to validate every software build and application to ensure it was free from the affected versions.
Prior to the development of SBOM, it took organizations significant time to discover which versions of OSS were being used within their environments. The Log4shell exploit highlighted the danger that organizations were in when using embedded OSS within their final product releases without completely understanding what the transient software contained. Many software development teams have historically treated OSS as trusted components in the software development lifecycle, but they contained a high risk of sabotage. SBOMs are intended to allow security teams to assess whether software is vulnerable to a known exploit and to rapidly locate the specific source[5]. However, issues with fulfilling SBOM requirements can lessen their reliability as a defensive mechanism for the software supply chain in the short-term.
Are minimum requirements enough?
In 2021, the US federal government mandated that all federal contractors provide an SBOM for any software product used as a part of, or in support to, critical infrastructure[6]. In addition to these requirements, the European Union (EU) demands this requirement of all vendors selling products on the European market. While there are a multitude of fields that can be included within an SBOM between the three primary formats (SPDX, SWID, and CycloneDX), governments only mandate that a small subset be integrated. In concept, these fields should be easily gleaned from the software metadata. However, in practice this relies on development teams consistently populating them as a matter of good software development, which has proved challenging. In fact, some generation tools frequently set unknown or unparsed field values to “NO ASSERTION” due to missing metadata, resulting in an incomplete and unreliable SBOM. While this may facilitate meeting minimum government requirements as-is, this is essentially as good as having no data, defeating the purpose of having an SBOM to begin with. If SBOM producers want meaningful data for SBOM consumers, additional and manual coding is required. This unfortunately means more time and resources, as well as limited automation, forcing these producers to lean on generic SBOMs as the minimally acceptable alternative – which equates to low provenance.
Further, the government specification broadly describes minimum SBOM components for compliance that potentially leaves out other meaningful data. Simply providing the supplier’s name, component name, version and hash is insufficient for properly identifying the source for all affected software. A supplier’s name is typically listed as the higher-level organization or department and does not spell out exactly where the software component came from—especially important for OSS. Including additional data fields, such as the download location and the original package creator, provides more accurate provenance details. A URL, for example, represents indisputable metadata that customers could use to locate the software origin more quickly, but again additional coding is required to provide this data consistently for all software packages. While some SBOM specifications include the download location as a mandatory requirement, it is not in direct alignment with the government standard. It is leading to inconsistencies in SBOM implementation and in the final data components included, as SBOM producers select what is easiest to produce amid minimal development resources.
Current SBOM challenges
SBOM producers are also facing significant generation and distribution challenges. First, though there are several SBOM generation tools available to automate results, each produce different outputs. Determining which to use is not an easy task to begin with as some are dependent upon specific ecosystems[7], such as Python. Additionally, not all tools are equipped to discover every software dependency, limiting their utility. Huge organizations using multiple development ecosystems will therefore require the use of different SBOM tools leading to decreased efficiencies and greater management requirements. To date, there isn’t one tool that will work exclusively for most SBOM consumers. This means that significant testing and customized adaptation is currently needed – highlighting the true immaturity of the SBOM space.
Second, concerns about their public distribution has SBOM producers on edge due to fears this will provide attackers easy access to confidential information like intellectual property. Some argue that it could also provide an attacker with valuable details about the software dependency relationships which could be used for the development of another exploit against that dependent application[8]. However, to support transparency SBOMs must be released to publicly available forums, such as an organization’s website. It is the best way to assure customers and partners of oversight in software security practices and to provide them with immediate documentation should an attack occur. There are increasing discussions around distributing SBOMs on a one-off basis or under strict non-disclosure agreements (NDA) with authorized customers to protect legal interests. Ultimately though, hiding SBOMs could put consumers at greater risk for exploitation due to the lengthy processes required for requests and agreement on NDAs. Moreover, clever attackers are not restricted to SBOM releases for reconnaissance activities, as prior supply chain attacks have demonstrated.
Final thoughts
SBOM consumers will eventually become smarter and more aware about potential security issues in the code they rely on to run their business. It will enable quicker decision making in the long-term, as standardization around SBOMs, including formats, automation, and tooling, improves. Now, however, we find ourselves a state of flux, with SBOM producers focused on meeting minimal requirements, managing multiple tools, and unnecessarily protecting their results, which is not benefiting SBOM consumers. Broadly speaking, SBOMs are not ready for prime time. These concerns need to be immediately addressed for greater impact across the software supply chain.
[1] The White House. (2021, May 12). Executive order on improving the nation’s cybersecurity. The White House. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
[2] Cyber Resilience Act. (2022, September 15). Shaping Europe’s Digital Future. https://digital-strategy.ec.europa.eu/en/library/cyber-resilience-act
[3] Hughes, C., & Turner, T. (2023). Software transparency: Supply chain security in an ERA of a software-driven society. John Wiley & Sons, Inc.
[4] Fudo. (2023, April 11). Impact of Apache Log4j vulnerability and how to stay safe! Fudo Security. https://fudosecurity.com/blog/2022/01/28/impact-of-apache-log4j-vulnerability-and-how-to-stay-safe/
[5] Epp, D. (2022, October 21). Can SBOM help you attack APIs? Dana Epp’s Blog. https://danaepp.com/can-sbom-help-you-attack-apis
[6] The White House. (2021, May 12). Executive order on improving the nation’s cybersecurity. The White House. https://www.whitehouse.gov/briefing-room/presidential-actions/2021/05/12/executive-order-on-improving-the-nations-cybersecurity/
[7] Zantow, K. (2023, September 19). How to Generate an SBOM with Free Open Source Tools. Anchore. https://anchore.com/sbom/how-to-generate-an-sbom-with-free-open-source-tools/
[8] Ph, N. (2021, August 3). Why we need to put the brakes on public software bills of material. TechBeacon. https://techbeacon.com/security/why-we-need-put-brakes-public-software-bills-material