President of Univention North America, making sure you stay in control of your data, your company and your future.
getty
With 99% of all commercial code bases containing open-source software, open source rules the world. Yet, 74% of all codebases also contain a high-risk open-source vulnerability, according to the latest annual report on "Open Source Security and Risk Analysis" by design automation company Synopsys.
At first glance, these vulnerabilities speak against using open-source software, but the truth is a bit more complicated. As the report points out, the mean age of the vulnerabilities was 2.8 years, and most components were 10 or more versions out of date.
Code, it turns out, doesn't age well and becomes quite problematic when it’s not constantly maintained, as all of us smartphone owners who forget critical updates will attest to. Experts even have a name for it—technical debt, and it’s all too often overlooked as a liability.
So, how did we get to the point that the vast majority of our systems contain years-old vulnerabilities, and what can we do to fix those?
Check The Stack: Software Supply Chain Management Is Critical
On the outside, it looks relatively easy. Open-source libraries have already solved most fundamental problems in the software world. Most of these libraries are free to use and don't present a risk to the commercial code base. That’s why developers are always happy to add an open-source library or component here and there. After all, rapid improvements and new features can help keep customers happy and consequently increase the bottom line. Any software consists of many underlying libraries glued to the company's code.
This accumulation of software, though, needs to be documented and maintained. Companies rarely perform complete audits of their whole stack. As a result, libraries and dependencies from "quick fixes" are forgotten in the day-to-day grind and a new, largely hidden tech debt starts accumulating.
Customers are even less likely to audit the software they run in their business. That’s because many have neither the experience to perform those audits themselves nor the clout to force their suppliers to give them an inside view into the code base.
It’s a multifaceted oversight with dire consequences. At the end of the day, no one has a clear and complete overview of how many compromised pieces of software exist within a company.
Beware Of The Fine Print: The Trouble With SBOMs
Software bills of materials (SBOMs) were supposed to fix the issue. Their goal was to give us the ingredients of every software. The list would have allowed customers to see the dependencies that go into a software product and how recently the integrator updated it. Having that insight, the thinking goes, would make it easier to take measures if the software had known security vulnerabilities.
Unfortunately, I've found SBOMs haven't delivered on all their promises. First, the government's requirements do not specify how extensive an SBOM should be or how to create it. The minimum requirement, for example, only mentions SBOMs to include the top-level dependency. If the dependency has other dependencies, the SBOM wouldn't need to list them to be compliant. That means highly dynamic languages like Python or Java might include many phantom dependencies that users are not even aware of.
Second, the flexibility or 'wiggle room' in U.S. requirements has led to widespread reporting using different tools. Both readability and actionability depend highly on the vendor and software version you’re using.
Speak Up: Vendors Should Be Held Accountable
Even if the software vendor includes their SBOM, most companies don't have the resources or abilities to hold their suppliers accountable. Costs, time and licensing terms restrict their possible options. Overworked IT departments and a lack of interest by boards and top-level executives may further contribute to the problem.
On the commercial side, switching a supplier or service provider is often cost-prohibitive, regardless of whether you change software or do a cloud migration. Additionally, the lack of open standards and APIs makes many projects labor-intensive.
There’s a legal aspect to this issue as well. Many terms and conditions protect the vendor from the customer. Claims like "this software is not fit for any particular purpose" severely restrict customers' legal recourse. Until courts accept that not updating software is akin to gross negligence, we won't see any changes. Even then, arbitration terms further restrict the way customers can seek recourse.
The high costs and legal constraints leave bad publicity as the only avenue to redress legitimate concerns. Calling suppliers out to provide secure software often is the only way customers can bring attention to the problem. But it also has a flipside as it increases the vulnerability. For starters, you publicly acknowledge that you are using insecure software and, by doing so, make yourself a target.
In addition, there is no guarantee that going public will exert enough pressure on a software vendor to fix things. Even after two years and significant coverage, security problems with the Java-based logging utility Log4J linger in over 30% of the use cases.
Risky Business: Don't Ignore Hidden Tech Debt
Today, most companies have accumulated obvious tech debt in the form of outdated systems and components, which is in many cases easier to explain and fix. Code gunk builds up and—if not addressed—will eventually have a corrosive effect on an organization. In severe cases, this could lead to catastrophic consequences. But that realization doesn't excuse turning a blind eye to the additional hidden debt that suppliers and software dependencies add to our existing IT worries.
It’s critical for businesses to improve dependency management and build more awareness of the software they are using by asking for things like transparency and more audits. Otherwise, it’s only a matter of time before the next major vulnerability issue will surface. In the end, an update of the code base is always preferable to any news update.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
