Applications are where business happens these days, with enterprises increasingly deploying apps and services in the cloud to keep pace with the digital economy. However, current vulnerability management techniques don’t cover the technologies used in modern applications, which often leads to vulnerabilities going unnoticed and unpatched.

Applications have become the top cyberattack vector, surpassing email in 2021, and now account for about 70% of all security incidents, according to Verizon’s 2022 Data Breach Investigations Report. Yet AppSec vulnerabilities appear only sporadically on the top common vulnerability and exposure (CVE) lists. The reason is that AppSec vulnerabilities mostly result from issues that CVE lists don’t cover, such as misconfigurations, combinations of various tools, or developer mistakes.

When CVEs don’t cover the bases

The CVE list is a standardized catalog that identifies and defines vulnerabilities that could result in a denial of service (DoS) attack or even allow an attacker to gain access to a system. The CVE creates a specific record for each vulnerability discovered.

The problem, however, is that the vulnerabilities being generated in modern applications aren’t known. The fast development and deployment of DevOps, which keeps businesses and other organizations competitive in ever-changing cloud environments, requires security teams to rehtink how they detect these vulnerabilities, allocate resources and remediate risks. Discovering vulnerabilities before going into production can be a time-consuming process and often beyond the capacity of security teams. This is due to the complexity of modern applications; these systems consist of multiple components and services that interact with each other, making it challenging to identify vulnerabilities that may arise from the interaction of different parts. 

As a result, many of the vulnerabilities found in modern applications never show up on a CVE list. And without a catalog, prioritizing those vulnerabilities to identify the most serious potential threats becomes difficult, to say the least.

CVSS asn’t made for appsec

The established method for prioritizing vulnerabilities on a CVE list is the CVSS, which gives each vulnerability a score on a scale of one to 10, which reflects how easily a vulnerability can be exploited and how potentially damaging an exploit could be.

But as useful as CVSS has been for prioritizing coding errors in operating systems and other areas, it lacks the granular separation of attacks to be useful for application security.

Nevertheless, security teams that find themselves unable to keep up with a growing number of vulnerabilities have turned to CVSS for a lack of anything better. The teams do not have another rating system available. Because CVSS isn’t designed for application security, its rating system has resulted in inaccuracies. Teams have ended up spending a lot of time fixing vulnerabilities that posed little risk to the enterprise — while missing vulnerabilities that presented a high level of risk and should have been prioritized. Additionally, third-party libraries that could be part of an application's code may have vulnerabilities but lack an attack path. This can lead security teams to waste time attempting to fix them, as they aim for a state of zero vulnerabilities.

Patching doesn’t keep pace

Finding and prioritizing vulnerabilities can be difficult enough with AppSec, but the next step often leaves those weaknesses exposed. Even in cases where security flaws are considered severe, patching them can be a slow process. Trustwave’s 2021 Spiderlabs Telemetry Report, for example, found that half of exposed servers remained unpatched for weeks or months after an update had been released.

As with CVE and CVSS, accepted patching processes don’t really meet the requirements of AppSec. Under the Payment Card Industry Data Security Standard (PCI DSS), for example, an organization can take a month to patch a critical vulnerability and still be compliant. That large window can create enormous risks.

The old guard stands in the way

The vulnerability management sector is resistant to change, dominated by a handful of established players that have stuck with the same way of doing things rather than innovating. Likewise, standard ISMS frameworks have remained static, held back by the compliance sector’s own slow pace. Little has changed in the last decade, despite rapid transformation in application development and the threat landscape.

Security teams working with a standardized, widely accepted approach to vulnerability management have limited options and are not able to develop customized policies that fit their company’s business. Policy violations often equate to vulnerabilities, so, rather than reactively chasing down vulnerabilities after they’ve appeared, proactively resolving policy violations is a more effective approach.

Enterprises should shift left — and right

An approach that has become increasingly common to address AppSec concerns is shifting left. By building security into the development process from the start, DevSecOps teams can catch vulnerabilities early, testing for flaws and correcting them in the staging phase. Fixing those flaws before apps are put into production has proved beneficial and certainly is an improvement over traditional methods of building code and running it past the security team at the last minute.

However, shifting left is not a panacea. It doesn’t solve AppSec problems on its own because it can’t. Production environments are different from staging environments, and the fact is that not all vulnerabilities will be found during staging. Some vulnerabilities with the greatest risk may not show up until the applications get into production, so relying on shift left alone to catch all vulnerabilities is impractical and costly.

The alternative is to shift right. Continuously testing in the production environment, with real payloads — taking an attacker’s view — allows teams to find vulnerabilities quickly and identify which of them pose the greatest risk.

They just need to be sure not to fall back into old habits. Testing in the production environment traditionally has relied on vulnerability management and applying patches. But the overreliance on that approach and CVEs means it will miss most vulnerabilities that result from DevOps practices. Testing needs to be tailored to the environment.

Ideally, organizations should shift left and right, continuously testing in both the development and production environments. And they should do it without relying on outdated vulnerability management practices that aren’t made for DevOps.

Vulnerability management still has an important role, especially in ensuring that organizations meet compliance requirements. But relying on CVEs as guides to AppSec overlooks too many flaws and will leave organizations vulnerable. Continuous testing and remediation, both during development and in production, give organizations a much better chance of protecting the modern tech stack.