Originally published on Forbes, September 30th, 2021
It’s no secret that cyberattacks are increasing at an unprecedented rate. With more and more businesses digitizing every aspect of their operations, the threat landscape has expanded to encompass an ever-increasing attack surface.
Meeting these threats requires serious investments in both time and money to ensure that the right people, processes and technology are in place. However, that in and of itself isn’t always enough; as breaches can occur from almost anywhere, the organizational culture needs to undergo significant change as well. Internal staff must be made aware of the new realities of a hostile environment constantly probing at their defenses and adapt accordingly. Existing processes need to be reworked so that companies shift left and move security to an earlier stage of the development cycle.
Reshuffling at this scale requires budgets that can only come with full executive buy-in. Unfortunately, the importance of cybersecurity is still underemphasized in many organizations; in some enterprises, executive leadership often only sees cybersecurity as a priority after an incident occurs.
To change this situation, leadership must be made to understand that security is an everyday priority and that ignoring cybersecurity can have serious consequences with repercussions that compound over time. Leadership must also acknowledge that issues that arise from cybersecurity accrue interest in a way that’s similar to financial debt (i.e., the longer one delays mitigation, the greater the total cost required to handle risk down the road).
The Rising Costs of Technological Debt
Technological debt is a well-known concept in software development that describes the consequences of implementing compromises or poorly written code into the development cycle. This often creates deficiencies in internal quality that eventually make it more difficult than it should be to continue developing the system. This difficulty becomes more acute with time, meaning that as more time goes by, the financial or time investment required to “pay back” the debt only grows.
The term was coined by Ward Cunningham as a way to conceptualize this idea. He used it as a metaphor to lend a financial spin on the extra work required to continue developing systems that have acquired technological debt (i.e., as the interest paid on that debt). Technological debt can be caused by deadlines, tight budgets, bad decisions or poor development abilities. An example could be a confusing module structure implemented in the codebase that adds three extra days to the time required to develop a new feature. Those extra days are the interest on the technological debt.
Vulnerability Debt: the Cumulative Cost of Neglecting Vulnerabilities
One way to better conceptualize technological problems in terms of their potential business impact is to apply a financial framework to cybersecurity risks. This approach may help leadership realize the bottom-line cost of launching products before vulnerabilities have been mitigated and acknowledge the need to rethink technological decisions in a way that better reflects their long-term financial impact.
Borrowing from the technological debt concept, the industry has adapted the term specifically for cybersecurity. Vulnerability debt refers to the often known, noncritical vulnerabilities that are ignored or rather accepted temporarily so that products are shipped faster. Absorbing vulnerability debt is a compromise that accepts higher levels of risk in favor of faster deliveries, with developers planning on tackling the vulnerability relatively quickly, ideally in an upcoming release.
However, the reality is often far from the ideal. In software systems, “temporary” vulnerabilities become a thorn when time goes by and the product software continues to evolve and advance. Upgrading to newer architecture becomes more complicated because of the system’s reliance on libraries from the previous version. In embedded systems, vulnerabilities originally accepted as a temporary risk that can be fixed rather quickly and cheaply become permanent when developers realize that significant system changes mandate time-consuming, expensive functional safety tests. In both cases, noncritical vulnerabilities become cost-prohibitive challenges that prevent the healthy development of a system.
And just like financial debt, the longer a vulnerability debt exists, the more it costs to eventually pay it back and fix the vulnerabilities. For one, as older versions remain in place, more and more vulnerabilities are discovered, significantly increasing the effort required to secure the system. Even when the decision has been made to upgrade to a new version, one that has fixed the vulnerabilities, challenges abound.
From version to version, the technology and patch gap grows — as does the effort required to upgrade. This goes double for embedded systems where updates are hard to implement and even more so for mission-critical systems where complex validation procedures and functional safety requirements (driven by regulations and standards) are mandated to safeguard the entire system.
Vulnerability debt can be used as a powerful framework that moves the conversation away from complicated tech terms. By restructuring abstract tech terms like risk levels into financial terms such as accrued interest on vulnerability debt, executives may have an easier time understanding the repercussions of their prioritization decisions. This concept can help executives realize that absorbing vulnerabilities isn’t just about R&D risk levels but rather about real financial debt that accrues interest with time.
Staying Out of (Vulnerability) Debt
Cyber risk and software vulnerabilities are often perceived as purely technical, so relevant discussions are delegated to technical functions. However, that should not be the case. The latest cyberattacks demonstrate that the cost of vulnerability debt spans far beyond monetary damages, especially when compounded with incident response efforts, litigation, regulatory penalties and loss of brand equity.
To reduce your vulnerability debt and cyber risk, you need to frame it as an enterprise risk and discuss it as such. Quantify vulnerability debt based on the potential damage to your business so that everybody — leadership team and board included — can understand it.
Keeping weaknesses out of your codebase can prevent them from becoming a painful vulnerability debt on your business. Consider it as an investment.
Did you find this interesting? Share it with others: