What is the cost of poor software quality in the U.S.?

Dec 06, 2022 / 5 min read

Table of Contents

What contributes to the cost of poor software quality?
A deeper look at supply chain challenges
Failure to patch
What security testing measures should organizations use to minimize their risk?

Black Duck recently cosponsored "The Cost of Poor Software Quality in the U.S.: A 2022 Report” with the Consortium for Information and Software Quality (CISQ). The report investigates the ever-increasing financial impact of poor software quality, and the factors that further its continued growth.

At a high level, the report's findings reflect that as of 2022, the cost of poor software quality in the U.S.—which includes cyberattacks due to existing vulnerabilities, complex issues involving the software supply chain, and the growing impact of rapidly accumulating technical debt—will total approximately $2.41 trillion.

The report examines these challenges in depth and provides guidance and suggestions for how an organization can best address them, which we will summarize below.

What contributes to the cost of poor software quality?

CISQ identified cybercrime, technical debt, and supply chain problems as key contributors.

Cybercrime. The CISQ report notes that cybercrime losses due to software vulnerabilities rose 64% between 2020 and 2021. Data shows another increase of 42% from 2021 to 2022. The report’s author, Herb Krasner, found that cybercrime is predicted to cost the world $7 trillion in 2022, making it a top priority for those tasked with security. According to the report, “the average cost of a data breach in the United States amounted to $9.44 million, up from $9.05 million in the previous year.”
Technical debt. The CISQ report found that technical debt has become the largest obstacle for organizations wanting to make changes to their existing codebases. “Technical debt” refers to the cost of rework in software development, accumulated deficiencies that desperately need attention but are very expensive and time-consuming to mend. But addressing these issues is critical to preventing problems that could leave data and systems vulnerable. CISQ found that these issues are not being resolved, and technical debt in the U.S. has risen to roughly $1.52 trillion in 2022.
Software supply chain problems. Most important to this report’s findings this year is the impact of software supply chain challenges. CISQ reports that supply chain problems with underlying third-party components are rising significantly. Problems stemming from weaknesses in open source components within the supply chain increased an alarming 650% from 2020 to 2021, a trend supported by the annual Black Duck “Open Source Security and Risk Analysis” (OSSRA) report. The data in the Black Duck report continues to underscore the importance of responsible and comprehensive open source security and risk management. With high-profile incidents like Log4Shell and SolarWinds, these types of issues are becoming a constant in the software development world.

Perhaps no cybersecurity trend was bigger in 2021-22 than the scourge of supply chain ransomware attacks. Among the biggest attacks was the Colonial Pipeline ransomware attack, which affected the East Coast of the U.S. in May 2021. There were also ongoing issues related to supply chain security due to a breach at software management vendor SolarWinds.

A deeper look at supply chain challenges

Former Black Duck VP of Cross-Portfolio Solutions and Strategy and CISQ board member Anita D’ Amico summed up the challenge of open source security within the supply chain: “In today's complex software supply chain, just because a newly added open source component is secure today does not mean that it will be secure tomorrow.” Which is to say, although open source itself is not the problem, the mismanagement of it is.

Echoing our own sentiments and warnings, the CISQ report notes that “most organizations are unaware of the extent to which they already use open source and underestimate their dependency on it, a dependency that comes with some risks.” Identifying and cataloging the open source throughout an application portfolio is the only way to identify and mitigate this risk.

According to the CISQ report, pre-existing vulnerabilities in an organization’s software supply chain “can enable an attack that targets the less-reliable components of a system’s supply chain. This can trigger a failure that creates a chain reaction that propagates to a network of providers and then spreads through the Internet to many other interconnected systems. These attacks are targeting the source code of the components of these software systems.” We saw this play out in the SolarWinds attack, in which a flawed software update secretly hosting a virus reached approximately 18,000 customers.

Failure to patch

A sister challenge to broader supply chain concerns is the trend of organizations failing to apply patches to known vulnerabilities. This failure leaves very preventable and avoidable gaps in a software security program. The OSSRA report continues to identify patching issues as a growing area of open source security risk. The ability to efficiently patch is inextricably linked to the ability to create and maintain a comprehensive catalog of an application’s code and the dependencies it leverages. Without an accurate inventory of your complete library of code, vulnerabilities and their available patches are impossible to identify.

Tracking application dependencies is no easy feat, though. In conducting research for our most recent OSSRA report, we found that the average application contains over 500 open source components. Trying to identify and track dependencies at this scale, and staying on top of the vulnerabilities and updates associated with them, can quickly become a daunting process and lead to the issues outlined in the CISQ report.

What security testing measures should organizations use to minimize their risk?

Organizations should analyze their existing security initiatives through the lens of the challenges outlined here. Considering existing and emerging software quality standards and tooling and how they can benefit or augment current security programs can be particularly helpful. Third-party and open source software components should receive extra attention, as they can provide an easy entry point for bad actors.

Given the scale of third-party and open source software usage, paying the necessary amount of attention to these components requires specialized tooling. Although manual processes, such as requiring developers to disclose which dependencies they’re leveraging, may have sufficed in the past, they leave large gaps today. For example, developers may only be aware of direct dependencies and not the further-removed dependencies.

Likewise, foundational components that have been in place since the architectural stages of application development should be tracked from their introduction. But the difficulty of staying on top of updates and the associated vulnerabilities for these components helps explain why we find foundational components to be the most vulnerable in our most recent OSSRA report. For this reason, automated detection and continuous monitoring of dependencies is necessary for staying on top of patches, and the risks that these patches often remediate.

Another important security best practice that can help mitigate supply chain risks is generating a robust software Bill of Materials (SBOM). D’Amico notes that “creating an SBOM allows organizations to proactively gather a comprehensive inventory of the components used to make up a piece of software, so as new and existing vulnerabilities are identified, organizations are fully equipped to act quickly to remedy those issues.”

Building an SBOM is only part of the process though; it simply provides a list of ingredients. Although it’s a necessary first step in securing the software supply chain, next steps should involve adding SBOM generation into development pipelines, and associating the listed components with areas of operational, security, and license risk.

CISQ wants organizations to think of the next vulnerability as inevitable. “[Organizations should be doing] anything and everything to prepare for the next Log4J,” the report states.