Don't Be Blindsided by Software Bills of Materials

Many in our industry are weighing the benefits that software bills of materials (SBOMs) could possibly bring to software quality and security. I think SBOMs are needed to understand and assess risk in software because they should provide visibility into the software construction process for a given software system. At some level, SBOMs already exist for certain products and software systems; however, their application for evaluating quality and security as stipulated in Executive Order 14028, Improving the Nation’s Cybersecurity and recent federal guidance by the US Office of Management and Budget, the National Institute of Standards and Technology, and the Cybersecurity Infrastructure and Security Agency is fairly new and unproven at scale.

**The Royce Bill That Never Passed****

Around 2013, SBOM legislation H.R.5793 – Cyber Supply Chain Management and Transparency Act (known as the Royce Bill) was introduced but never gained the momentum it needed to pass as a mandate, bill, or requirement. The industry did not then have the appetite for transparency to manage software supply chain risk.

The issues this legislation would have addressed are outlined in the Congressional Record – Extensions of Remarks. These issues have now been exacerbated given the overwhelming amount of complexity and growing size in modern software development, and the increasing rate of attacks against open source software. With the increasing consumption rate of open source software in modern software development, consumers must be aware of the technical debt in open source software projects that has accumulated over time to better manage software risk. The idea of more software complexity, larger software systems, and mounting technical debt does not bode well for the federal government’s desire for software integrity and trustworthiness through the software supply chain.

The fact that the Royce Bill didn’t pass can be seen as a missed opportunity to address the growing threats and risk in software security at the time. Almost a decade later, the industry is still struggling to figure out how to implement SBOMs and strike the right balance to make them useful and not a target for adversaries to exploit. This raises major concern in industry about whether SBOMs are ready for prime time given the skepticism regarding the current requirements outlined in federal guidance.

****SBOM Must Inform About Unknown Risk****

One of the challenges for SBOMs is advancing and understanding how risky software is determined. I use the term “risky” because all software has vulnerabilities, and the SBOM must be able to differentiate or provide context to the level of risk associated with a software component, whether in isolation or once it has been implemented and integrated into a software system. To simply say you can’t use this software component because it has CVEs (common vulnerabilities and exposures) associated with it becomes moot because all software can have vulnerabilities. SBOMs must be able to succinctly qualify which CVEs are the most dangerous and exploitable given the context the software will be implemented and used — the component function (logging, encryption, access control, authorization), the environment, and whether it can be hardened to reduce a given attack surface. The way in which software components are integrated into a system matters because software components can be implemented poorly or incorrectly, exposing vulnerabilities in software systems.

Using CVEs to establish a security baseline for open source software consumption make sense; however, tallying a bunch of CVEs to determine what software is less risky or riskier only focuses on the “known knowns” (as shown in the figure below) and does very little to help organizations understand what weaknesses are lurking that may expose vulnerabilities and impact the overall hygiene of that software component (over a period of time). Furthermore, the current state of practice regarding SBOMs doesn’t encourage software supply chainers to understand the defect proneness or attack proneness rates associated with software. This is important because some software components are highly targeted and require significant patching due to inherent technical debt, low code quality, and security issues that expose vulnerabilities. More patching means developers and engineering teams are spending less time on creating and delivering new features and functionality to customers.

Defect proneness refers to the likelihood that a software component will be defective after a software product is released. There are various socio-technical factors that contribute to defect proneness such as low code quality and design flaws. Attack proneness refers to the rate at which software components can be successfully exploited, or the likelihood that software components will contain exploitable weaknesses — bug, defect, or flaw — or vulnerabilities.

Source: Kevin Greene

SBOM solutions must give organizations visibility into potential risk for a given software component as shown in the figure above, helping organizations make informed decisions about which software components to use and which software components to avoid. For instance, advice in the National Security Agency (NSA) Cybersecurity Information Sheet encourages developers to avoid using software developed in C and C++ because those programming languages were not intended to enforce good memory management checks. It will be interesting to see how this advice will affect the software supply chain, mainly for embedded safety critical systems, and whether suppliers will turn to programming languages that are memory safe, such as Rust and Go.

****Go Deeper to Guide SBOM****

SBOMs are not going away, so it’s imperative we all collaborate and partner to improve software security. This may require developing tools and standards that can enrich SBOMs and provide deeper analysis and insight about the characteristics of software that help inform about software risk. This will help organizations effectively evaluate and attest to software integrity, as well as other software assurance properties. Ultimately, it’s important for software supply chainers to understand not just the risk associated with a given software component but the potential maintenance associated with using that software component over a period of time, given the challenges in industry to remediate vulnerabilities in software in a timely fashion. The use of defect and attack proneness rates could provide actionable intelligence that helps lower the consumption of risky software with poor hygiene, and guide software supply chainers in building software systems that are more resilient to cyberattacks.

In theory, software components with high defect and attack proneness rates should be avoided to help stimulate and encourage the use of alternatives with better hygiene. In my opinion, SBOMs don’t improve code quality and security directly, but they can make software supply chainers more aware of risk in their software construction process. Improving code quality and security for open source software requires a culture shift given that having many eyes does not make all bugs shallow.

**