Don't Be Blindsided by Software Bills of Materials

It's imperative we collaborate and partner to improve software security. This may require developing tools and standards that can enrich SBOMs and provide deeper analysis.

Kevin E. Greene, Public Sector CTO, OpenText Cybersecurity

January 6, 2023

6 Min Read
Digital lock indicating security
Source: vska via Alamy Stock Photo

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.
Three types of software vulnerabilities: Known knowns, known unknowns, unknown unknowns
Source: Kevin GreeneSBOM 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.

About the Author(s)

Kevin E. Greene

Public Sector CTO, OpenText Cybersecurity

Kevin E. Greene is a public sector expert at OpenText Cybersecurity. With more than 25 years of experience in cybersecurity, he is an experienced leader, champion, and advocate for advancing the state of art and practice around improving software security. He has been successful in leading federal funded research and development (R&D) and has a proven track record in tech transition and commercialization. Notably research from Hybrid Analysis Mapping (HAM) project was commercialized in former technologies/products by Secure Decisions’ Code Dx and Denim Group Thread Fix, which were acquired by Synopsis and Coal Fire respectively. Additional commercialization includes GrammaTech Code Sonar, KDM Analytics Blade platform and research transitioned to improve MITRE’s Common Weakness Enumeration (CWE) by incorporating architectural design issues from the Common Architectural Weakness Enumeration (CAWE) research project developed by Rochester Institute of Technology (RIT).

Prior to joining OpenText Cybersecurity, Kevin worked at the MITRE Corporation supporting DevSecOps initiatives for sponsors, Adversarial Tactics, Techniques, and Common Knowledge (ATT&CK) research under the Center for Threat Informed Defense (CTID), and high-performing contributor to MITRE’s CWE program. Kevin valued his time serving the nation as a federal employee at the Department of Homeland Security, Science and Technology Directory, Cyber Security division, where he was as program manager leading federal funded research in software security.

Kevin currently serves on the advisory board/committee for New Jersey Institute of Technology (NJIT) Cybersecurity Research Center where he holds both a Master of Science and Bachelor of Science in Information Systems; as well as Bowie State University Computer Technology department and Bryant University Cybersecurity/Cloud Program external advisory boards.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights