Poor software quality can cost time and money, straightforward solutions are available

Most of the time, ROI is calculated on how much money you made on the money you spent. But it also applies to money you didn’t have to spend. As the old proverb puts it, “A penny saved is a penny earned.”

And by that measure, there are hundreds of trillions of pennies going unearned, because organizations aren’t investing in improving their software.

According to “The Cost of Poor Software Quality in the U.S.” by the Consortium for Information and Software Quality (CISQ), the collective bill in the U.S. for defective software in 2021 was an estimated $2.41 trillion, up almost 16% from the 2020s $2.08 trillion. That’s more than the GDP of all but a dozen countries.

And it doesn’t even count an estimated $1.52 trillion in “technical debt” (TD)—accumulated software vulnerabilities in applications, networks, and systems that have never been addressed but will have to be paid eventually.

Those and other findings illuminate an alarming state of apparent denial among organizational leaders who know or ought to know, that software can make or break them. If it’s high quality, with security “built-in” throughout development, software can make a business prosperous.

But if it is written or maintained poorly, software can make an organization an easy target for online attackers, who can exploit its vulnerabilities to steal intellectual property, money, and customer information. It can damage brand reputation, leave organizations vulnerable to legal and regulatory liabilities—even put them out of business.

Given that, you might think any organization that wants to prosper would make the quality and security of its software a high priority. Who wouldn’t want to be on the “make” side of make or break?

Apparently, not so much.

The biannual report, cosponsored by Synopsys, found that the major reasons for the cost of poor-quality software (CPQS) continuing to increase are:

– Failure to fix existing vulnerabilities. Note that these aren’t zero-day vulnerabilities—they’re known. In almost all cases, there are patches or updates available. They just aren’t being applied.

– Software supply chain problems. In 2021, 77% of organizations reported an increase in their use of open-source software. But the number of failures due to weaknesses in the open source components in software supply chains increased by much more—650%. This means organizations are using it more but protecting it less.

– Rapidly accumulating TD. The report describes TD as “the biggest obstacle to making any changes to existing codebases.” That’s because its impact is similar to that of growing credit card debt. When it gets too large, borrowers get caught in a downward spiral of paying only interest and never paying down the principal.

What to do about all that?

The overall goals of the CISQ report, according to author Herb Krasner, retired professor of software engineering at the University of Texas, Austin, are not simply to document how bad things are, but also to recommend solutions.

Among them are:

– Secure the software supply chain. This is especially true for open-source components, which are a prime attack surface. The annual Synopsys “Open Source Security and Risk Analysis” (OSSRA) report has documented that open-source software components are in virtually every codebase. Krasner noted that even a medium-sized application has 200 to 300 third-party components in it.

The latest OSSRA report found that 91% of the codebases analyzed had outdated—as in, unpatched—versions of open-source components. That means far too many organizations are ignoring the key to maintaining the security of those components—keeping an inventory of them. The way to do that is well-established. An automated software composition analysis tool will find open-source components, which can then help create a software Bill of Materials (SBOM).

– Address technical debt. TD is rampant because of short-term thinking. Allowing TD to go unaddressed “comes with substantial, initially hidden costs that organizations must pay later,” Krasner wrote. But there are automated tools available, including static code debt analyzers, to help companies start paying off both the principal and interest of that debt.

– Set quality standards and then conform to them. A quality standard already exists, created by CISQ, called ISO 5055, which defines source code quality measurements in four categories: reliability, performance efficiency, security, and maintainability. “If all new software were created without known vulnerabilities and exploitable weaknesses, the CPQS would plummet,” Krasner wrote.

These and other recommendations take time and money to implement. But an investment in high-quality software that you and your customers can trust can help you save, and therefore earn, a lot more pennies.

To learn more, visit us here.