Building trustworthy software can feel impossible. The goal should not be the number of tickets closed or quantity of vulnerabilities remediated; it is instead about consistently achieving and delivering on the promise of trustworthy software that improves the security posture of what we build. The goal should be to empower software suppliers, consumers, and security teams on both sides to identify and address problems worth solving. This helps us keep one another safe while using the brilliant things we build. That is why we work in software security.
To get there, we need to consider the problem with the current system, the new capabilities we have today, and the way we work to focus on security posture management. This information is meant to intentionally tie a few core concepts together – CVEs, EPSS, SBOMs, and VEX – to help software development and security teams work towards their common goals. The aim of that strategy is to help us ship more safe software by focusing on the attack surface of supply chains: exploitable vulnerabilities. Taking this approach allows us to reinvest our efforts into activities that keep consumers secure and products delightful.
Signal to Noise Ratio
Driving risk management activities based on Common Vulnerabilities and Exposures (CVE) and the underlying Common Vulnerability Scoring System (CVSS) base score is no longer serving us. As of May 31, 2024, there were 237,687 published CVEs. In the past 12 months alone, we have added an additional 30,000 CVEs to the catalogue of known vulnerabilities. Annually, we average a 16% increase. Yet, only about 6% of all published CVEs have been exploited; a rate that has held relatively steady since 2017.
For most companies, vulnerability management is driven by the CVSS score of the vulnerability. As the quantity of CVEs rise, and densely clusters in critical and high categories, a CVSS-driven approach no longer works. In response to this, data-driven efforts for estimating the probability that a published vulnerability will be exploited in the wild are taking hold.
The Forum of Incident Response and Security Teams (FIRST) launched the Exploit Prediction Scoring System (EPSS) in 2019. The promise of EPSS, and similar decision-frameworks, is to refocus priorities to defend against known exploits to generate more value out of vulnerability management activities, freeing the capacity of software and security teams into highly productive activities. A CVSS-driven approach often comes at the opportunity cost of greater security and organizational objectives when teams are asked to remediate non-exploitable or non-applicable vulnerabilities.
The premise is simple: if only about 6% of CVEs have exploits, spending the finite organizational capacity on non-exploitable vulnerabilities does not generate a return on security investment. In fact, even within that figure, an exploitation of a CVE is only possible in the context of the overall system the CVE exists in (e.g. certain vectors, certain attack requirements, etc.). Only a subset of that percentage is applicable for exploitation. This does not mean that vulnerability management is not a critical function, rather, it means that we need different strategies to solve complex and meaningful problems at scale. Doing so prioritizes focusing on targeted security posture protection over vulnerability management more generally.
Cracks In Supply Chains
While the problem of low return on security investment applies generally, it likely applies most impactfully in the field of application security. The growth of open source and third-party dependencies has led to a boom in new product and capability development. However, with it comes a sharp rise in the number of CVEs for those applications. We do not have enough eyeballs to consistently uncover all the security bugs.
A now classic example of this issue was the Apache Log4J incident of 2021, which impacted global software supply chains and shed light on the risks of both security monocultures and supply chain security. It is worth noting, however, that open source software is not by any means the only concern as we learned through the SolarWinds SUNBURST incident. As a result, the US Federal Government took action in an Executive Order(M-22-18, M-23-16) to address supply chain security by requiring a bill of materials in the product.
The concept of a bill of materials has existed for decades. When you have a product, you want to know all the ingredients, components, and processes needed to create the finished work. This manifest of ingredients reduces information asymmetries between producers and consumers.
Rise of the SBOM
At its core, a Software Bill of Materials (SBOM) is a transparency mechanism that encourages collaboration and accountability. While SBOMs come in two flavors, System Packet Data Exchange (SPDX) and CycloneDX, both supply critical information that describe the components of the software system. At a minimum, SBOMs must include identifying information about the supplier, the component and version, dependencies related to the component, and certain other metadata. This information is powerful and helps software developers, application security teams, and end customers differently.
SBOMs support developers with an improved understanding of software, collaboration amongst teams, and overall maturity. They give developers traceability, easier dependency management, redundancy reduction, and overall system optimization. SBOMs support security teams with enhanced vulnerability management capabilities, improved incident response efficiency at scale, and visibility into third-party components for several purposes including regulatory compliance and licensing. SBOMs help end customers by providing transparency into software supply chains, giving them observability into the products and software services their organizations seek to use or use already. But with that opportunity for transparency comes friction when organizations realize that their SBOMs also attest to the efficacy of engineering and security programs.
The Problem with Debt
If you work in software development, then “technical debt” is a term that likely triggers strong reactions. Foundationally, technical debt serves a similar function to financial debt. When well-managed, both can be used as leverage for further growth opportunities. In the context of engineering, technical debt can help expand product offerings and operations, helping a business grow faster than paying the debt with the opportunities offered from the leverage. On the other hand, debt also comes with risks and the rate of exposure is variable, dependent on circumstance.
In the context of security, acceptance of technical debt from End of Life (EoL) software and risky decisions enable threats whose greatest advantage is time, the exact resource that debt leverages. While defenders put off key activities to buy time so they can build applications, attackers use that same time to engage in reconnaissance, reverse engineering, and other techniques. This allows them to exploit slow moving software projects and reuse that exploitation investment at scale over a wide range of companies taking dependency on the product. At some point, the debt comes due.
Practitioners know that out of date and unsupported software components represent a significant risk. According to Qualys Threat Research Unit (TRU) data, 20% of critical applications have EoS software that contain “high” or “critical” severity vulnerabilities. 48% of issues on the CISA Known Exploited Vulnerabilities(KEV) catalogue are EoL software and operating system issues. For many CVEs, the root issue is technical debt that presents as a security issue. Unlike software, which ages like milk, attackers’ capabilities age like fine wine. Security is the symptom; technical debt is the disease.
Turning Data into Decisions
While unintended, the delivery of an SBOM without exploit information tends to cause friction, as it does not provide the context of the application itself. For those building and reviewing SBOMs, they would be well-served to embrace the Vulnerability Exploit Exchange (VEX), which decorates an SBOM with important machine-readable information.
VEX is a method to standardize discussions around software vulnerabilities found in specific components. A VEX document is an attestation file that rides along with an SBOM, a form of a security advisory that indicates whether a product is affected by any known vulnerabilities. When software suppliers provide a VEX, they define if the product is affected by a CVE or not, signal if it is under investigation, or affirm that it has been fixed. This helps suppliers and consumers determine if remediation is required to address the vulnerability. Based on that, internal security review teams and supply chain organizations can have more productive risk-based discussions than they do today.
Strategy In Practice
The trustworthiness of software is dependent on the exploitable attack surface. Part of that attack surface are exploitable vulnerabilities. If the outcome of the SBOM with a VEX attestation is a deeper understanding of those applicable and exploitable vulnerabilities, coupling that information with exploit predictive analysis like EPSS helps to bring valuable information to decision-making. This type of assessment allows for programmatic decision-making. It allows software suppliers to express risk in the context of their applications and empowers software consumers to escalate on problems worth solving.
When you have a list of a hundred, a thousand, or ten thousand issues to fix without any context, where should you start? Who is responsible for the fix, and where do those issues come from? Using SBOM data alongside exploit prediction (perhaps even risk scoring) allows teams to get the insight needed to prioritize, addressing spot issues or wide-scale issues. This speeds up processes, highlights specific problems, increases flow, and reduces cognitive overload.
Software development and cybersecurity are hard because of information asymmetries. There is context that security teams do not have about the underlying application that they need to risk manage. Conversely, software development teams need specific, highly valuable, and actionable asks from security teams so that they can succeed in their role of building products worth using. By refocusing on the security posture of an application, rather than chasing a list of vulnerabilities, we can get back to what inspired us to work in software. Trustworthy software is achievable, if we focus on what is urgent and important.
Alex Kreilein is Vice President of Product Security at Qualys. He focuses on delivering security and quality improvement outcomes across a portfolio of award winning products to ensure the highest standards of security, trust, and compliance. Prior to joining Qualys, Alex held multiple security management roles, including responsibility for early access programs for critical infrastructure security at Microsoft, as well as being a Technology Policy Strategist for the US Department of Homeland Security and a Guest Researcher at the National Institute of Standards and Technology (NIST).