How AppSec debt hurts your company – and how to make it stop

What is technical debt in application development?

The concept of technical debt is as old as engineering itself. Whenever you put off making necessary technical improvements in favor of ongoing work, whether in an industrial plant or software development organization, you are accumulating technical debt that you will eventually have to deal with. For example, a software company might have a flagship application based on an aging core framework that creates more and more problems with each release. A modern framework is planned, but the company is committed to putting out a new release every six months and cannot spare the resources to develop and deploy the framework and then migrate the application to it. The legacy framework is the company’s technical debt. Unless replaced in a controlled way, that rusty old framework will eventually fail in one way or another and cause serious problems, maybe even delaying the next release until a new framework is finally deployed. Now imagine the problem is not performance or functionality but security – and you have AppSec debt.

5 sources of AppSec debt

Application security debt can come in many shapes and sizes, sometimes creeping in on multiple levels at once. While this is definitely not an exhaustive list, here are (in no particular order) five causes of security backlog bloat.

#1: Outdated components

With the manic pace of web application development, some security-related tradeoffs are often unavoidable in the short term. For instance, you might not have the time or resources to upgrade and reintegrate a crucial external library that is known to have a vulnerability in a function that you’re not currently using. In the short term, that’s not a security risk – but if you leave it for too long, someone might eventually use that vulnerable function, or attackers may find other vulnerabilities. That deferred upgrade is one form of web AppSec debt.

#2: Vulnerabilities coming in too fast

Endless vulnerability backlogs are another form of AppSec debt, with many organizations being forced to choose which security defects they need to fix now and which they must risk leaving for later. This is usually caused by working with test results that need time-consuming manual verification or having inefficient remediation workflows, with developers and security engineers forced to spend more time on investigating what to do than actually doing it. Combined with the fact that vulnerabilities are often introduced faster than they can be addressed due to insufficient education about secure development practices, this leaves companies resigned to always having a backlog.

#3: Insufficient visibility

A similar dilemma applies to entire application environments – if you don’t have a way of testing and securing every single web asset, you are also building up security debt. Most organizations don’t test all their public web assets simply because they don’t know about some of them, but even for known sites, they often need to choose where to assign their limited resources. That way, critical assets are kept secure while many (if not most) websites and applications are left untested or unfixed, again contributing to the security debt.

#4: Inadequate or ineffective tooling

Adding insult to injury, security tools themselves can contribute to the backlog. It is common for organizations to invest in tools that don’t deliver immediate security value because they need weeks if not months of integration work to deliver meaningful results – and until then, they are another drag on limited human resources. Worse still, misconfigured or simply low-quality tools can aggravate the whole situation by piling false alarms onto the backlog, in effect making security worse instead of improving it.

#5: Reliance on blocking instead of fixing

If you have a web application firewall (WAF), the standard way of dealing with a critical vulnerability is to temporarily block it on the firewall until a fix is ready. However, faced with too many exploitable vulnerabilities that they don’t have the resources to fix on time, companies can become overly reliant on their WAFs and start treating vulnerability blocking as a permanent rather than temporary solution. Every vulnerability that is patched on the firewall but not fixed in the application is another pebble added to your mountain of AppSec debt.

4 ways that AppSec debt hurts your organization

Like any other type of debt, AppSec debt usually creeps up on you slowly, with minor issues gradually adding up to an overwhelming backlog. In some cases, though, you can also wake up one day to discover you’re suddenly in debt and expected to deal with it, for example if web application security was never a priority for the organization – but now it is because you just had a breach. No matter how it arises, AppSec debt is always harmful in at least four crucial ways:

• Security risk: Putting off security improvements for later always increases risk. Whether it’s vulnerable components, application security defects, or assets waiting to be tested, as long as you are forced to choose what to secure, you are increasing the risk of cyberattacks with all their consequences.
• Financial drain: Dealing with a never-ending backlog is a case of running very fast just to stay in one place. Many organizations are caught in a vicious circle where they are pumping resources into security with no visible improvements – but also can’t afford to stop doing it. Unsurprisingly, many start seeing application security as all cost for no benefit, which makes it even harder to break out of the whole cycle.
• Frustration and burnout: Stuck in the middle of the AppSec debt dilemma are the security engineers, testers, and developers who actually work through the backlog. For security professionals in particular, unreliable results and tedious manual tasks that make very little difference to overall security are frustrating and can contribute to burnout.
• Obstacle to innovation: When you’re burdened by security debt, AppSec can seem like an anchor that is forever hindering innovation and sapping resources that could otherwise fuel growth. With that security backlog weighing on every decision, it’s no wonder that so many organizations see security as an obstacle to innovation.

How to break out of the AppSec debt spiral

The key to taking control of your vulnerability backlog is to fix real issues faster than they can come in. Sounds simple? That’s because it is – but only if you can make every step of the process accurate and efficient.

Focus on real issues

If you want to make headway, the “real issues” part is crucial to ensure that every single ticket your security professionals and developers work on leads to a measurable security improvement. This is where a modern application security testing solution such as Invicti with its Proof-Based Scanning technology can make all the difference by clearly indicating which vulnerabilities are exploitable and automatically confirming most of them. Actionable security tickets can go directly to the right developers via issue tracker integration and, once fixed, are automatically retested to make sure the vulnerability is gone. Just as importantly, each vulnerability report comes with remediation guidance and best-practice recommendations, so developers can not only fix the issue quickly and permanently but also learn to write more secure code. And that’s it – issue resolved, backlog reduced, fewer vulnerabilities coming in the future, and no resources wasted on false alarms or manual work that should have been automated.

Don’t let vulnerabilities pile up

To prevent AppSec debt from building up in the future, you need to make sure that application security testing is an integral part of the software development lifecycle (SDLC). That way, security defects can be found and addressed as a matter of course rather than thrown on the pile. Treating vulnerabilities like any other software bug is the whole idea behind extending security testing into the development process, often called shifting left. Once again, a modern DAST solution can be extremely effective here, allowing agile teams to find and address security issues without breaking step. By building dynamic security testing into the SDLC at multiple stages of the development process, you can maximize security while also catching vulnerabilities as early as possible for easier and cheaper remediation. That way, security stops being an anchor to innovation and becomes an integral part of application development. With the right approach, you can finally pay off your AppSec debt – and make sure it doesn’t come back.