Name: Zero Exposure by Design: Stopping Vulnerabilities Before Code Ships
Uploaded: 2026-09-29T15:30:29.003Z
Duration: 25 min 44 s
Description: Zero Exposure by Design: Stopping Vulnerabilities Before Code Ships

Transcript for "Zero Exposure by Design: Stopping Vulnerabilities Before Code Ships": Well, good morning. Good afternoon, wherever you're joining us from, welcome to this webinar where we'll be covering zero exposure by design and try to stop vulnerabilities before your code ships. My name is Marcin Charlom. Over the next thirty minutes, we're going to talk about this team. And if you want to summarize it in two sentences, here's the short version. The speed at which your teams is shipping code has changed and it has changed permanently. The tooling you use to secure that code has not in many cases. Let me put a number to that. AI generated code generates 75% more vulnerabilities than the traditionally written code. Many of those vulnerabilities show up in forms that the older scanners were never designed to catch. So on one hand, you have the volume going up and detection quality going down at exactly the same time. So for a decade, our answer has been to shift to left, pushing security earlier, catching the problems sooner. And it was the right instinct. It's just that today, it's no longer enough. When code is writing itself, when attackers are automating, catching problems is still catching problems. The real goal is to shift to zero. Exposure that never enters the pipeline in the first place, And when it does enter the pipeline or when it does enter into production, we fix it before it becomes an issue. Now to unpack all of that today, I'm joined by Yoav Nathaniel. Yoav, how are you? I'm good. Thank you for having me. No. Welcome to the webinar. Just as a quick introduction because many people know you already, but maybe not everyone on the audience today. So can you, give us a bit of background on your role within Armis from ServiceNow? Sure. Yeah. So I joined Armis, about two and a half years ago. I was the CEO of the company called Silk Security that Armis acquired, which is now known as the viper product. And, nowadays, I lead a lot of strategic initiatives, and incubation, within, Armis by ServiceNow. So a lot of the new product lines, that we have, such as the AppSec product, are, managed by me. And, very exciting, time to be in cybersecurity. I'll say that with everything that's changing. Yeah. Couldn't agree more. And I'm glad we have this thirty minutes together to really go a bit more deep dive on application security. Just to guide our conversation a bit, we'll we'll discuss what is what we could consider to be the industry problem. We won't go, in too much detail on all of these frontier models, but it's important to ask a question and and to kind of, understand what changes, what didn't change, how we can potentially use that to our advantage as well. And I would also like our audience to walk away today with an idea of what good looks like. Good looks like potentially our misapplication security, hopefully. But we'll be covering some of the new, product capabilities that were recently introduced. That's definitely something I would like to cover you as well today, Ivan. But, starting with a few, logistics, this will be more of a conversation. We're not gonna send you 50 slides today. If you have any questions, feel free, feel free to use the q and a functionality. We'll try to do our best to answer them as we go through this session. If not, we'll come back to you, offline. So, hey, Joao. Ready for the first topic? Of course. Born ready. Cool. Let's start with the industry problem. And I like the fact that you I mean, you're so busy. We know you're you're super busy, but you're in front of customers, prospects also almost on a daily basis. So you talk to these application security teams every week. What is it that has changed for them, say, in the last eighteen months? I think the biggest change, that security teams, especially application security teams, have encountered, in the past eighteen months, maybe a little bit longer, is, the change of pace speed. So both attackers are now moving faster, and also defenders can do a lot more things on their own. They can move faster, and the bar has been raised on them, because attackers can move faster. So a lot of the operations and the status quos of how, security teams worked and for the last twenty years is no longer relevant because it's not matching the speed of the attackers. And so defenders have to rethink a lot of the way they do things. So there's a big disconnect between today, maybe the speed of the attackers versus the speed of the defenders. So we'll we'll come to that later as potentially how we can use that to our advantage as well. Speed is the word that I heard here. And our answer to this speed for a decade has been, you need to shift left like you need to go as left as possible. Why is that running out of road? Shift left was a very ambitious initiative in the industry where we tried to, get ahead of these problems before they go into production. But in reality, a lot of state a lot of vulnerabilities still slip through the cracks, and it created a lot of friction with developers when you come to them right before a production release. And this brings us to, the modern day where we're actually shifting zero instead of shifting left. Where instead of trying to fix things before they fully go out, we're fixing them at the source. So as vulnerabilities get created, we have, preventative and self healing workflows, that actually eliminate the vulnerabilities, either before they're created or within seconds, automatically. And, that's, allowing organizations to move much more smoothly at a at a much faster pace than ever before. Yeah. And if we like to visualize this, this is what it looks like. My shifting left is already earlier, but the risk kind of has already multiplied at that stage. So shifting zero has the ambition to eliminate exposures before it exists. And I think with application security, it's really easy to conceive as a as a as a as a foundational operating model because there's that stage where the application has not shipped yet. They're still in development phase, and this is our unique opportunity in application security to kind of eliminate those exposures before they even exist. We'll cover a few examples later during the webinar, but I thought this visual kind of, paints and I picks paints and I picture nice picture to show the difference between shifting left and shifting zero. There's another topic that I hear all the time, which is this infamous backlog. I'm I'm not gonna throw any numbers here, but, like, sometimes it goes into the hundreds of thousands of items that are still waiting to be three hours where there's no context available. Where does that really come from? Like, is it still a thing today? Is it the volume that is a problem? Or is it just because nobody can tell which findings really matter? We've been in the business of managing backlogs for many, many years. It's on a good day, it's hundreds of thousands, but on a regular day, it's typically millions of vulnerabilities in the backlog for a very large organization. A lot of it stems from, a lot of noisy detections that organizations have. A lot of, slower mediation processes that can't keep up. And right in between, those two is, the ability to actually distill what's important. Organizations are still having trouble, contextualizing everything that they're finding and putting all the puzzle pieces together to understand, attack paths and kill chains. And, it's really a a big data problem and the and the process problem for a lot of organization. And if they can solve that and they can also upgrade the way that they do things, then, ideally, they get to little to no backlog. I think, in a futuristic world, the backlog is really comprised of the things that really require human attention as opposed to all the low severity issues that nobody ever gets to fix. Got it. We we we should have the ambition as an industry to move away from managing a permanent backlog to clearing that backlog or really limiting to those things that require human intervention. I like that as an ambition. There's also gap while while we are still, like, describing the industry problem. One problem that came to my attention is probably also because of the speed that you just described is that there's kind of a window of opportunity, I would say, for the bad guys where, you you you can maybe walk us through that window where a malicious package is being published. It takes some time before that malicious package would show up in those public CVE feeds. Can can you unpack that a bit as well? Yeah. I mean, even in 2026, we've seen a bunch of examples, especially in the first half of the year. Imagine that you have a popular package that is used by millions of people every single day. It gets downloaded millions of times for all sorts of automated use cases, developers building all sorts of things. And, someone hijacks that, package, and, now starts distributing, like, a new version of that package, with either a vulnerability or an exploit that might not even exist directly in the package. It could be in the post installation script. But even if they post, a new vulnerability, typically takes anywhere from five days to a few weeks for a new CVE to get, verified, to get published, and then all the sources to actually disseminate and and, collect that vulnerability and detect on it. So the cycle itself is too slow. And if there's no CVE or a new vulnerability and just an exploitation, it's going to, eventually never get published in the first place. And so there's this phenomenon, call it, that the market has a way of clearing a lot of these hijacking, exploits, unpublished vulnerabilities, by itself. It has corrective mechanisms. So, if a new, highly exploitable package version is is being published, typically, it take gets taken offline within three days. People start noticing and they take action even if there's no, published CV. And so, with supply chain protection, you can, create a window of, call it, seven days or two weeks, which is like a buffer. So you don't wanna use anything that hasn't been properly vetted by the market. You wanna give every package the opportunity to get vetted before you ever, start using it. And if it hasn't had that time, to vet, then we should consider it untrusted. It sounds too. Okay. Implementing that buffer can have a huge, difference in in terms of how many malicious packages or packages are being introduced. Thank you for clarifying that. So just for an additional point, if you look at, like, the trivia attack or the Axios attack or Shihullu mini two, if you had that buffer, go to the seven day buffer for new packages, you wouldn't have been affected by them at all. They were taken offline within twenty four to seventy two hours, and anybody that didn't have that buffer and was using them, got infected. Yeah. Sounds like a no brainer. And and it's the functionality that we kind of added in our latest AppSec release. We'll cover some of these, and what good looks like, but thank you for already unpacking that. Before we go there, there's there's one thing. I wouldn't call it the elephant in the room. Everybody talks about it, but we have to talk about these Frontier models and what is their their impact because, obviously, they crossed the line in the last year. They can read a code base. They can identify vulnerabilities like we've never seen before. In some cases, they can even write working exploit code. So what does this all mean, like, from your expertise? What does this all mean for the people that are defending the code? I mean, at the end of the day, I mean, there's there's two parts to this question. One, it's you have a lot of Frontier models that are highly capable, a lot of, really good harnesses also for, call it, exploitations, that attackers can leverage. But it's not limited to just Frontier models. Also, we're seeing that, small language models, are, highly capable today as well with the right harness. So it's it's not limited to just that. But, just like attackers can benefit from the exploitation capabilities of these frontier models, their ability to generate exploits and chain them together, defenders can do the same. So suddenly, it gives you the opportunity to call it simulate, what an attack looks like against your environment at your own time. So you then have to do it when an attacker comes and attacks. So you can do it way before that to better prepare for, the new wave of attacks that's that's already coming, using, all sorts of agents. I like that. So we can actually use that to our advantage to build a better knowledge and kind of simulate potentially, attacks within our environment. That's that's the one thing that we have as an advantage, over the bad guys is that we can learn, our environment, that we can simulate all these potential, entry points and and and attacks. So it's not all doom and gloom with the Frontier models. We can use them to our advantage as well. No. Absolutely. And it's even the ones that are coming at you, there's ways to defend against them in an agentic manner. So, we're seeing, of lot cyber security, adapt to the new way of, security operations and attack operations, including, immediate response, call it, to these attacks. Because the way that you'd neutralize a human attacker is different than how you'd neutralize, an agent attacker. So as we look to what good looks like today, we'll we'll, cover these four, enhancements that we recently lost on the application security, solution. The first one is I like the fact that instead of just blindly scanning application, we have this notion of providing you with detection that understands the application. Can can you clarify that a bit first? Yeah. Rather than doing what a lot of traditional scanners have done, which is, trying to scan the code and then trying to add, all sorts of additional context like call paths and reachability, we flip it on its head. Because many times you're scanning irrelevant code and, you're trying to now, populate all the context after the fact. We want to start with context from the get go. So every time we scan an application, before we even do any real scanning, we generate a threat model to understand what that application is, how does it work, what, controls does it have, what control gaps does it have, how are things being implemented. And so that allows us to create much more targeted scans because suddenly a web app is gonna be scanned differently than a mobile app, for example, versus a script or a CLI tool, because they have different entry points. And so, truly understanding how the application works, what are the sensitive components, and why was it built to, do what it does, I think knowing that ahead of time allows you to, avoid dead codes and focus on much more meaningful stuff. Is it fair to say that this would be more cost efficient and resource efficient as well, having all that context? Not necessarily. Depends on how you implement it. And, generally, I think there's more complexity that gets associated with it, but you can also get much more meaningful results. Because imagine that you're if you're scanning blindly, then, you're just looking at every snippet of code and trying to see if it's vulnerable and then trying to see after the fact if if it's worthy of your time. Now you're focusing on, like, only reachable, attack paths, call it, that's, you go through multiple layers of validation of that call path, to see, how is that code getting sanitized? How is it, like, getting triggered? What configurations do we need to be aware of that actually trigger this vulnerability? So what's the wrong combo of toggles that actually activate this? So it allows you to get much more specific. Yeah. And the quality of the output is just much higher with all the context. Get it. The second item is something that I think we already covered. So, like, in in a nutshell, we talked about supply chain enforcement. That was the part that we we can enforce before that CVE exists in a feed. Is there anything you like to add there, or you think we covered that sufficiently? I I see a lot of different use cases of how organizations are trying to enforce supply chain, whether they're trying to create a buffer window or they're trying to force people into their private artifacts storage, where they have more control over what artifacts are there. But then it's it's still a challenge to force people to actually use it. And, all the way to understanding if a specific vulnerability is even being triggered in their supply chain. So if you're calling a third party library and understanding if, the if you're actually activating, the the the vulnerable functions within it, within that library or sub dependencies. But, we've seen that it's been being widely adopted, the supply chain protection that we have. And, it offers so many benefits, seamlessly to developers, preventing them and their CICD pipelines from getting exploited. Yeah. This is the the perfect definition of shifting to zero. It's eliminating those exposures before they come a problem. Okay. But moving on to runtime prove instead of static suspicion, I guess this is where developers want to see confirmed problems instead of just suspicion. Right? Yeah. We, as I mentioned, the bar has been raised, and we're seeing it become more commonplace for organizations to think this way, which is great. It's not just about detecting. It's also about proper validation. Validation used to be, very manual. And nowadays, it can be very sophisticated and very automated. So suddenly, it becomes this pipeline where you can see how you're, detecting, vulnerabilities really well, be able to validate them using all sorts of, mechanisms, including a DAST, for example, that we have, and then also, remediating them. But, very strong validation that's very contextualized to the environment allows us to go after more confirmed kills rather than, mere suspicions that there's a vulnerability here. Yeah. And this is a brand new functionality that we added. So if anybody on this call is is an Army's AppSec customer, we have some early access programs that they can definitely subscribe to. So if you would like to do so, please leave us a message in the chat, and we'll definitely come back to you. And then last but not least, you have fixes that fit the organization. It sounds, simple, but I I remember from the old days where the ticket would would just, include some generic recommendation in terms of remediation, have to update to whatever version might be applicable. This is kind of the complete opposite. Like, this is really tailored to how an organization works with the best fix that we could potentially suggest, like, a senior engineer. Is that what it is? Pretty much. So we worked really hard to craft, what we call the ideal fix. Anybody can just generate a fix or can propose something or potentially verify if it would be a valid fix that could work. But if you're a bank or a a defense company or a a health care company or a tech company, You have your own way of doing things. And how do we come up with a fix that not only actually fixes the issue and doesn't introduce new issues and doesn't break the code, but also conforms to how your organization operates. And so by studying your coding patterns, taking your best practice standards, threat models, architectures, organizational policies, it allows us to craft not just a verified fix that you'd want to use, but also a knowledge driven fix, that really is tailored to your organization. And just like Maxine mentioned, the goal is to be able to fix, like, a senior security architect within that organization. And so that allows you to fix much faster and much more confidently. I like how we, we we've always been around context and use utilizing all of that context when it comes to, let's say, the ingestion and the prioritization of of all these findings. You're using the context of the enterprise now or whatever the organization might be to actually generate fixes that are tailored to their environment, like the the knowledge driven remediation, as you call it, is really a revolution. So it's really cool to hear. And by the way, if if we were to to summarize this in terms of how our product looks like, if you've been familiar with Armies application security, all of these new functionalities, are being released or are already released. So it kind of complements an already compelling Armies application security suite. Yoav, thank you so much. I would like to, leave a last word with you. Kind of consider this to be your forward look forward looking statement. So if, application security goes into a certain direction the next twelve months, what what would you see happening in the market? I mean, from everything that I'm seeing and of the trajectory is going is that I think, code is gonna come out much cleaner and backlogs are gonna get, cleaned up, because of a lot of autonomous capabilities, that are coming out and how, the world of, application development, call it, and security are converging. So you're gonna get embedded controls much more easily into the process. And I think, that's gonna lead to a much safer future. We still have to deal with a lot of the legacy applications that, move a little bit slower. But I'm very confident about where application security is gonna go, just because of the new capabilities and the new possibilities that people are adopting already. And we're just gonna see a faster pace of adoption over the next eighteen months. Cool. And nobody can be against a safer future, so thank you for sharing that, Yolaf. If there's one thing, our audience would take away from this session, I would consider this to be the following. Finding vulnerabilities is no longer the hard part. There's Frontier models enough that you can help you there. It's no longer where your advantage would come from. So your advantage is from knowing which vulnerabilities actually matter, knowing your environment like the bad guys can never know, and from fixing them before they become a problem or before they reach production. If they do reach production, it's about eliminating them before they actually cause damage to your environment. So that is what shifting zero means in practice, not earlier, but zero. So, one next step, rather than just sending out an email with a recording of this webinar, which you'll probably get anyways, we'll be sharing you in a resource section and in the chat, a link to a self guided product demo. So I think as a modern SaaS buyer, you want to try stuff, in your own time and at your own pace. You can see how army's application security from ServiceNow behaves with real code, and you can play with the console, see if you like, and if it all, seems to be working according to your needs. So with that, I would like to thank you for joining us today. Yoav, thank you so much for being here. Always a pleasure. And, wish you a good rest of the day. Thank you, everybody. Thank you, Maxim. Thank you.