This post was originally published here by MIKE MILNER.
Web applications are complex. Only a tiny part of any web app is code that you write for it. In fact, it is possible to create a web application without writing any original code. Some estimates say that 80% 
of the code in web applications is third party libraries and frameworks. This makes it easier to create a web application, but it means that you do not have any control over the majority of the code you are using. Nor how secure it is.
Consider left-pad. Eleven lines of code downloaded millions of times and used in web applications all around the world. In spring of 2016, the developer removed code he had uploaded on NPM, the primary source of code for node.js programmers. When it went offline, software that relied on that code stopped working. And because thousands of popular web applications relied on this little bit of code, they stopped working too.
Left-pad was replaced and is working again. It was removed originally because of a trademark dispute. But what if the intent had been malicious? What if the original code was replaced with a malicious package with the same name? How would that have impacted the thousands of web apps and popular websites that relied on this code? Steps are being taken to ensure that removal of a package cannot happen again, nor can a new package be uploaded with the same name.
But think about the significance of those eleven lines of code. What if, instead of being pulled from the library, that code had a vulnerability that could be exploited? A handful of lines of code that you really know nothing about, out of the millions in your web app, could put your entire system at risk.
It is possible to check for known vulnerabilities in third party libraries and frameworks. Using software component analysis, you can review all the libraries you are using and check for known vulnerabilities. If you find known issues, you can update that code to remove the vulnerability. For web applications using hundreds of libraries, which themselves rely on other libraries, this is an onerous task.
This is where runtime application self-protection (RASP) really earns its keep. This technology works across the full stack—code that you wrote, code others wrote, code that is part of the application framework itself. It protects any software in the runtime environment by detecting and blocking any anomalies. When you find a vulnerability in the code, you are protected while you are waiting to upgrade or writing and testing new code. So, no matter how complex your web application and its attendant libraries are, RASP is the security technology that protects from both the known and unknown risks. Learn more about protecting your apps with RASP; read the Real-Time Web Application Security whitepaper.
