AppSec's Runtime Revolution

A look at the rise of Cloud Application Detection & Response (CADR) and one of the teams leading the transformation - Oligo Security

If you’re like me and have been spending a large part of your time in recent years in AppSec, you inevitably have been through various waves and trends. Arguably the most dominant was that of “shift left”, where we sought to bring security earlier in the SDLC, in order to catch vulnerabilities close to development where the theory is they are less costly and cumbersome to fix.

Those theories turned out to have some flaws, both conceptually, and in practice, which I have written about before but will summarize below as well.

As a result, we’ve seen the AppSec community evolve to place an emphasis on runtime visibility and context, not because we shouldn’t try and embed security early in the SDLC, but because at the end of the day, what matters is what is actually running in production, what is reachable/exploitable and ensuring teams have visibility of what is happening at the application layer in order to mitigate malicious activities when they occur.

I’ll be walking through why that is in this article and using one of the industry leaders in the space, Oligo Security, as an example of what right looks like and where the future of AppSec lies.

---

---

---

---

Challenges with Shift Left

I previously wrote a piece detailing the challenges with shift left titled “Shift Left is Starting to Rust”, aside from some of the practical challenges with how the industry has approached this trend, which I’ll discuss below, I also pointed out that the origins of the claim that it’s cheaper to fix vulnerabilities earlier in the SDLC may be outright false.

In fact, the Cybersecurity Infrastructure Security Agency (CISA) published a report where they demonstrated that the origins of the claim were never validated, but spread still like a fairy tale, passed down through the industry without any real data to support them, see below:

The lack of empirical data aside, the way the industry has “shifted left” in practice has also been problematic. This largely manifested in security using low fidelity tools (e.g. SAST, SCA etc.) which were full of false positives and/or didn’t account for criteria such as known exploitation, exploitability, reachability and compensating controls, leading to long spreadsheets of noise and toil which we then beat development peers over the head with, telling them these had to be fixed before they could go to production.

This all occurred while cybersecurity influencers took to the streets to claim cyber is a “business enabler” while concurrently erecting gates and imposing friction and blocking development from delivering value to production in the form of increased code velocity and product capabilities.

Not to pat myself and others on the back, but even Gartner came around to this reality (albeit a year+ after myself and others began pointing it out) in a research publication titled “Shift Security Down, Not Left to Scale DevSecOps”, where they stated the industry should:

“ Pivot away from shifting left approaches. Instead they should shift down AppSec and improve collaboration across teams.”

None of this is to say that it isn’t intuitive and common sense to try and address security and vulnerabilities earlier in the SDLC, and we’re even seeing teams trying to bring concepts such as Secure-by-Design from theory to reality, especially with the rise of AI and Agents, where it becomes practical.

That said, the reality at the end of the day is that vulnerabilities can and will make it through to runtime environments, either through implicit business risk acceptance and tradeoffs or due to constraints and competing priorities.

Shifting left is a methodology that when done properly can be helpful and is part of a broader defense in depth strategy we can and should employ in security, but runtime deserves some attention after years neglect. That said, it is still a point in time activity, accounting for a specific aspect of the SDLC, that doesn’t account for the dynamic and changing elements such as new and emerging CVEs, zero days or even unknown attack vectors.

While runtime may not have gotten the attention of the cyber ecosystem or leaders in recent years, it certainly has gotten the attention of attackers.

App Exploitation Trends

While application-level vulnerability exploitation is far from new, it has been seeing increased attention from malicious actors. This is validated from industry leading reports, such as Verizon’s 2025 DBIR, where they demonstrated exploitation of vulnerabilities is on the rise, surpassing phishing and even poised to potentially pass credential abuse, an attack vector that’s been dominant for several years.

Another major report, Mandiant’s M-Trends showed similar findings, and in fact has vulnerability exploitation being the most dominant initial attack vector, ahead of stolen credentials and email phishing.

So despite years of the industry “shifting left”, vulnerabilities continue to make it through to production environments, driven by factors such as improved vulnerability disclosure and reporting, which is good for transparency but ultimately does manifest in more issues that warrant investigation and potentially remediation. This includes challenges such as ineffective tooling that lacks context to drive effective prioritization, coupled with competing business priorities, developer frustration with security, and a lack of runtime tooling to provide comprehensive visibility to AppSec and SecOps alike.

Thankfully, that is changing, as we see the rise and growth of categories such as Application Detection & Response (ADR) or Cloud Application Detection and Response (CADR). I’ve previously written about why ADR is critical and what is driving the category’s growth in a piece titled “How ADR Addresses Gaps in the Detection and Response Landscape.”

In this piece, I’ll be going deeper into the topic, and also using Resilient Cyber’s partner Oligo Security as a great example of a team leading this transformation.

One of my favorite vulnerability researchers, Jerry Gamblin shared his recap of the 2025 CVE trends, demonstrating the 48k+ record setting growth, he closed his discussion with the statement:

“Prioritization is the only way to survive 2026”

In the video below from Oligo, they walk through the four key questions that are relevant related to vulnerabilities:

• Do we have it?

• Where in my environment is it?

• Are we effected by it and is it truly exploitable?

• What do we need to do to fix it or mitigate the likelihood?

Runtime Revolution

Aside from the problems with the industry’s implementation of “shift left” I discussed above, there are other factors leading to the rise of runtime security as well.

As organizations either miss potential vulnerabilities due to legacy static tools, or make implicit and/or explicit business decisions to allow vulnerabilities through pipelines to production, at the end of the day, organizations and the community at large have realized that we need runtime visibility and context. This means understanding what vulnerabilities are running in our production environments, and coupling it with vulnerability intelligence such as what is known to be exploited, likely to be exploited, reachable etc. as well as business-specific application context.

Furthermore, while scanning for CVEs is a tried and trusted practice, the reality is that the CVE ecosystem is problematic, from challenges with the NVD still having a massive backlog of unenriched CVEs due to a funding scare, as well as CVE data quality challenges. In Vulnerability Research Jerry Gamblin’s 2025 CVE report, he highlighted that only 57.6% of CVEs had a CPE identifier. As seen below, the CVE data quality actually dropped in 2025, across not just CPE, but also CVEs having associated CWEs and CVSS as well.

In fact, as of this date, the NIST NVD still has a backlog of thousands of CVE’s that haven’t been enriched, let alone widespread frustrations from the community regarding the completeness and quality of CVE data overall.

Oligo addresses this by looking at behavioral runtime context and highlighting vulnerable and malicious behavior that may not have a CVE identifier and may have not have been identified with static scanners.

Whether we use the stereotypical log4j, or the most recent scare with RCEs in React and Next.js, it is easy to see how deep runtime visibility and context is critical. While many teams may be left scrambling, trying to understand “where do we have vulnerable versions of X running”, teams with CADR solutions such as Oligo are able to quickly identify the exact systems, applications and workloads where they have vulnerable versions and functions running and implement real-time mitigations.

Something I also found particularly impactful from Oligo was their technique-based detections and protections, where they can identify any type of CVE, risks in first and third-party code, and sticking with the log4j example, they can identify the attempted abuse of a JNDI type attack and provide visibility for defenders or even block it, regardless of the attacks origination point.

For a practical example of CADR in action, you can check out the clip below:

Rather than taking a blunt instrument approach of impacting entire clusters, workloads and applications, which can lead to business disruption, Oligo allows teams to specifically target just the vulnerable function that is running, without disrupting the running application or business functions that it facilitates.

Yeah, but what about proprietary software?

Now, I’ve been around the space long enough to know this retort, and it’s fair. When it comes to supply chain security, we often over-prioritize open source, looking for log4j or the latest React/Next.js vulnerabilities running in our internal applications.

And it makes sense, given internal development efforts make extensive use of OSS. But guess what, so do third party commercial vendors who’s products and applications we’re running in our environments too.

These third party software vendors have historically been a black box, and while efforts such as SBOMs have been pursued, to try and get software transparency (hey, someone should write a book on that) from those external software vendors, the reality is that many vendors don’t have and/or provide SBOMs to customers. The SBOM ecosystem itself is saddled with challenges around SBOM quality data quality, consistent findings from SBOM tooling, ingestion and processing of SBOM artifacts and more.

What I found really incredible when working with the Oligo team to better understand their platform is that they’re able to provide runtime visibility into proprietary software calls and function use, not just internal software or applications.

This is a massive differentiator and helps CISOs and security teams understand the vulnerable functions and components in their third-party commercial software products as well, forcing honest conversations with their suppliers and allowing organizations to take protective measures to mitigate risks when their vendors can’t, or won’t.

eBPF Isn’t Always Equal

While eBPF in itself isn’t novel in the sense that many security vendors have begun integrating eBPF into their products and solutions, it is a core enabling technology for protecting environments at runtime. But like most things in security the how matters quite a bit.

At a high level, eBPF began to early adoption due to its ability to provide deep visibility at the kernel-to-user-space, not requiring code changes that teams find disruptive or problematic from a deployment perspective, making it incredibly simple to deploy in Kubernetes environments.

As we’ve seen the rise of containerization, microservices and Kubernetes-based workloads, eBPF became a perfect solution for security vendors to add to their offerings and for customers to get the sort of runtime visibility they needed for various security functions, such as SecOps.

syscalls are crucial as they provide an understanding of what is occurring between applications and the OS kernel, such as taking privileged actions, opening files, making network connections, creating processes and more.

For this reason, many have defaulted to using eBPF to primarily monitor syscalls, but they do so while also experiencing high false positives, negatives and lacking deep context when it comes to raw syscall logs. The lack of context is the very same problem that has plagued legacy static AppSec tools (e.g. SAST/SCA), which created some of the problems with “shift left” I discussed earlier.

Oligo instead uses “Deep Application Inspection” (DAI), which involves moving from raw syscall data from eBPF to deep behavioral narratives that couple low-level events and high-level app logic to bring the missing context that most generic eBPF implementations from security vendors miss.

Below is a great depiction of why that difference matters:

What About AI?

No modern conversation about AppSec would be complete without discussing AI. AI, LLMs and Agents have fundamentally transformed the software ecosystem in just a few short years. From widespread GenAI consumption, the rise of platforms such as HuggingFace and millions of potential open source models and tools, and developers making daily use of AI coding tools which has altered the future of the SDLC.

That said, and as OWASP AI Security Leader Rob van der Veer has said in my interview with him on Resilient Cyber titled “Navigating the AI Security Landscape”, at the end of the day, AI is still code and if you can see what is going on within the code, you can see what anything build on the code of doing, so the code execution visibility is still an incredibly power defensive capability.

That’s why I was pleased to see Oligo also launched runtime AI security capabilities, focusing on both AI Security Posture Management (AI-SPM) and AI Detection and Response (AI-DR).

If you’ve been around security long enough like I have, you know that most technology waves lead to security needing to cover two critical areas. That is the posture and hygiene of the technology, as well as the ability for organizations to detect and respond to incidents or malicious activities involving those technologies.

Oligo is coming at both concurrently with their launch of AI-SPM and AI-DR. Much like prior technological waves, coupled with security’s longstanding history of being a business blocker and the “office of no”, we’re seeing widespread shadow usage of AI as well, with security teams having poor visibility of what AI is being used within their organizations, let alone its posture or potential incidents.

Oligo brings its runtime depth and capabilities to bear on this problem space, helping teams understand not just what AI workloads are running in their environments, but what API calls are being made, what databases are being accessed, what cloud services are being consumed.

The way they approach AI security involves multiple areas:

• A comprehensive AI catalog, showing models, SDKs, agents and their associated security risks, as well as a real-time AI-BOM, a concept that has been championed by leading organizations such as OWASP in their AI-BOM project.

• AI-SPM, focused on reviewing and addressing risks in small and large language models, and in multiple deployment scenarios, such as self-hosted or externally consumed.

  

• The same function-level visibility of their flagship runtime platform, but with AI, helping you understand where first and third-party code involves the use of AI.

• Moving beyond posture to AI-DR as well, empowering organizations to address real-time risks in AI models and agents, whether that involves prompt injection, sys call deviations or potentially malicious tool calls.

  

As someone who has followed the rise of the AI security space closely, this is a unique and comprehensive approach covering the various areas of AI security, across models, agents, tools and more and multiple deployment scenarios that many vendors focusing on AI security lack.

For example, many vendors have begun to try and rollout inline or proxy type AI security tools, to monitor prompts and data flows, but without the deep runtime workload visibility context, it is easy to imagine how malicious activities could be overlooked with these generic proxy type tools.

Application Attack Matrix

As we have discussed above, application exploits have become one of the most dominant attack vectors for malicious actors, per authoritative sources such as DBIR and M-Trends among others. That said, modern applications can be complex, consisting of not just code but underlying cloud infrastructure, kubernetes/containers and microservices and robust API’s that traditional security frameworks and methodologies don’t align perfectly well to.

That’s why the team at Oligo produces the industry’s first comprehensive framework dubbed the “Application Attack Matrix”, leaning on the style of the popular MITRE ATT&CK Framework but focused on modern application environments and considerations.

As you can see, the framework covers the attack lifecycle, from pre-intrusion through impact and the associated activities such as recon, gaining access, expanding control and ultimately impacting organizations via interrupting services, exfiltrating data and other activities.

This comprehensive framework addresses modern application complexities including blindspots in supply chain and application and logic abuse challenges, the latter of which was specifically called out as a pervasive issue in the latest OWASP Top 10, which I covered in my article “X”.

The App Attack Matrix isn’t theoretical either, as the team at Oligo maps it to realworld incidents, such as the Bybit 1.5B Crypto Theft, where a vulnerable open-source library led to the largest known crypto heist ever. Many other examples as well, from SolarWinds, Log4shell and the more recent xz-utils backdoor.

The App Attack Matrix can be an actionable resource for various teams and stackholders across AppSec, CISO’s, Security Analysts and those in IR. It’s also a community-driven effort with an active Discord community and open to community contributions, similar to MITRE’s frameworks.

This is a great example of providing an industry-driven resource that is grounded in real world incidents and attacks and that Oligo’s leading CADR solution specifically addresses, making it not just another theoretical framework but one grounded in real-world incidents coupled with real-world capabilities.

Closing Thoughts

Oligo’s comprehensive CADR solution is a compelling capability at a time when application-level exploits are on the rise as a dominant attack vector impacting organizations. They bring deep runtime context to help teams prioritize effectively and are also covering emerging use cases such as AI Security Posture Management (AI-SPM) and Detection and Response (AIDR).

Their contribution of the Application Attack Matrix to the community demonstrates real-world incidents and TTPs and steps organizations can take to mitigate their risks.

As the level of application incidents rise, coupled with exponential year-over-year growth, organizations must focus on whats running and what truly matters from a risk management perspective.

It isn’t that we shouldn’t incorporate security into every phase of the SDLC, including “left”, but at the end of the day, what you’re running in production and what can be exploited by attackers is what matters most, and in a world of finite time, resources and attention, we need to allocate it accordingly.