The unfortunate reality for all of us is that bugs are simply part of the software lifecycle. Along with poorly coded software components, those bugs introduce vulnerabilities just waiting to be discovered and exploited. While steps can be taken to manage application security risk, they’re complicated and time-consuming.
A single static application security testing (SAST) report could identify hundreds—if not thousands—of instances for each vulnerability, but running SAST and dynamic application security testing (DAST) tools to identify all the vulnerabilities in given software takes much more time than organizations can afford to spend. Additionally, false positives are still a major problem that make the process difficult to manage since it requires manual filtering from experienced security and software engineers.
Even if organizations are willing to find and fix the vulnerabilities in their own code, applications can still be vulnerable since only 10% - 20% of the code that runs on the system is written by application developers.
The rest is code for all the underlying frameworks, libraries, transient dependencies, servers, services and even the runtime platform itself (JVM, .NET, etc.). Vulnerabilities do not exist only in the application code but also in any other component of the above-mentioned software layers.
The solution to fixing these vulnerabilities is usually a straightforward process. Simply patch the vulnerable component with a newer version. The reality is that this process can become very difficult to manage and scale because of the sheer volume of new software being released.
According to a recent study from Sonatype more than 10,000 new component versions are released daily, offering new features, bug fixes and security patches. It is evident that security and DevSecOps teams are overburdened and often cannot easily cope with the vast number of patches that need to be applied, especially in enterprise environments. It is not a surprise to learn that on average companies need three to four months to patch identified vulnerabilities.
To make things worse, patches might not even become available - ever. When a vulnerability exists in a third-party library, framework, middleware, or server you are at the mercy of the vendor. Vendors might not offer a patch. This could happen for many reasons. They may have stopped supporting older or legacy versions or because they might not accept the responsibility of the vulnerability.
To solve the growing problem of patching, both of the following are needed:
Active and accurate security controls that require minimum configuration able to completely remediate classes of common vulnerabilities (CWEs) or neutralizing attacks by mitigating known and zero-day exploits.
If such security controls are deployed in production, the urgency of immediate patching is removed and organizations no longer need to panic over every newly discovered vulnerability. However, no active security control can be deployed in production in unrestricted blocking mode if it generates false positives.
False positives are a major problem in production environments because they block legitimate requests. Stopping legitimate users from using the application is not an acceptable condition for most organizations.
In a traditional approach, reducing the number of false positives requires manual tuning and configuration from expert engineers. This manual process defeats the purpose of active and accurate security controls. Also, the security controls should not require extra configuration to be able to block zero-day exploits.
By moving the security controls from outside of the application to inside the runtime the visibility needed to eliminate all of these problems is gained. Self-protecting runtime platforms using virtualization techniques have complete visibility of all the code that is executed as well as its execution context, allowing a new category of techniques to be applied that do not depend on heuristic approaches.
Automated, agile and scalable patch deployment without breaking or restarting the application. Enterprises will keep lagging behind patches, struggling to cope with the ever-increasing quantity of released patches unless the entire process becomes more automated and flexible. Patch management and lifecycle software is a first good step that automates the notification of new vulnerabilities in software components, but these are applicable only before the software reaches the production environments.
Patching becomes more difficult in production because applying physical patches requires binary changes and even recompilation of the source code. Runtime protection solutions based on virtualization are able to apply virtual patches in an agile way without the need to recompile the application or restart the application or the platform. This greatly simplifies the process of patching, removes the urgency to prioritize the patching, and gives time to the DevSecOps and security teams to deploy the physical patch according to their own update schedules.
This also gives organizations the opportunity to cherry pick which patches are important to their environments, letting them roll back patches of specific CVEs that are not compatible with the existing application functionality.
The patching problem cannot be solved by throwing more and more engineers to manually patch and test the applications. Also, asking developers to remediate all vulnerabilities is a no-win proposition since a large number of these vulnerabilities are not located in the application code that they write and control.