Testing Isn’t Enough: The Need for RASP

Many organizations are relying on legacy vulnerability management practices to protect their applications. In many cases, the belief is that white box testing, with its ability to scan an application’s source code for known vulnerabilities, is enough to ensure that production code is free of exploitable bugs.

However, vulnerability testing, whether white box, black box, or gray box, has its limitations. As a result, the average web application in production use contains a number of vulnerabilities that put the organization and its customers at risk. A new approach to vulnerability management, which augments vulnerability testing in development with real-time protection in production, is necessary to secure web applications against exploitation.

The Limitations of Vulnerability Testing

Website security is increasingly a priority for applications. In fact, many organizations are talking about transitioning from DevOps to DevSecOps practices. A crucial part of this process is integrating security testing into development practices. In theory, this integration would decrease the number of vulnerabilities in applications that reach production.

Despite these efforts to add testing to developers’ workflows, vulnerabilities are still slipping through the cracks. In fact, in 2019, the average web application in production use contained 22 vulnerabilities.

Not all of these missed vulnerabilities are caused by a failure to embed good security testing in an organization’s development processes. Traditional application security practices, including white box testing, have their limitations.

Software Complexity

One of the biggest contributors to missed vulnerabilities in web applications is the complexity of the application code. The average web application includes approximately 1,000 third-party libraries and dependencies. These dependencies pose a significant security risk to an application since it inherits the vulnerabilities of any functions that it imports from third-party libraries.

This use of third-party code becomes a serious problem if an organization is relying upon white box testing for vulnerability detection. In many cases, these tests are focused only on the code developed in-house, not the external libraries that the code depends upon. A vulnerability in third-party code may be invisible to the testing team but leave the application open to exploitation.

These third-party vulnerabilities can be addressed (to an extent) by applying all available security patches and updates for third-party code used within an application. However, the sheer number of external dependencies used by the average web application makes it unlikely that a development team has complete visibility into its applications’ dependency trees, let alone the patch status of each library.

Developer Knowledge

Exacerbating the challenges of vulnerability management in web applications is the fact that most developers do not receive specialized security training. In general, training for developers is focused on learning the languages, platforms, processes and tools needed to create the applications that their organization requires rather than how to secure these applications.

This lack of developer training makes it extremely difficult for developers to identify and correct vulnerabilities within the code that they create. If a developer is responsible for writing test cases, the only security test cases that exist are the ones that they know how to write or that are available by default in the organization’s application security tools (if any exist). As a result, the same types of vulnerabilities (cross-site scripting, buffer overflows, etc.) continue to appear in web applications, making them easy for cybercriminals to exploit.

Velocity of Code Updates

In the past, many organizations used legacy code development practices. Processes like Waterfall built applications as a single, monolithic program. As a result, these applications had long development timelines and were infrequently updated. Now organizations are adopting modern development processes, such as Agile, Scrum, and DevOps. Under these processes, code is modularized, enabling pieces to be developed and updated more quickly. Some organizations that have adopted DevOps create new releases on a daily basis or even more quickly.

These rapid development cycles make it necessary to accelerate the pace of security testing as well. If an organization does not have mature DevSecOps practices in place, with robust and automated application security testing, it may be impossible to perform comprehensive security testing within these accelerated software release cycles. In most cases, when security and release dates are in conflict, it isn’t the release deadline that the development team sacrifices.

Managing Vulnerabilities in Production

Despite the best of intentions, most organizations are not prepared to embrace DevSecOps practices. These practices require integration and automation of robust application security testing into a development team’s continuous integration and testing workflow.

As a result, production code will contain vulnerabilities. Attempting to manage these vulnerabilities through legacy practices, such as manual patch creation and application, is an unscalable approach to security. Organizations are relying on ever-increasing numbers of applications – containing growing dependency lists – making it far too easy to overlook a critical vulnerability or update.

While attempting to correct vulnerabilities in development is important, organizations must also accept and prepare for the fact that production code will contain exploitable vulnerabilities. Runtime application self-protection (RASP) helps to address these issues by integrating security monitoring into a potentially vulnerable application.

If the inputs, outputs, or behavior of the application becomes anomalous, the RASP solution can take action to alert the security team of a potential attack or to block it altogether. This ability to perform “virtual patching” of an application based upon deep insight into its inner workings enables it to protect an application against exploitation of the vulnerabilities missed during testing.