A new report estimates the cost of poor software quality at $2.41 trillion for the U.S. in 2022. Cybercrime, software supply chain challenges, and technical debt are major contributors.
Synopsys 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.
CISQ identified cybercrime, technical debt, and supply chain problems as key contributors.
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.
Synopsys Software Integrity Group 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.
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.
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.
Mike McGuire is a senior software solutions manager at Synopsys where he has spent several years leading go-to-market efforts for open source risk and software supply chain security solutions. After beginning his career as a software engineer, Mike transitioned into product management and strategy roles, as he enjoyed interfacing with the buyers and users of the products he worked on. Leveraging several years of development experience, Mike enjoys connecting the market’s complex AppSec problems with Synopsys’ comprehensive solutions.