Welcome, Shantanu Kulkarni

Rachael Lyon:
Hello, everyone. Welcome to this week's episode of To The Point podcast. I'm Rachael Lyon here with my co-host Jon Knepher. Jon. Hi Rachael, it's been a minute.

Jonathan Knepher:
Hi.

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

Jonathan Knepher:
So I read the same article and 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 this whole idea of just let things be connected 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.

Rachael Lyon:
Thank you. They didn't really get into what that actually meant. They just said random, quasi-random. Anyway, but let's jump into today's guest. Really excited to welcome Shan Kulkarni. 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 and is pioneering autonomous — I'm having a Friday — autonomous product security engineering to address the critical shortage of security talent which we know has been a significant challenge for years.

Shan previously worked as a software engineer at Cisco and cloud security engineer at CMD Solutions. He's also served as a lecturer at the University of New South Wales Computer Science and Engineering, teaching DevSecOps and cloud security courses. Welcome Shan.

Shan Kulkarni:
Thank you for having me. Rachael, great to be here.

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

[02:50] Legacy AppSec is at a Breakpoint

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

Shan Kulkarni:
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 is kind of on its way out. Right. I'm sure everybody's been talking about CISOs. It's kind of a board level priority for most companies. 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 engineers to actually go and turn those findings into fixed vulnerabilities. So with everything that's happening with AI producing exploits, staying within the patch gap or closing the patch gap, I should say, really becomes a challenging problem.

And I think what practitioners are struggling with today is with that legacy approach of scan, review, fix, they're really struggling to figure out what needs to be fixed first, how should it be fixed, who's the right person to fix it? And generally speaking, they're quite overwhelmed. 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 it's definitely interesting and exciting at the same time.

Rachael Lyon:
Kind of piggybacking on that. I was peeping your LinkedIn and you had a post of a speaking event 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 SBOMs 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.

Shan Kulkarni:
Absolutely. So I think when this kind of cycle started and SBOM became really, really important, we weren't really experiencing the rate of attacks that we are today. And so where I think security teams have gotten to is they feel a little bit fatigued or they feel a little bit, you know, fed up with just more tools that are showing them a lot more findings. Right. So when it comes to actioning visibility. So, you know, now that we know what's in our software, now that we know where the vulnerabilities are, which of them are actually exploitable, which developers should be assigned to fix them, how should they be fixed, when should they be fixed? So I think a lot of the conversation from those practitioners was about, you know, is more visibility actually helping us, like, in measuring success and within 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.

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

Shan Kulkarni:
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. And a lot of them were really talking about the uplift and the opportunity 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. They spent quite a few years investing in SBOM and building out really good APIs, really good tools. And now they're interested to see like, what can the AI do with it? And can the AI tell me while it's happening, as soon as the 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, 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 SBOMs in the bin. It's more like they're starting to realize like it's only part of the solution for them and they're trying to figure out where they should go next.

[07:11] The Intuition Work Shift

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

Shan Kulkarni:
Yeah, absolutely. So I think it's super interesting and super exciting building here at the frontier and seeing other companies, whether obviously they're security companies or any other enterprise SaaS, companies that are adopting AI in their products, or other startup founders who are building more kind of AI-first products. I think the way that it's creating value 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 a lot of existing knowledge workers who were previously using SaaS to 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, but now the AI can straight up just do what they were doing before. Right? So maybe AI was making them 30% more productive at triaging alerts or 40% more productive at, 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 does the human do? And so I think what people are starting to shift towards is a different kind of work I like to call intuition work. And so I think for security, like that's a very interesting shift because what we're seeing now is like, you know, reporting up, understanding the business risk more, engaging with lots of different stakeholders in different parts of the business. That seems to be the kind of like intuition work equivalent for the security program in the security industry. 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.

Jonathan Knepher:
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?

Shan Kulkarni:
Yeah, absolutely. So I think a lot of people, they're really interested in securing AI, but 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. If a lot of the way this software is being developed is, you know, AI writing software, then I think a lot of how it should be secured is AI securing software. So I think that responsibility structure you mentioned and that responsibility model is definitely changing. Perhaps like, you know, before you had to do a lot more manual review yourself or you kind of had a 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.

So I think the accountability comes from like, 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 in GitHub, I think all of these things are contributing to that responsibility structure conversation.

[11:43] Building Agentic AI Trust

Rachael Lyon:
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. 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?

Shan Kulkarni:
Yeah, it's a great question. I think with what we're doing and AI for product security, there is quite a high burden of proof and how do we trust AI and 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, but the kind of final decision, for example, for making a code change probably does lie in a human reviewing the AI's changes rather than just letting the AI do whatever it wants. But now we're talking to a lot more security teams that, well, they're letting their agents that build their software auto merge code. So why not let their security agents that patch and secure that software auto merge as well? So it's definitely an interesting conversation that we're seeing in engineering teams.

Jonathan Knepher:
So looking at Vault, right? Like, how does this work when you're basically now consolidating all of the crown jewels, right? Source code, configuration, authentication, how do we keep it safe when we're basically putting all the crown jewels in one place?

Shan Kulkarni:
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 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. 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. We try to work as much as possible. With, you know, abstractions on top of knowledge. So we don't, you know, store any of this code kind of server side.

We try to store relationships between assets and workloads and everything like that. But it's really what is really powering a lot of our agents' decision making. And I think once they see that, like, they can actually trust AI more because it's forced to reference and using its work, the things involved as evidence, 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 it's one that a lot of security teams are now much more open to than they were before.

Rachael Lyon:
And with the more significant leaning into AI generated code, there was some research report last year about that. 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 how an agentic system actually reasons about exploiting for bugs and whatnot versus hallucinating, which we know is an ongoing challenge.

Shan Kulkarni:
Yeah, absolutely. I think it's really, as I said, it's really all about context. And we spent a year almost trying to get agents really, really sophisticated at investigating vulnerabilities and, and when we had just information about the customer's code base, 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? 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. Then it probably needs to figure out what the application is doing, what the logic of the application is, what other systems it touches. It needs to understand the behavior of different endpoints, and maybe it needs to make requests 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 going the last mile with, with investigating and triaging vulnerabilities, which is just 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 that validates proof of exploit for this vulnerability. And I think that is the kind of new bar or the new level of value that 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.

Jonathan Knepher:
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 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.

Shan Kulkarni:
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. AI generates a list of a set of exploit 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 and it will try to see if you're logged in as this user, 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 that results in some exploit or abuse scenario? But that's obviously something that modifies data and 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. 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 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. So yeah, we've definitely come a long way and we definitely think those considerations are important to adopting it safely.

[20:13] The AI Workplace Future

Rachael Lyon:
So there's a wonderful video I saw 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. And now that we have agents 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? 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?

Shan Kulkarni:
Yeah, I think again it's interesting because a lot of people, they don't even know what their head count or what their tools and what their programs are going to look like in a few years. And again, I think it's less about like, are 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, 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 10 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 two generalists, cybersecurity 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 teams are going to create value? And 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'll turn them into more intuition workers. They're orchestrating and managing the AI to do knowledge work and that way they can focus on doing things like connecting the dots.

I think that's kind of the only way we're going to see that bottleneck hump of 100 to 1 be bridged.

Jonathan Knepher:
So what's your take on that? The way that bottleneck intersects with 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?

Shan Kulkarni:
That's a good, that's a good question. I feel like that's its own 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, 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 because, you know, I think AI is going to, you know, I know a lot of people at first, 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 because, you know, they're using the AI tools to generate their code. But yeah, I guess we'll see. I don't know, it'd be great. I guess we'll see.

[24:07] Shantanu Kulkarni's Path to Cyber

Rachael Lyon:
It's a hot topic though. You keep hearing a lot about that and it's a big one as well. So I always like to ask kind of personal questions, but I won't get super personal. But more about your journey because you've had such an interesting journey working at Cisco. You've done exploit research, AWS unicorn project that I believe became a university course, consulting work that became Nullify. It's always such an interesting journey to where people get today and where we're talking about security on this podcast. 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?

Shan Kulkarni:
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 vulnerability research and exploit development. We really liked, 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. And so I think whenever you're kind of committed to like 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, you know, you work on interesting things, you work on interesting problems. So I remember at Cisco like working on network assurance engine, I believe at the time was called Network Insights. That was a lot of fun because even though I wasn't very passionate about the type of security or like the type of problems like networking, I was really, really interested and really, really got to understand early on like, you know, how do enterprise security teams function? Like how are sales engineering or sales teams like deploying and delivering this value? How are they making the customers successful? 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 open sourcing, our own project on, 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 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 operate that part of the program. And my co-founder Tim was also quite passionate about software security. So we both knew from working with AWS that Amazon had a very successful philosophy called Security Guardians. And 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.

Rachael Lyon:
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 and then it becomes part of the development. Which feels to me like a significant shift.

Shan Kulkarni:
Very significant, absolutely. 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 an outstanding problem, especially one that we think, you know, we're well positioned to solve. But yeah, it was definitely, things were definitely in a very different position versus when we started versus where we are now. 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 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.

Rachael Lyon:
That's exciting. I love change myself. I'm a big fan of evolution, rapid evolution. So that sounds like a fun challenge. Well, thank you so much for your time today, Shan. I really enjoyed this conversation. There's just so much to dig into here. I wish we had endless time.

But thanks for sharing your great insights and I love the work that Nullify is doing. Very, very much needed. 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.

Jonathan Knepher:
Smash that subscribe button

Rachael Lyon:
And you get a fresh episode every single Tuesday. So until next time, everyone stay secure. Thanks 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.

About Our Guest

Shan Kulkarni, Co-Founder & CEO Nullify

Shan Kulkarni is Co-Founder and CEO of Nullify, the first AI workforce for product security that autonomously detects, triages, and remediates vulnerabilities. Based in San Francisco, Shan is pioneering autonomous product security engineering to address the critical shortage of security talent. Shan earned a Bachelor of Engineering (Honours) in Computer Software Engineering from UNSW in 2022 and previously worked as a Software Engineer at Cisco and Cloud Security Engineer at CMD Solutions Australia. He also served as a Casual Lecturer at UNSW Computer Science and Engineering, teaching DevSecOps and cloud security courses.

Learn more about Shan Kulkarni and Nullify