Application Security Should be Revamped 

Application Security is at the stage of evolution when its traditional technologies have reached their limits. They have successfully fulfilled their duties, served the purpose and expectations, enabled more secure application ecosystem than before, and yet…Today’s Application Security lacks technologies, features, and capabilities that should make it serve modern demands. 

Application security was founded approximately twenty years ago, when the DevSecOps paradigm of the seamless integration of security technologies and processes into application development and operation has not been yet introduced, when open-source components have not yet constituted up to 90% of a typical application. At that time, absent or under-developed where such concepts as cloud-native applications and distributed applications, and the use of microservices and APIs was not massive. Moreover, it was an era when hackers’ attacks were not as relentless and globally spread as they are today; when hackers were just individuals, not organized criminal groups or government-sponsored cyberwarfare troops. 

The new era, where we live now, demands from Application Security new technologies, features and capabilities. Therefore, let us assess Application Security readiness to address modern concepts and demands. Let us review the existing Application Security portfolio, evaluate its strengths and challenges, find out what is missing, and envision the next stage of its evolution. 

The First Phase of Application Security Evolution 

Per Gartner, since its inception in early 2000s, Application Security has been growing from zero to an impressive $9.3B in 2024 and estimated $16.5B in 2027. This market’s growth rate exceeds 22 percent. It is by far higher than the rate of 8 to 12 to 14 percent of the markets such as IAM, Network Security, Integrated Risk, Data Security, and Infrastructure Protection. 

Let us review the prominent technologies that made Application Security a mandatory discipline to the customers and the champion of growth.  

Static application security testing (SAST):  

SAST analyzes applications’ code for security vulnerabilities such as SQL Injection, Cross-Site Scripting, Cross-Site Request Forgery, etc. 

Strengths: 

• SAST detects vulnerabilities early in the lifecycle. It enables remediation earlier and inexpensively 

Challenges:

• SAST is testing not a real, running application, but just application’s code. It is not a runtime technology. It detects (actually, suspects) vulnerabilities in the code that has not in a running state yet. Thus, it is broadly open to false positives 

Dynamic application security testing (DAST):  

DAST analyzes a running application by launching simulated attacks, watching application response to the attacks, and thus concluding whether those attacks were successful. 

Strengths: 

• DAST is a runtime technology that watches application behavior under the attack during application’s execution at the test phase of the lifecycle. 

Challenges: 

• It is a “black-box” technology. Even if it senses a vulnerability, it does not have insight into application code, composition and architecture. Therefore, it has a limited ability to point to the origin of the vulnerability. 

Software composition analysis (SCA):

SCA detects malicious open-source software (OSS) components with security vulnerabilities, OSS components with legal issues (e.g., improperly licensed components), and OSS components with DevOps issues (e.g., outdated components). 

Strengths: 

• SCA inventories OSS components, identifies OSS that pose risk, enables to manage security of the software supply chain.  

Challenges: 

• SCA is not a testing technology, but an inventorying technology. Unlike SAST and DAST, it does not analyze the application, but compares application’s components against some known inventory of malicious components (e.g. National Vulnerability Database (NVD)). SCA detects only known vulnerabilities listed in such an inventory. It lacks the ability to discover OSS that has not been inventoried yet, e.g., it cannot point to zero-day attacks.  

• SCA is not a runtime technology, it does not see OSS components at the application execution, cannot alert users of the malicious OSS being executed, cannot stop execution of the malicious OSS components.  

Web application and API protection (WAAP):  

It is a collection/integration of technologies that mitigate attacks against applications. It typically includes such features as web application firewall, bot management, denial of service, and API security. 

Strengths: 

• WAAP is a runtime technology. It watches applications’ data exchange at operation phase – the phase that is not addressed by SAST, DAST, and SCA. 

Challenges: 

• WAAP is a traffic parser/analyzer. It does not have insight into application’s code, components, architecture. It watches the outcome of the application processes: the traffic caused by the application’s processes, not the source of those processes within the application or across application/API ecosystem. It lacks accuracy of API detection.  

Challenges that Traditional Application Security Faces 

Lack of Insight into a “Real” Application 

Technologies such as SAST and SCA analyze/observe not a “real” application at the running/operation mode. Instead, they analyze application’s code and/or component composition. This is the most serious gap in their abilities, which they are unable to compensate for. 

DAST does watch application in the running/operation mode, but it has no/minimal insight into application’s code, architecture, and composition. 

WAAP is a runtime technology, but like DAST, it does not have insight into application code, architecture, and composition. 

Lack of Observability  

Lack of observability for SAST and SCA stems out of their inability to get insight into a running, operational application. Lack of observability for DAST is a result of its “black-box” nature. WAAP lacks observability due to its nature of being a traffic analyzer, not an application-process analyzer. 

Intermittent Nature of Technologies

Nowadays, characterized by the globally-spread, relentless attacks, applications must be under continuous, always-active monitoring and protection. Unfortunately, technologies such as SAST, DAST and SCA are scanners, intermittent by their nature. Scan runs for some minutes or hours and then it stops. The next scan might not (and, typically, does not) run for many hours, days, weeks and even months. In-between scans, the application remains unwatched, unobserved, and unprotected.  

On the contrary, WAAP is a monitor, not a scanner. It continuously monitors application traffic. Yet, as we have pointed out, WAAP lacks critically needed observability into applications and APIs.   

Limited Coverage of DevOps Lifecycle 

None of the technologies covers the entire DevOps lifecycle: from left to right, from programming to budling/testing and to operation. SAST, DAST and SCA mainly work at Build/Test phase, and somewhat at Programming phase, but not at Operation phase. WAAP – at Operation phase, but not at Programming and Build/Test phases. Therefore, at each of the phases, DevSecOps specialists must deal with a variety of technologies: learning them, running them, and taking responsibility for their results – a job, at which they are not terribly successful. At some DevOps phases, they are not equipped with those technologies at all or not sufficiently-enough. 

Too Complex to Use 

Application Security industry was successful-enough to make SAST and SCA user-friendly, so they could be given into hands of developers and security specialists. 

DAST was not that successful. It requires the amount and level of skills which exceed developers’ capabilities and resources. Configuring DAST and tuning it up, ensuring authentication and proper crawling and coverage is not a sustainable task for them. WAAP is so complex for developers, that nobody would even think of integrating it into CI/CD technologies and processes. 

Those deficiencies of the existing Application Security result in the fact that DevSecOps lacks comprehensive insight into the way that applications and APIs are built and secured. Existing Application Security has severely limited insight into a “real” application/API architecture, into the logic-, vulnerability-, and threat-processes and flows. Developers and security specialists cannot observe what they are building and securing. No surprise, they are not successful-enough in Dev, Sec, and Ops. 

Attempts to Mitigate Application Security Challenges 

We cannot say that Application Security industry has not worked on addressing its challenges. Two solutions have been invented and productized: Interactive Application Secuirty Testing (IAST) and Runtime Application Self-Protection (RASP). Both technologies are siblings with similar architecture and features.   

IAST has an agent instrumented into a runtime engine, such as a language-virtual-machine (e.g., JVM). It also has an inducer that executes an application at test runtime. That inducer could be a DAST technology that launces attacks against a tested application (so-called Active IAST) or an inducer could be a QA test: script or manual test (so-called Passive IAST).  

IAST is a result of an interaction between an inducer and an agent (thus, the name Interactive: IAST). Inducer makes tested application run, while an agent closely and deeply observes processes within the running tested application, enabling detection of security vulnerabilities. IAST offers a combination and interaction of DAST and SAST features: it enables testing at application runtime (like DAST does) and can point to the origin of the vulnerability (like SAST does): yet another reason for naming it Interactive. 

RASP is very similar to IAST, yet with some important differences. Unlike IAST: 

• It runs at Operation phase
• It runs on a production (not on a test) server
• It does not need DAST or QA inducers. Its inducer is a real attack against a production application
• It can protect application by blocking attacks (a feature often called: “virtual patching”), e.g. by stopping application execution right before it is about to follow a malicious flow imposed by a hacker)

IAST and RASP strengths were obvious and groundbreaking. Yet, IAST and RASP adoption has been low and slow due to their challenges, listed below: 

Stability concerns about the agent instrumentation into a runtime engine 

Users get worried about a possible agent failure (especially for RASP, at operation phase), which might cause a failure of an application itself. This is the greatest challenge that agent-based technology faces. 

Proprietary provenance of an agent 

Stability concerns were exacerbated by the fact that agents were productized by startup vendors and not endorsed by the prominent, globally-recognized vendors of runtime engines (such as vendors of operating systems, virtual machines and other runtime platforms). This is another main challenge of IAST and RASP. 

Language-dependence 

IAST and RASP agents are language-dependent, which means that one agent should be developed for Java, another one for C#, yet another one for PHP, etc. Dependence on a large variety of languages makes it somewhat difficult to develop and maintain those two products. To be fair, the resolution of that challenge is more of an issue of resources that IAST/RASP vendors could dedicate to the problem resolution. 

CPU impact 

IAST ad RASP run on the same server as an application itself, consuming some CPU cycles. To be fair, that is the challenge that is reasonably easy to solve. 

As we pointed out, those challenges substantially lowered and slowed down the adoption of IAST and RASP. And yet, a mere emergence of those technologies has been pointing out to a tremendous value that runtime observability solutions with deep insight into application/API processes could have on the advancement of Application Security, on the advancing it to a stage, which cannot be addressed by the first phase of Application Security, by the traditional SAST, DAST, SCA, and WAAP. 

New Opportunities in AppSec

Over the last several years, a new technology has emerged. A technology with the potential to solve some problems that IAST and RASP have not been able to solve. This technology (or rather a feature of Linux Operation System’s (OS)) is called eBPF.  

Practically, it is a programmable interface into Linux OS (and lately, into MSFT Windows OS as well). It enables programming some new, additional functionality with deep observability into application and API processes during application test and production runtime. eBPF provides a way to ensure safety and stability of the OS kernel when in operates with those additional, user-developed functions. eBPF is supported by the Linux OS consortium: the fact that almost/fully eliminates concerns about agents’ proprietary nature. eBPF, unlike IAST and RASP, is not a proprietary feature/technology, but a standardized way to extend the OS, with standardization offered and endorsed by the OS Linux consortium. That standardization and endorsement by the world’s most popular/used/deployed OSs, combined with the ability to ensure safety and stability of the OS kernel, addresses and (almost?) takes away two main challenges that IAST and RASP have been facing and not being able to overcome.  

Surely, eBPF-lead approach is not entirely rosy. It is still to be demonstrated that it offers sufficient-enough observability, which satisfies demands from DevSecOps. Nevertheless, the promise is encouraging. 

We can conclude that the first phase of application security has reached its limits. New concepts, such as cloud-native applications, distributed applications, containers, massive use of APIs demand new solutions, which traditional approaches have proven unable to provide. All signs indicate that the next phase of appsec solutions should and will be able to offer runtime observability, deep into application and API processes, provide insight into architecture, logic-, vulnerability-, and threat-flows in real-rime and across the entire DevSecOps workflow. This is the space where innovation should and will be focused over the coming months and years.