AI changed the economics of attack. Free runtime security is how we change them back.
I've spent most of my career trying to find better answers to application security problems. Today, with CVE Shield, we're shipping one.
CVE Shield is free for everyone. It installs in seconds, runs inside your live applications, and shows you exploits against CVEs while you manage the patching process. The paid version blocks those exploits. For years, that dangerous exposure window between disclosure and patch was something we just had to live through. Now you can close it.
Most of AppSec has been built around accepting bad answers, wrapping processes around them, and then pretending the process solved the problem. We find something that might be vulnerable. We assign it a score. We open a ticket. We route it to a developer. We track it in a dashboard. We report it to leadership. We argue about severity, ownership, and exceptions. And then, somewhere inside all of that ceremony, we hope we made the application safer. Sometimes we did. Often we didn't.
When I look back over the last twenty years, what strikes me is how much of AppSec was built on conjecture. We guessed from source code. We guessed from dependency manifests. We guessed from package names and version numbers. We guessed from CVSS scores. We guessed from whether a vulnerable library appeared somewhere in a build, or whether a dangerous function appeared somewhere in the code. Some of those guesses were useful. Some were the best answers available at the time. But they were still guesses. That's always bothered me.
I've sat with security teams drowning in findings they didn't trust. I've sat with developers who were frustrated, not because they hated security, but because they were being asked to stop their real work and chase findings that often turned out to be inconsequential. I've sat with CISOs who knew their dashboards looked terrible and also knew that fixing everything on the dashboard was impossible, expensive, and probably not the best use of the company's time.
Over time, I came to understand that most organizations weren't being irrational. They were triaging chaos, not managing risk. The tools were noisy. Expert triage was expensive. Developers were already overloaded. Most theoretical vulnerabilities were never going to be exploited in that specific environment. So, companies did what rational companies do. They did enough AppSec to satisfy compliance, reduce the most obvious critical problems, and move on. Everything else went into the backlog.
That backlog wasn't a sign that everyone had failed. It was the compromise the industry knowingly settled on because there was no better answer. I've never been satisfied with that compromise.
After years of performing manual code review and penetration testing, I kept seeing the same pattern. No matter how careful the review or how thorough the test, we were still making educated guesses about what might be exploitable. We were missing the full context of what actually happened — how the application behaved when everything was assembled and running in production.
That changed how I thought about security. The only reliable way to identify real, exploitable vulnerabilities was to observe the running application itself. Everything else, whether static analysis, dependency scanning, or even expert review, lacked the context to be consistently useful.
I wanted to stop guessing from the outside and start observing from the inside. I wanted to see what applications and APIs actually do when they run. Which routes are exercised. Which libraries are loaded. Which code paths are reached. Which data flows are real. Which vulnerabilities are actually exploitable. Which attacks are actually happening. That was the original idea of runtime security, and I believe it's one of the most important advancements in application security.
The industry unfortunately took a detour. It fell in love with “shift left.” I understand why. The slogan sounds right. Find problems earlier. Fix them cheaper. Teach developers to write better code. Who could be against that?
But in practice, shift left went wrong. Not because developers shouldn't care about security. They absolutely should. Not because early testing is bad. It's useful. The problem is that we moved the burden left and left all the context behind. We took noisy, uncertain, low-context findings and dumped them into development workflows. We told developers to fix things because a scanner said so. We treated generic severity as if it represented business risk. We acted as if the earlier a finding appeared, the more valuable it was. That's backwards.
The result was gigantic backlogs of vulnerabilities and CVEs. Like a forest full of dead trees and underbrush, we accumulated risk faster than we could clear it. The left side of the SDLC doesn't magically create truth. Development environments don't know which code actually runs in production. They don't know which APIs are exposed to real users, which libraries are active, which vulnerabilities attackers are targeting, which applications connect to sensitive data, or which controls are already preventing exploitation. Only the running application in production knows.
That's the lesson I've learned again and again from helping real companies. The accuracy and context from the right side, from production, are exactly what you need to create urgency and trust on the left. Developers respond differently when security can say, “This code path is active in production, exposed to attackers, connected to sensitive data, and we just saw an exploit attempt.” That isn't a generic ticket, and it isn't FUD. It's a focus on real risk, backed by evidence. That's a reason to act, and it's the missing loop in AppSec.
We shouldn't be choosing between shift left and runtime security. Runtime evidence is what makes security in development work. The right tells the left what matters. Production tells development where to focus. Real attacks, real execution, real exposure, and real business context create the trust that generic scanners never could. And now, AI has made that feedback loop crucial and urgent.
Frontier AI models have changed the economics of application security almost overnight. There are three main drivers:
CISOs have noticed. Application and API security are no longer buried somewhere in the program review. They're at the top of the breach reports and at the top of this year's security initiatives, because everyone can see the same thing. The attacker's cost curve has changed, and defenders have to change with it.
A CVE is already a strange kind of security event. It's public. It's specific. It often affects software used by thousands of companies. It arrives with a name, a severity, a version range, and sometimes a proof of concept. Everyone knows what the issue is called, but almost no one knows, at first, whether it actually matters in their environment.
In the old world, that uncertainty was painful but survivable. There was usually time to inventory, triage, assign, patch, test, deploy and verify. That process was slow, but enterprises are complicated. Patching isn't a moral failing. It's operational work inside real software factories. But attackers don't have to patch. They only have to find one exposed path before you close it.
That's why the old CVE model is breaking. A spreadsheet and a ticket queue aren't enough when attackers are moving at AI speed. A generic CVSS score isn't enough. An SCA list isn't enough. A WAF rule guessing at payload patterns isn't enough. Organizations need to know, almost immediately, whether vulnerable code is actually running in production, whether it's exposed, whether anyone is attacking it, and whether exploitation can be prevented before patching happens.
Contrast Security CVE Shield is designed to get people started with runtime security in the most urgent and practical way possible, by protecting applications and APIs from exploitable CVEs in production.
CVE Shield isn't another perimeter device, eBPF kernel program, or CNAPP claiming they do application security. It's not another way to tell developers that a package somewhere in the dependency tree has a scary version number. CVE Shield monitors every CVE inside a running app or API so teams can understand their real status: Present. Active. Exposed. Targeted. Blocked.
Our key innovation is the microsandbox. Broad sandboxes sound powerful, but they're very hard to use in real production applications. If you try to define what an entire application, process, container, or library is allowed to do, you end up with enormous configuration and tuning problems. The policy becomes either too permissive to stop enough or too restrictive to trust in production. That's not what any team needs during a fast-moving CVE event.
CVE Shield takes the opposite approach. It creates a very narrow microsandbox around the exact method involved in a specific CVE. Within that scope, the behaviors an attacker needs to exploit it are blocked. That narrowness changes everything. We don't have to understand every capability the whole application needs. We only have to understand the dangerous capabilities an attacker needs to exploit a specific CVE. The application keeps working as before, and the exploit path is closed.
I want to be honest about what it took to get here, because this is the part I'm most proud of. A microsandbox is only useful if it stops the attack without getting in the way of legitimate behavior, and getting that boundary right is hard engineering, not a slogan.
We built thousands of test cases spanning real CVEs and real exploit variants, then ran them through automated test harnesses that exercise both the attack and the normal application behavior each method is supposed to allow. We used data science to learn what normal data and control flow look like at each dangerous method, so the microsandbox can tell an exploit apart from ordinary use. And we invested heavily in performance engineering, because a control that lives in production has to earn its place there. None of that work is glamorous, and none of it shows up in a slick demo. It's the difference between a control you can put in front of real traffic and one you can't.
You can install Contrast in seconds with a single command on your workloads, or use our Kubernetes operator to push it across an entire cluster.
Here is what you can expect shortly after installing:
CVE Shield also changes the patching conversation. Patches still matter. Secure code still matters. Building better software from the beginning still matters. I believe all of that as much as I ever have. But there has to be something between disclosure and patch completion. There has to be a compensating control during the window when attackers are moving, and the enterprise is still doing the careful work of testing and deployment. That's what CVE Shield provides. It's runtime security for the moment when runtime security matters most.
At runtime, Contrast CVE Shield detected multiple CVEs across apps, scored their severity, and is now blocking malicious function calls, without disrupting normal app behavior.
CVE Shield provides evidence where the CVE is present in your application.
And hey, if you like CVE Shield, there's a lot more to runtime security. This is just the start. The same runtime instrumentation can expose far more telemetry, and all of it flows into the Contrast Graph, a living picture of your apps, APIs, libraries, data flows and real attacks. You can use that graph to streamline your whole AppSec program, and it's the perfect substrate for the AI-powered security tools you'll want to build on top of it.
The Contrast Graph provides runtime intelligence that builds a unified, real-time security model for your entire application and API security ecosystem.
We're making CVE Shield free for anyone who wants to see which CVEs are actually present and active in their applications. Blocking will be available as part of the paid offering.
A lot of the best work I've been part of was about making security knowledge and capability freely accessible. I'm proud of what I did at OWASP, and proud that people are still using those projects almost 25 years later.
Give CVE Shield a try. Don't run applications or APIs in production without runtime protection. Use runtime evidence from production to build trust with your development teams. I've worked with many companies that used this approach to grow into a highly efficient and effective AppSec program.
That's where the next era of AppSec starts