Bad Software Cost US Businesses $2.1 Trillion In 2022

Poor software quality may have cost the U.S. at least $2.41 trillion this year, nearly double that of the country’s budget deficit.

According to a report released by Synopsys and the Consortium for Information & Software Quality, the cost of poor software in the U.S. — which includes vulnerabilities that lead to cyber attacks, complex software supply chain issues, and the increasing impact of accumulated technical debt — have led to soaring collective costs for American businesses and other organizations.

“Cybercrime is predicted to cost the world $7 trillion in 2022. Now is the time to turn our attention to recent developments and emerging solutions to help improve the poor software quality situation as it now exists and stabilize and reduce the growth rate of CPSQ in the near future,” said Herb Krasner, the report’s author and retired Professor of Software Engineering at the University of Texas at Austin.

While the actual cost of cybercrime losses and the number of supply chain incidents have yet to be finalized for 2022, the data highlights the increasing number of cybersecurity vulnerabilities in open source software as one of the primary drivers of the problem in recent years.

The number of software supply chain failures related to open source components increased by a whopping 650% between 2020 and 2021. Perhaps not coincidentally, 77% of organizations reported a wider adoption of open source software during the year.

Indeed, despite the SolarWinds and Log4j incidents serving as wake-up calls for exposure to third-party applications, open source repositories have remained ripe for exploitation over the past year.

The report also found that the cost of accumulated technical debt in the U.S. has risen to nearly $1.52 trillion in 2022 alongside operational failures and supply chain issues.

“Technical debt accumulates over the life of a software application. Early in its lifecycle, an application does not have the full feature set that can be found in later versions,” said Anita D’Amico, vice president of cross-portfolio solutions and strategy at Synopsys and a CISQ board member. “Those features are the result of a set of technical decisions about how best to implement them, given the constraints of how the application is structured. Over time those constraints limit the options available to development teams for not only how best to implement new features, but also how best to mitigate security issues.”

Goverment, industry working to drop SBOMs on vulnerable code

D’Amico also said that creating a Software Bill of Materials (SBOM) in the upcoming year can help with security risk management.

Significant parts of the software sold in commercial systems are pulled from free repositories or other sources, and few companies put time into documenting the provenance of each line of code. Such bills – or “SBOMs” as they’re often called – function as lists of code snippets or components that make up different software programs. In theory, they can be leveraged when a new vulnerability is discovered to quickly identify other programs and systems that rely on the same vulnerable code, providing defenders with a map of assets that need to be patched or remediated.

“Creating a Software Bill of Materials (SBOM) allows organizations to proactively gather a comprehensive inventory of the components used to make up a piece of software. That means when a new vulnerability is identified in an existing component, organizations can quickly identify where it is in their software and take action to remedy it,” D’Amico explained.

But few organizations actually develop SBOMs today. The Biden administration has tasked the the Cybersecurity and Infrastructure Security Agency and the National Institute for Standards and Technology with developing a framework to promote the creation and implementation of SBOMs better manage vulnerabilities like Log4J and SolarWinds that are deeply embedded across industry and other sectors.

However, major industry players have expressed reluctance with any mandates around the concept. Just last week, several trade groups, including the U.S. Chamber of Commerce and the Cybersecurity Coalition, published an open letter asking Congress to delay SBOM for defense contractors until the ecosystem matures.

Kristen Bell, director of application security at GuidePoint Security, told SC Media that the arguments in the open letter are reasonable and worth considering.

To build a mature SBOM, organizations and policymakers need to work together to ensure that new legislation does not introduce unintended consequences.

“Lawmakers need to rely on the opinions of technical experts, and there should be an evaluation of how some in the private sector address third-party vendor management. For example, many third-party vendor management processes require a [nondisclosure agreement] to be in place prior to a software vendor exposing details of their applications to the prospective buyer,” she said.

In addition, security experts told SC Media that organizations and policymakers should consider the cost of remediation when pushing SBOM.

“While an SBOM is a foundational requirement to vulnerability, we should be asking ourselves if that vulnerability actually impacts our application,” said Jamie Scott, founding product manager at Endor Labs.

“[SBOM] should include a vulnerability exploitability exchange addendum to help teams understand what is exploitable among their detected vulnerabilities. This is important because we know from recent research that more than 85% of detected vulnerabilities are not actually exploitable,” Liran Tancman, CEO of Rezilion, added.

That said, producing SBOMs may not be enough to secure the software supply chain and reduce CPSQ in the upcoming year. Brian Behlendorf, general manger of the Open Source Security Foundation, told SC Media that companies are encouraged to adopt complementary security tools alongside SBOMs to reassure developers of their components’ security profile, such as OpenSSF’s Scorecards and the tools outlined in the Concise Guides for Developing More Secure Software and Evaluating Open Source Software.

READ MORE HERE