AppSec Needs AI Employees, Not More Tools with Shan Kulkarni

Speaker A: Welcome to to the Point Cybersecurity Podcast. Each week join Jonathan Neffer and Rachel Lyon to explore the latest in global cybersecurity news, trending topics and cyber industry initiatives impacting businesses, governments and our way of life. Now let's get to the Point. Hello everyone. Welcome to this week's episode of to the Point podcast. I'm Rachel Lyon, here with my co host, Jon Neffer. John. Hi Rachel, it's been a minute.

Speaker B: Hi.

Speaker A: Now, I was pinging you this morning because I love when I learn a new term in our world and quasi random design, uh, as it relates to kind of networking and data centers. Can you please explain that to me?

Speaker B: So I read the same article and uh, it's actually quite interesting. Right. Like all these years we've had all sorts of back and forths like what kind of network design is better? Hierarchical, flat layer two, isolation, layer three isolation. And uh, this whole idea of just let things be connected, um, is a pretty interesting idea and kind of brings like that whole theory of the whole Internet at large, lots of connections all over the place down into the data center.

Speaker C: So, yeah, interesting.

Speaker A: Thank you. They didn't really get into what that actually meant. They just said random, quasi random. Anyway, um, but, uh, let's jump into today's guest. Really excited to welcome Shankarni. He is the co founder and CEO of Nullify, the first AI workforce for product security that autonomously detects triages and remediates vulnerabilities. He's based in San Francisco, uh, and is pioneering autonomous. I'm having a Friday autonomous product security engineering to address the critical shortage of security talent, uh, which we know has been a significant challenge for years. Sham previously worked as a software engineer at Cisco and cloud security engineer at CMD Solutions. He's also served as a lecturer at, uh, the University of South Wales computer science and engineering, teaching DevSecOps and cloud security courses. Welcome, Shan.

Speaker C: Thank you for having me. Rachel, great to be here.

Speaker A: Do you want to kick off? Yeah, I've got so many questions. Let's go.

Speaker B: Okay. So Shane, you've been talking publicly about legacy dashboards and scanners and ticket routing just being a losing game. Where does it go if, uh, folks keep going that path? Uh, and when does it break?

Speaker C: Yeah, absolutely. I think that old kind of operating model of buying a bunch of scanners and then hiring a bunch of humans to route all the findings around, um, is kind of on its way out. Right. I'm sure everybody's been talking about Misos. It's kind of a board level priority for most companies. Um, a lot of companies are realizing that that operating model for application security just hasn't been able to create value in that part of the program. And I think the breakpoint is now, like, they don't have enough security, uh, engineers to actually go and turn those findings into fixed vulnerabilities. So with everything that's happening with AI producing exploits, um, staying within the patch gap or closing the patch gap, I should say, um, really becomes a challenging problem. And I think what practitioners are struggling with today is with that legacy approach of scan review fixed, they're really struggling to figure out what needs to be fixed first, how should it be fixed, um, who's the right person to fix it? And generally speaking, they're quite overwhelmed. Um, so I think we're definitely at a turning point in how security practitioners are building this part of their program, the application security program. And, um, it's definitely interesting and exciting at the same time.

Speaker A: Kind of piggybacking on that. I was peeping your LinkedIn, uh, and you had a post of a speaking event, uh, that you were at in San Francisco, the Secure Software and AppSec Summit, and you were sharing some of the feedback that you'd heard and that four out of four panelists called SBoM's perfectly useless for modern AppSec teams. Not because visibility doesn't matter, but because visibility alone doesn't create outcomes. I'd love for you to expand a little bit on that as well.

Speaker C: Absolutely. So I think when this kind of cycle started and SBOM became really, really important, um, we weren't really experiencing the rate of attacks that we were, that we are today. And so where I think security teams have gotten to is they, they feel a little bit fatigued or they feel a little bit, um, you know, fed up with just more tools that are showing them a lot more findings. Right. So when it comes to action, invisibility. So, you know, now that we know what's in our software, now that we know where the vulnerabilities are, um, which of them are actually exploitable, which developers should be assigned to fix them, how should they be fixed, when should they be fixed? Uh, so I think a lot of the conversation from those practitioners was about, um, you know, is more visibility actually helping us, like, uh, in measuring success and with um, in the product security program, is it actually helping us in the things that we care about? So it's actually helping us reduce the size of the backlog, Is it helping us fix more critical risks? And a lot of them are just saying that it's just more visibility, it's not really that useful unless it's actioned.

Speaker B: Can you dig in a little deeper there where you're going on that like if, if the uh, SBOM isn't the right way to go, how, how do we protect ourselves from, you know, being aware of all of the supply chain attacks that are happening recently?

Speaker C: I think it was more of a conversation of like it's only half of the solution or it's only part of the solution. Um, and a lot of them were really talking about the uplift and the opportunity, um, they were seeing in using AI to automate a lot of their previous workflows. I think they're a lot more open, a lot more excited to taking what they have today. So you're signing with. They spent quite a few years investing in SBOM and building out really um, good APIs, really good tools. And now they're interested to see like what can the AI do with it? And um, the AI tell me, uh, while it's happening, as soon as the uh, advisory breaks, like which workloads in my organization have the presence of a vulnerable package, rather than me having to see it on the news, going into my SBOM and then having to search up that package, um, is there a way that the AI can kind of do it for me? And so I think it's less about like, well, they're throwing their S BOMs in the bin. It's more like they're starting to realize like it's only part of the solution for them and um, they're trying to figure out where they should go next.

Speaker A: Yeah. Well I'm so excited we're talking about AI security today because it's such an important topic and moving so quickly. Um, what I've also found interesting, and I'm sure you're running into this as well as part of your business but uh, they're finding AI security doesn't necessarily, or autonomous agents, uh, all of this AI availability, uh, doesn't necessarily make uh, you work less. You're actually working longer hours, your scope is growing incredibly because now you're augmented. Um, I'm just interested in what you're hearing in your patch of the world relative to this.

Speaker C: Yeah, absolutely. So I think it's super interesting and um, super exciting building here at the frontier, um, and seeing other companies, whether obviously they're security companies or any other enterprise SaaS, companies that ah, um, are adopting AI in their products, or other startup founders who are building um, what kind of AI first products I Think the, the way that it's creating value, uh, is changing. And so I don't know if it's about like they're working longer hours per se, but I do think that AI is really good at performing knowledge work. And so uh, a lot of existing knowledge workers who were previously using SAS to perform, perform their jobs, let's say in the security program, you know, they were using these legacy tools and now there's maybe an AI tool that made them more productive. Um, but now the AI can straight up just do what they were doing before, right? So maybe um, AI was making them 30% more productive at triaging alerts or 40% more productive at uh, um, you know, resolving vulnerabilities, whatever it might be. But now we're actually seeing for the first time in SaaS, we don't need the human or the SaaS, right? So in that case to perform that knowledge work. So in that case what is the, what does the human do? Um, and so I think what people are starting to shift towards is a different kind of work I like to call intuition work. Um, and so I think for security, like that's a very interesting shift, um, because what we're seeing now is like, you know, reporting up, uh, understanding the business risk more, um, engaging with lots of different stakeholders in different parts of the business. That seems to be the kind of like intuition work equivalent, uh, for the security program in the security industry. Um, so I think it's a bit more nuanced than just AIs creating more work. I think it's maybe a shift in what most knowledge workers are doing in their day to day jobs.

Speaker B: So from there maybe talk some more about how that AI is interacting with some of the more high risk areas. Right. Product security and so on. And, and is there a responsibility structure that's required around this?

Speaker C: Yeah, absolutely. So I think a lot of people, uh, um, they're really interested in securing AI, but uh, I think a lot of security teams are now starting to understand how much of the value opportunity lies in using AI in different parts of the program. So I think in product security or application security, that's definitely where a large value opportunity sits. Right. Um, if a lot of the way this, the software is being developed is, you know, AI writing software, then I think um, a lot of how it should be secured is AI securing software. Um, so I think that responsibility structure you mentioned and that uh, responsibility model is definitely changing. Um, perhaps like, you know, before you had to um, do a lot more manual review yourself or you kind of Had a uh, certain boundary up until like, you know, that the human security team are responsible for, whereas now they're just kind of reviewing the vulnerabilities the AI is discovering, validating, you know, assigning and fixing. Um, so I think the accountability comes from like how, how well are we trusting the AI's determinations? Can we trust that the AI really believes this vulnerability is a false positive or a true positive, or trust this patch that the AI has opened for one of my developers and GitHub, um, um, I think all of these things are uh, contributing to that responsibility structure, uh, conversation.

Speaker A: Speaking of responsibility, I guess, and tangentially accountability, I mean we can't escape, right, the conversations right now about agentic AI and identity accountability when the agent's taking the action. Um, and so when an agent opens, a pull request escalates in Slack or auto resolves a vulnerability, whose identity is on that action and when something goes wrong, more importantly, where does the accountability lie?

Speaker C: Yeah, it's a great question. I think with um, what we're doing and AI for product security, there is quite a high burden of proof and how do we trust AI and uh, the actions it's performing. But I think in those examples those are workflows that engineering have been automating with AI or automating in some way for a while. So generally speaking it's fine for the identity to just be the identity of the agent, the identity of our AI. Uh, but the kind of final decision, for example for making a code change probably does lie in um, a human reviewing the AI's, uh, changes rather than just letting the AI do whatever it wants. But now we're talking to a lot more security teams that uh, well they're letting their um, agents that build their software auto merge code. So why not let their security agents that uh, patch and secure that software auto merge as well? So it's definitely an interesting conversation that we're seeing in engineering teams.

Speaker B: So looking at um, vault, um. Right. Like how does this work when you're basically now consolidating all of the crown jewels, right? Source code, configuration, authentication, um,

Speaker A: how do

Speaker B: we keep it safe when we're basically putting all the crown jewels in one place?

Speaker C: Yeah, well, I think this kind of twofold question, I think on one side a lot of people don't, they don't disagree or they are starting to realize that they're not able to get good value out of the AI unless it has the right context. So you know, that kind of conversation has become easier to have with security Leaders with any company, uh, once we show them the depth of reasoning and the depth of work that these agents can perform if they have all this context involved. Um, but I think the trust conversation has to still be grounded in, you know, just really good design principles. So for us, you know, Vault is like a fully tenanted, it's like fully isolated per customer. There's no shared data across, you know, any customer stacks. Um, we try to work as much as possible with, you know, abstractions on top of knowledge. So we don't, um, you know, store any of this code kind of server side. We try to store relationships between assets and workloads and everything like that. Um, but it's really what is really powering a lot of our agents, decision making. And I think once they see that like, um, they can actually trust AI more because it's forced to, uh, reference and using its work, uh, the things involved as evidence, um, they start to realize that's actually the path to them making AI really successful in their security program is that sort of a memory layer. So I think it's definitely been a journey, but, um, it's one that a lot of security teams are now much more open to than they were before.

Speaker A: And with the more significant leaning into AI generated code. Um, there was some research report last year about that. Uh, it introduces vulnerabilities of about a 45% rate, which is kind of interesting. I'd never seen an exact number like that. But I'd be curious in your point of view on uh, how an agentic system actually reasons about exploiting for bugs and whatnot versus hallucinating, which we know is an ongoing challenge.

Speaker C: Yeah, absolutely. Um, I think it's really, as I said, it's really all about context. And we spent a year almost, uh, trying to get agents really, really sophisticated at investigating, uh, vulnerabilities and, and when we had just information about the customer's code base, um, that was definitely a good start. And the AI could use tooling, like different types of tooling to generate different symbols and representations of the code to try to understand whether or not a vulnerability is reachable, is it exploitable? Um, but I think where things really opened up for us was when we started giving the AI more context. So the question that we wanted to ask ourselves is what context would a human security engineer need to investigate or determine if this vulnerability was exploitable? Well, it turns out they have to go and see where the workload is deployed, so they probably need access to your AWS account. Um, then it probably needs to Figure out uh, what the application is doing, what the logic of the application is, what other systems it touches. Uh, it needs to understand the behavior of different endpoints and maybe it needs to make requests uh, and actually like try to figure out you know, what responses it gets back with different types of requests. So I think that's really where we started to see an uplift in the quality of our investigations as well as um, going the last mile with, with investigating uh, and triaging vulnerabilities which is just uh, validating an exploit. So we've gone from like the AI saying this is most likely a true positive and these are the reasons and here's how we think it can be exploited to this is a reproduction script um, that validates proof of exploit for this vulnerability. And I think that is the kind of new uh, bar or the new um, level of value that uh, security teams are expecting out of these tools. Like they've been, they've been using these tools for so long. But for the first time the tool can literally tell you with 100% confidence because of its ability to like make those requests and use those tools with 100% confidence that this is something you have to fix. And here's why.

Speaker B: So help me dig into this a little bit further. Right, so in this scenario you're basically putting these tools almost against like your production or test but real systems uh, to actually try to exploit. Like how do you find that balance between actually finding real world things and protecting too from unexpected side effects or potential other issues that the AI actions could cause? Because normal human red teamers might cause side effects too that would not be advantageous against your systems.

Speaker C: Yeah, I mean that's a good point. That's why we always kind of upfront set that expectation. Like this sort of testing needs to happen on non production workloads, it's happen on staging workloads. Um, AI generates a list of a set of export hypotheses. You know, look at what the application's doing, we'll look at the code and then it will go one by one and try to validate each of those. Um, and it will try to see if you're logged in as this user, ah, can you do that? And if you do this and then that, create this data, delete this data, can you yield some sort of behavior in the application um, that results in some exploit or abuse scenario. But that's obviously something that modifies uh, data and um, might be destructive in the way that it's discovered. So we want to make sure that people and security teams understand that, you know, it can't be run on a production workload. Um, that's, I think, how we kind of walk that line. But I think the value that people are starting to see now is exceptional. And you know, a lot of, there's a lot of talk about whether or not the bug bounty program still has a place and all the kind of, um, failing economics. So unit economics of bug bounty and the vulnerability economy more broadly, just because of how good these agents are at discovering this stuff. Um, so, yeah, we've definitely come a long way and we definitely think those considerations are important to adopting it safely.

Speaker A: So there's a wonderful video I saw, um, on your website, but also on LinkedIn and you were talking about, which I never really thought about in this context, in terms of the significant disparity between the number of software engineers and the number of security engineers. I think something 100 to 1 and obviously Amazon or others, the behemoths, are one that have the lion's share of talent. Um, and now that we have agents, uh, and AI, if you're looking in your crystal ball in the next couple of years, because I know everyone has this question, how do you see things? Ah, we all want fewer tools. So are we going to see these two things merge and the agents significantly augment, or do you see it going a different path?

Speaker C: Yeah, I think again, it's interesting because a lot of people, they don't even know what, what their head count or what their um, tools and what their programs are going to look like in a few years. And again, I think it's less about like, are, ah, we augmenting, are we replacing tools or humans? It's more about what kind of work is going to be outstanding to perform. And if AI is performing a lot of what security teams are doing today, um, what else can they be doing? And that's very exciting. So when I talk to CISOs, a lot of them are saying, you know what, actually I wouldn't mind instead of having to hire ten, uh, security engineers for every part of my programs, maybe a product security engineer, an email security engineer, corporate security engineer. Why don't we just hire two staff level generalist security engineers? But they are managing an AI employee in every security program. So those, those two generalists, cyber security engineers, they might manage an AI AppSec engineer, manage an AI corporate security engineer, managing a SOC analyst, et cetera. So I think it's just a shift in like, well, how do we think these, you know, these, these teams are going to create value. And what, what is that going to look like? What's that model going to look like? How is AI going to augment their work or perform a lot of their work? And I think it's going to make them kind of like what I was talking about earlier with the intuition work it all, it'll turn them into more intuition workers. Um, they're orchestrating and managing the AI to do knowledge work and that way they can focus on doing things like connecting the dots. Um, I think that's kind of the only way we're going to see that bottleneck hump of 100 to 1, um, be bridged.

Speaker B: So what's your take on that? The way that bottleneck intersects with uh, say the open source community. Right. Like basically everything that's going on has this underlying foundation of open source supporting it in, in the real world. Right. And I think that same overwhelm is happening to these open source maintainers. Like how does that play out in your mind?

Speaker C: That's a good, that's a good question. I feel like that's its own, uh, problem. A lot of people try to say how do we bring security to the open source? And I think like a lot of it has come from, um, you know, people are like, well, how do we incentivize, do we fund open source projects better? Like how do we incentivize them to be more secure? I actually think this is one of the areas where it's AI is going to make it better. Uh, because you know, I think AI is going to, you know, I know a lot of people at first, uh, and even I was seeing the AI is introducing more vulnerabilities. But I think after that like there's going to be, once the models get so good at coding, like they're going to introduce a lot less of the old types of bug classes. So hopefully we can see like a lot less happening in those open source projects. Um, because you know, they're using the AI tools to generate their code. Um, but yeah, I guess we'll see. I don't know, it'd be great. I guess we'll see.

Speaker A: It's a hot topic though. You keep hearing a lot about that and it's a big one as well. Um, so I always like to ask kind of personal questions, but I won't get super personal. But more about your journey. Uh, because you've had such an interesting journey working at Cisco, you've done exploit research, uh, AWS Unicorn project that I believe became a university course, consulting work that became Nullify. Um, it's always such an interesting journey to where people get today and where we're talking about security on this podcast. Uh, was it kind of a linear path for you or just life just gave you these turns and, and you just kind of kept moving forward and here you are today?

Speaker C: Absolutely. I think it was definitely the second one. I think it was a very accidental kind of founding journey. And I think those, as I've gone on it, I think those of those are generally the best founding journeys. And if you think about Tim and I's background, like we, we really liked um, vulnerability research and expert development. We really liked um, you know, solving difficult, difficult security engineering problems. But we always knew that we wanted to be close to the customer or to be closer to real customers. Real security programs, real companies. Right. Real problems. Um, and so I think whenever you're kind of committed to like ah, where, you know, where do we want to solve interesting problems for the customer, where do we want to take the customer, then naturally like, you know, things are just going to unfold in a way where um, you know, you work on interesting things, you work on interesting problems. So I remember at Cisco like working on Network assurance Engine, uh, I believe at the time was called Network Insights. That was a lot of fun because even though I wasn't very passionate about um, the type of security or like the type of problems, um, like networking, I was really really uh, interested and really, really got to understand early on like, you know, how do enterprise security teams function? Like how are ah, sales engineering or sales teams like deploying and delivering this value? How are they making the customers successful? Um, and that was really interesting to me. And then after that I think like working really closely with AWS to teach students about cloud security and um, open sourcing our own project on um, uh, you know, to build more secure workloads on aws. It really taught us that user empathy I think and I think it allowed us to like cultivate empathy for the customer, cultivate empathy for security teams. And um, I think that's what put us in a good position to, to go down this journey. But definitely definitely wasn't intentional at all. I was doing consulting. One of our, one of my customers was a very large health insurer. They had hundreds of software engineers, they had a small number of security engineers. I thought there was a better way to uh, operate that part of the program. And um, my co founder Tim was also quite passionate about software security. So we both knew from working with AWS that uh, Amazon had a very successful philosophy called security Guardians. And um, from that we were also able to learn what does good look like in the application security space for companies that have managed to distribute that security ownership. So it was kind of a perfect storm of insights and opportunity and timing. But yeah, definitely an interesting and fun journey.

Speaker A: It's also, I think as well. Right. Helping to address this age old problem of where security can come in the process. You bolted in on the back end because we don't want to slow down innovation, but now you can bring it closer to the front, uh, and then it becomes part of the development, which feels to me like a significant shift.

Speaker C: Very significant, absolutely. Um, I think when we started off there was, you know, things happening, but a lot of the time it was just a lot of friction, a lot of challenge to interface between security and engineering. I do think that still remains like a, uh, outstanding problem, especially one that we think, you know, we're well positioned to solve. But, um, yeah, it was definitely, things were definitely in a very different position versus when we started, versus where we are now. Um, and you know, with that, the perception of what good looks like has changed, what value looks like has changed, and obviously it's going to keep changing. And that's, I think what's so exciting is like we are have to keep going 0 to, not exactly 0 to 1, but keep adjusting every couple of quarters as the need changes, challenges change, and ultimately where we want to take our customers change as well.

Speaker A: That's exciting. I love change myself. I'm a big fan of evolution, rapid evolution. So that sounds like a fun challenge. Um, well, thank you so much for your time today, Shan. I, uh, really enjoyed this conversation. There's just so much to dig into here. I wish we had at least. Um, but thanks for sharing your great insights and I love the work that Nullify is doing. Very, very much needed. Uh, and to all of our listeners out there, thanks again for joining us. And I'm going to do the drum roll for Jonathan to make his announcement.

Speaker B: Smash that subscribe button

Speaker A: and you get a fresh episode every single Tuesday. So until next time, everyone stay secure. Thanks for, for joining us on the to the Point Cybersecurity podcast, brought to you by forcepoint. For more information and show notes from today's episode, please visit forcepoint.com podcast and don't forget to subscribe and leave a review on Apple Podcasts or your favorite listening platform.