Cybersecurity is a constant race between black hat hackers and cyber defenders. Both are frequently trying to identify vulnerabilities in applications. The defenders want to fix the bugs, while the hackers want to exploit them. Unfortunately, hackers often have the opportunity to exploit vulnerabilities before they are patched. While the manufacturer of the vulnerable software may be on the ball in issuing a patch for an identified vulnerability, organizations still need to apply that patch.

Rapid Exploit Development Makes Traditional Security Models Ineffective

The delays between patch availability and application leave organizations open to attack, and the sheer number of vulnerabilities in modern software means that the problem is unlikely to be fixed soon. A new solution to vulnerability management is needed, and a good option is runtime application self protection (RASP).


The Web Application Security Landscape

While all software may be targeted by attackers, web applications are probably the most common target. Web applications are publicly exposed yet act as the gateway to extremely sensitive and valuable data. Many web app code is the only thing standing between an attacker and an organization’s internal databases, so the effects of even a single coding error can be significant. As a result, hackers are willing to put a lot of work into trying to identify that one coding flaw. In general, the success rates of attacks against web applications can be as low as 1 in 100,000. Hackers need to put in a lot of work to find that big payoff.

However, these attacks can often be easily automated. Common security flaws like cross-site scripting (XSS) and SQL injection can be identified by simple scripts or commonly available tools. As a result, a hacker can use automation to pick out promising potential targets worth their personal attention.

Limits of Patching

Hackers often need to work very hard to find an exploitable vulnerability in a web application. However, most web applications are in fact vulnerable to some attack. In fact, 90% of web applications include a known CVE, which is a publicly known vulnerability. The challenge for hackers is identifying and exploiting this vulnerability before it can be found and patched by the organization’s cyber defenders.


Most organization’s cybersecurity practices are based upon applying patches for known vulnerabilities. Someone, whether an ethical hacker, black hat or internal developer at a company, identifies a vulnerability in the company’s software. When the company becomes aware of the vulnerability (either through a bug report or its active exploitation), they issue a patch to close the vulnerability, a process that usually takes 90 days or less. Once that patch is available, individuals and organizations apply the patch to their own systems, making it no longer exploitable by attackers.


The opening where vulnerability is usable to a hacker is the gap between its initial discovery and the application of a patch by an organization. Unfortunately, this window can often be fairly wide. If the vulnerability is ethically reported, the details of the bug aren’t made public until a patch is made available, so the delay is the time that it takes the organization to apply the patch. However, this delay is 38 days on average and can be much longer.

On the other hand, the average time between the public announcement of a vulnerability and an exploit is available on the Internet has dropped to about 14 days. This gives an attacker the better part of a month to scan for and exploit machines using a vulnerability whose patch is publicly available and just waiting to be applied. And this only counts the time after the exploit is publicly available, not when its developer might be privately using it themselves.


Runtime Application Self-Protection

The traditional method of managing vulnerabilities through patching isn’t working. This was demonstrated very clearly by the WannaCry outbreak, which took advantage of a vulnerability whose patch was available months before the ransomware worm was released. The sheer number of vulnerabilities that an organization needs to patch is overwhelming and growing constantly.

Security solutions like web application firewalls (WAFs) do a lot to help fix the problems with slow patch cycles. Typically, WAF developers are faster to release signatures for exploits, allowing them to identify and block potential attacks before they can reach vulnerable systems. However, even WAFs often need a signature to be available in order to accurately identify and block a new attack.

A new paradigm is needed for vulnerability management, and runtime application self-protection is a promising solution. Leading WAFs use anomaly detection to identify unusual traffic that may be intended to exploit an unknown vulnerability. However, WAFs are often used to protect the organization’s entire web presence, which limits the insight that they can achieve into any particular application.

RASP, on the other hand, provides personalized protection to an application. A RASP solution wraps around an application, monitoring its inputs, outputs, and behaviors for any anomalies. This tight integration provides the RASP system with the insight necessary to identify even novel attacks based on their impact on the application’s behavior.

The ability of RASP to protect against even zero-day attacks makes it a promising solution to the problem of vulnerability management. While fixing bugs in applications is probably still desirable in the long term, RASP can remove the urgency that organizations face regarding patch management and ensures that slow patch cycles do not leave an organization vulnerable to attack.