Vulnerability Jail and the AI-Era AppSec Engineer

0:00Jeevan SinghWe saw someone go over, we reached out to them, we talked to them and say, hey, this is what's going to happen in a couple of days if you don't fix the vulnerability or get an extension. And then for the most part, people were in line. And then we started seeing people after a while not being in line. So we jailed a couple of teams, and then things got back in line again. And then we automated the process. And with automation, there was no yes or like, not— there's no friendliness. It's like, Either you're out of jail or you're in jail.

0:30Chris RomeoAnd it's a deterministic check.

0:33Jeevan SinghIt's a deterministic check.

0:34Chris RomeoNot a non-deterministic, like, well, maybe you're in jail, maybe you're not.

0:38Robert HurlbutYeah.

0:40Jeevan SinghSo, with that, the automation, a lot more teams were going into jail a lot more often. And we got a lot of great feedback from engineering. They weren't aware that they're about to go into jail.

0:55Chris RomeoJeevan Singh is Director of Security Engineering at Rippling, where he embeds security throughout the software development process. With 20 years of experience in development and leadership, he focuses on building strong security cultures and world-class teams that solve emerging security challenges. Hey folks, welcome to another episode of the Application Security Podcast. This is Chris Romeo, and I'm joined by Robert Hurlbut, who is coming to us from an AI lab somewhere. If you're watching on video, you see him in the background. Robert, what are you doing with that AI engine there? Are you, are you building something that, uh, you know, some doomsday device or are we just playing around in the lab?

1:35Jeevan SinghJust playing around at the moment.

1:37Robert HurlbutJust playing around. Uh, no, no specific projects per se, other than training.

1:42Jeevan SinghThat's, that's my biggest project at the moment.

1:44Chris RomeoRobert's bread and butter these days. So go look him up if you need threat modeling and AI training, check it out. That was an unplanned plug, by the way. That wasn't even in the script. We're just making it up as we go. I do want to ask our audience here before we get to a familiar face and voice, Jeevan Singh, who's here with us, but I want to ask us if you would share an episode of the Application Security Podcast, share it with somebody who needs to hear this. We're on this arc where we're diving deep into the intersection of AI and AppSec, and we want to just get the word out to more people because we're, there's, we've had a list of amazing guests and more people need to hear their thoughts because they're on the cutting edge of how these 2 things come together. So share an episode on social, even even better, tag us in it. We'll comment and try to get you at least 3 views.

2:29Jeevan SinghThat's all we can guarantee.

2:31Chris RomeoYou know, we're not that, uh, we're not that famous, but, uh, but Jeevan, now that we kind of kick off working with you here, I'm going to ask you this question that I've been asking a lot of people, and it's a strange question to ask with a focus on AI in the world right now, but what gets you away from the machines? Like, is there anything that gets you outside to play?

2:48Jeevan SinghUh, not really, but I will say, uh, my kids get me outside. And so, uh, driving around, uh, being a chauffeur, so soccer, basketball, ball hockey, track, all these, all the stuff that definitely gets me outside. So at least I get to sit in the sun for a little bit, which is what I didn't realize how much I enjoy just sitting in the sun and just soaking it all in. But yeah, it's been hard, especially with the age of AI, with how fast things go, just to get away from technology and work and all that. So, but yeah, my kids are the ones, major drivers that get me outside.

3:27Chris RomeoAll right, Mike, I'm going to ask you a hard question now, which may be uncomfortable, but laptop, is it with you as you're watching soccer?

3:34Jeevan SinghI was hoping you would not ask that.

3:35Chris RomeoI'm going there, man. That's, I'm known for this. I don't, I'm relentless when it comes to asking people hard questions.

3:41Jeevan SinghFor certain sports. So I definitely take my laptop for soccer and when they go swim club, but for basketball, ball hockey, I don't take my laptop.

3:51Chris RomeoSo The exciting, where there's a lot of excitement that's happening all the time. I get it. Like a track meet, there's like 2 hours of track meet. There's 5 minutes of your kid running.

4:02Jeevan SinghThat's it.

4:03Chris RomeoYou just gotta make sure you look up at the right moment. Like you don't wanna be like deep into a problem. You look up and you're like, your kid's at the finish line. I won first place.

4:11Jeevan SinghExactly. Same with swim club. You, it's a 4 or 5 hour event. Your kid's swimming maybe 3 times that time and it's for a total of 3 or 4 minutes that they've swam in the pool.

4:22Chris RomeoSo All right, so we need an, we need an AI bot that just watches and then goes ding, ding, ding when your kid starts to do something. So you can immediately look up and you can be like, we're doing this.

4:33Robert HurlbutYou got this.

4:34Chris RomeoNo, don't do that. Just, that sounds like a good plan though.

4:36Robert HurlbutYeah.

4:37Chris RomeoIt's, kids are amazing and they definitely get you to different events and things. And it's real, it's, it's real world stuff. It's not, uh, just the screen. I mean, I'm guilty of taking my laptop. places these days when I shouldn't as well.

4:50Jeevan SinghSo it's been a little bit of the reverse this summer. So summer holidays are just about wrapping up for my kids, and been really working on hardware design with my older one. He's 12 now. He got him into digital design. So we got breadboards, we got LEDs, we got the Arduino out. So really showing him the stuff that you can do based on it. So that's been fun. I know it's not moving away from technology, but it's like teaching him how the things that I've learned over the years.

5:20Chris RomeoHey, any, any quality time with a child is, is good, even if there's a screen attached. Now, hopefully you're not just watching TV, which in this case you're not. Like you're, you're teaching him something you've, you've learned in the past, which that's, that's admirable. I love that. That's a cool thing. So, all right, Robert, where are we going with this? Bring us back on the rails here. You are now known as the guy who, who keeps us on the rails, not Ruby on Rails either, because That's, you know, kind of older. This episode is brought to you by Security Compass, a company I've worked with very closely in the past. They've recently put out a great guide on threat modeling for agentic AI. It breaks down what changes when you model an agentic system and what a complete model looks like end to end. The Security Compass platform brings continuous threat modeling, security requirements, and validation into one You'll find the guide at appsecpodcast.com/securitycompass. That's appsecpodcast.com/securitycompass.

6:19Robert HurlbutAll right. Well, we last discussed the future AppSec engineer in a previous episode, but since then, AI has changed how software gets written. Uh, in your opinion, what has changed most in the job?

6:34Jeevan SinghYeah, that's a great question. Like, to recap, we, I think we chatted about this about 3 years ago. And at that point, like the things that I talked about what an application security engineer needs is like, first there's the early application security engineers. They're mostly red teamers or offensive security folks where they knew a lot about security, but they didn't know as much about engineering. So they would attack, provide you a list of things, findings, and the engineering teams will just go and try fixing all of these items. And they're also very no-focused. If engineering wants to do this, they'll say, no, you can't do that, but they won't provide any guidance on what to do next. So that was the initial sort of application security engineer. Then we saw the next wave where they're more engineering-focused. These folks were more emphasis on building. They work really closely with engineers as well, strong software development background. Didn't say no. If engineering had something in mind, they would say, no, but you can do it this way, and really working and being collaborative with the engineering team, finding beneficial, mutually beneficial solution. So really working with them, building up security champions, building up a security partnership program, that sort of thing. So now, as you mentioned, the difference is AI. And what I've discovered is that we still need people to be very, very strong at security and engineering. We need people that are highly technical. They're not actually afraid of shipping. In the past, it'd be mostly shipping security tooling and automation, but these new wave, the future, what I'm looking for is like people that are actually not afraid of shipping code, production code. So I'm looking for people that can fix full classes of vulnerabilities, either They do it themselves or they can bed with the engineering team and do it with them. So, really, really core engineering chops in itself. Very comfortable with AI itself. And I think it's actually different for security. I don't think we just have to be comfortable with AI. I think we have to be on the forefront of AI and really need to know where the industry is going, doing POCs and really testing things out there. So, I have several people on my team that are definitely on the forefront of AI. They know exactly, we're building agentic platforms internally so that we can run our agents on top of it. And these individuals are using the leading edge technologies to make sure that we're happening. And like all things AI, we're very comfortable with pivoting because things change so rapidly in itself. So really, again, looking at people that are strong builders. But really strong at AI. And also, I think in the future we have to be— this is, I hate even saying it, we have to be less collaborative with engineering. So we're going from initially when we said no to them all the time, but didn't provide solutions, then going to more collaborative approach, say no, but you can do it this way. I think we have to go back to being less collaborative because engineering is moving so quickly. it is really hard for us to keep up pace with them. So we have to start saying, no, these are the lines in the sand that you cannot cross at all, and building our programs that way so that they know that this is the line that they can't cross, but they can self-help themselves to get to the place that they need to be without crossing that line. I think that's a very high level. Let me give an example of that. So when we think about vulnerability management, It is a terrible program just in general, because we're always chasing engineers. So we came up with a democratized vulnerability approach at a previous company where we would give all the capabilities to the engineering team. So if a vulnerability goes over SLA, they will get the extension from an engineering manager, VP, or exec. That way security doesn't need to be involved. It's up to engineers. They can chase it down. Now that we're shipping 10x, 20x more code, Things are way harder, and I've seen SLAs slip all the time. So what we've taken is a vulnerability jail approach. So if your vulnerability goes over SLA, we place your team in jail. And what that means is that you no longer can merge PRs into the default or main branches at all. You can still generate PRs, but you can't merge them there. So if you go over SLA, the security team will help merge it. And if everything looks good, you're out of jail and you can continue on with your program. So you need to build out programs like these where you're, you have very defined consequences for not doing the security thing. So a lot more on the non-collaborative approach there.

11:29Chris RomeoIs that a guardrail, a paved road, or something different that you just described?

11:35Jeevan SinghI think it's, I would say it is maybe a guardrail. You have to fix vulnerabilities. There's no, this is no longer an option. And fixing vulnerabilities is a lot easier now than it was a few years ago in itself.

11:50Chris RomeoWhat's been engineering's response to that? Because this is the repeat of a pattern in my earlier technology company days before I became a startup person that was always, we had a threat that the chief security officer was going to shut you down, but there was no technical mitigation to do it. And I think he only pulled, he only swung the hammer twice that I can remember, but it was big things that people were just not doing, you know, basic security things that we were trying to get them to do in those days. But what's, how's engineering responded to this? Are they pushing back?

12:23Jeevan SinghA great question. So we approach this very softly first. So if you give me an inch, I'll take a mile sort of situation. So there was a different jail that we have had in the past. It was called feature flag jail. And the problem was that we keep generating these feature flags and the technical debt around feature flags was very high. It led to a couple of incidents on the engineering side. So the team owning feature flags, they built the concept of a jail. You could, you have a budget of certain amount of feature flags. You can't go over it. And you're, and if you're over budget by when they rolled it out, you have a certain amount of time before you have to get under budget as well. So the concept of jail was there in the organization. So we've noticed that it was getting harder and harder for us to chase down engineers to actually get extensions and fix vulnerabilities. So we pitched this idea to our CTO. Our CISO was there at the time. He loved it because he's a big fan of security. So I will say that you do need a leadership team that is very security-oriented and focused. So pitched that idea. He loved it. We cleaned things up. We tested it a bunch internally, and then we actually had him talk about it at an R&D all-hands. So he told the engineering org that this is what we're going to do. These are the consequences for not fixing vulnerabilities. So there's still an extension process that they can go through, but this was the consequence. And when you have your CTO propose it, no one's going to be yelling at security. They're going to be, and they're not going to be yelling at the CTO. So they all accepted that decision. Not for long.

13:59Chris RomeoIf they do, we know what happens.

14:01Jeevan SinghDefinitely not for long. So with that, the buy-in was great and we started off With the vulnerability jail being manual process. So if we saw someone go over, we reach out to them, we talk to them and say, hey, this is what's going to happen in a couple of days if you don't fix the vulnerability or get an extension. And then for the most part, people were in line. And then we started seeing people after a while not being in line. So we jailed a couple of teams and then things got back in line again. And then we automated the process. And with automation, There was no yes or like, not, there's no friendliness. It's like either you're out of jail or you're in jail.

14:38Chris RomeoAnd it's like— It's a deterministic check.

14:39Jeevan SinghIt's a deterministic check.

14:41Chris RomeoNot a non-deterministic, like, well, maybe you're in jail, maybe you're not.

14:45Jeevan SinghYeah. So with that, the automation, a lot more teams were going into jail a lot more often. And we got a lot of great feedback from engineering. They weren't aware that they're about to go into jail. So we worked with a bunch of them to figure out how does notification work and how do, I get it working better in itself. Now the jail checks were done twice a day. And what I realized was that, that it was not often enough. We had to do it very quickly and more often so people could get into jail, but also get out of jail as well. Third was that we still had the auto— like we still had to get people to get sign-off from their VPs for an extension.

15:27Chris RomeoMm-hmm.

15:28Jeevan SinghAnd VPs are busy people. So some people would get into jail because their VPs didn't have enough time or wasn't looking at extending these requests. So what we did there is that we, you, when you ask for extension, instead of going to VP, now you go to an AI. The AI bot will review your extension request. They will look at, does it make sense, the plan, and is the plan aggressive enough? So if you're asking for a month extension, that might be too long. So, it'll provide you immediate feedback. So, when people request, they'll get rejected, they'll know the reason for rejection, so they can apply for a request again and get accepted there.

16:05Chris RomeoI want to dig into something else you mentioned as you were laying out kind of where we've been and where AI is enabling. You said, you made a comment about being able to eliminate like a class of vulnerabilities.

16:19Jeevan SinghYeah. That's a great question.

16:22Chris RomeoIs like SQL injection. Can we just use AI to squash this thing once and for all across the codebase and then put some checks at, uh, at the repo level that prevent it from ever being introduced again? Like, can inject— is there a chance injection's coming off the top 10? Because I keep making the joke every time I talk about it, and I'd love to not be able to make that joke that why don't we just do the top 1 and we'll just knock out injection.

16:46Robert HurlbutYeah.

16:46Chris RomeoI'd love for that joke to be stale.

16:48Jeevan SinghYeah, we are definitely— so what we're seeing is that everyone's using AI, including bug bounty researchers. So we're noticing a large uptick of vulnerabilities going up in our ecosystem. And what we're doing is that we're now, we're diving much— we were in the past, but we're doing it a lot more often now. It's like, is this a one-off or is this a framework-level fix that we have to make? And when we get enough of them, one of our engineers Very recently, there was one specific class of permission vulnerabilities that we noticed. They embedded with the permission framework team and they are like, okay, if we make these 3 changes, this should eliminate dozens or maybe even low hundreds of vulnerabilities from our queue as well. So, and that we, we definitely look at partnerships for that. We also last year, we noticed that our server-side request forgery mechanism, we saw an uptick. The mechanism wasn't great. So one individual on the team, he's like, let me take over it. I created the anti-SSRF library. I pulled in 2 more security engineers. They applied it across the entire ecosystem. And I think we might've had 1 or 2 vulnerabilities after that. It was just edge cases that we didn't consider. So once we implemented it, we fixed it across the board. So we're definitely looking at, like, when we talk about the future AI security engineer, We're definitely looking at mechanisms where either we're fixing the full class of vulnerabilities in the server-side request forgery case, or we're partnering with our engineering teams and working with them to how to fix a permission class of vulnerabilities.

18:19Chris RomeoYeah, because this, it opens a whole new world that honestly I hadn't really thought about, and that is security team generated libraries. Like we talked about this in the old days, but it was so much work. To create a library, even like an input validation library that you would push company-wide. But now with AI, it's not that hard to do.

18:41Jeevan SinghGenerating the library is still not— it is pretty straightforward now, but it's still hard to implement it across the ecosystem. Like, I know that there's thousands of places where we have to patch the server-side request forgery in itself. So we still need PRs to be approved from the appropriate teams. And what we ended up doing is really batching them so that if we know Team A, there's probably 40 different areas, we'll work with the DRI on Team A and they'll go through all the PRs that we have created and get those all approved. But like, yeah, it's still a bunch of work, but like, it all is all moving faster. We need less context from engineering. AI really helps us distill the information so we can better understand what's happening, helps us with building out the libraries, helps us with patching. And then we work with engineering to get all this merged.

19:30Robert HurlbutOkay. Let's see. I'm looking at our questions. We're all kind of all over the place now.

19:35Chris RomeoWelcome to the world of AI. Welcome to the world of AI. That's how it goes. Absolutely.

19:40Robert HurlbutI want to ask this one, and it's maybe slightly altered a little bit based on some of our conversations, but in terms of working with engineers and developers and delegating more implementation to coding agents, Are there certain AppSec skills that have become more important or other skills that may not be as important anymore or less central, if you will?

20:00Jeevan SinghYeah, I think we're still learning that. So my biggest concern nowadays is I'm still trying to figure out how we live in this AI world is that I really relied on security partners, people that are deeply embedded with engineering teams. understanding what they're building, making sure that we are thinking about security A to Z when building those items. Now everyone's shipping 10x, 20x, 30x more. That partnership framework that we had dies a bit. There's no way for one security engineer to team up with several teams because like even team, even engineering managers are struggling with understanding all the things that they're shipping in itself, just because they're shipping so much. So I do worry more on the partnership side. I worry a lot about situational awareness as well, Robert. Where everyone's shipping everything now. And there's so much being shipped. A lot of, a lot of the times now engineers are not even writing documentation, like documents. They're just generating the POC. I'm working with product saying, hey, this is what I think this feature should look like. And getting alignment with product. And once they've got alignment, that POC very shortly after becomes a beta feature in itself. So, the way that we have done software development is changing considerably, and I don't know how do we partner with our engineering team to make sure that they're considering security at the ground level. So, it's mostly now making sure that we're building strong platforms that have— we built security right into the platform, and these product teams are hooking into these platforms, but I still want to make sure that we have a mechanism that we can figure out things that we need to be aware of on the product side of things as well.

21:48Chris RomeoThis episode's sponsored by Corgea. Design it, build it, ship it. Corgea secures it. Corgea is an AI-native app security platform covering your whole software lifecycle, from the first architecture diagram to code in production. It brings design reviews, AI-powered code scans, scanning, and autonomous pen testing into one platform. So your team spends less time chasing noise and more time fixing what matters. Visit corgea.com, C-O-R-G-E-A.com. Corgia, one security platform for the entire SDLC.

22:26Robert HurlbutSort of addition to that, because this is a thing that I've been really wondering about, and I've got a talk related to it coming up soon. Actually, in a couple months, validation, making sure, so, so much code is being generated. And as you said, the skills are changing, but also validation. I mean, you know, using AI to help you with vulnerability management and so forth, but how are you perhaps tackling some of the validation of all those bunch of code that's being written and distributed out?

22:57Jeevan SinghYeah, we've built a ton of agents to help our code scanning workflows. So we have, we've done it in a few different ways. One is like, one philosophy is that there are certain classes of vulnerabilities and we will target that. So if we go back to the bug bounty, the bug bounty has been great because it's a good signal of what a threat actor would do. So if we notice a vulnerability that we haven't seen before, or a class of vulnerability, or like a permission, say there was a permission vulnerability, authorization vulnerability, It's a new type of authorization vulnerability that we haven't seen. So we can look at that, build a detection, and then scan all of our code to see if we can find something similar. What we've done in addition is that if we've found maybe a bunch of those that are similar, we actually— so that's the static analysis side of things. We also built a mechanism to dynamically test that and say, okay, this is what we think is a hypothesis of potential areas that is problematic. Let's validate if they are actually problematic or not. So with respect to that, we found thousands of vulnerabilities in our ecosystem, and it was very low false positive rates. I want to say like 0.5. There's still false positives just because there was attendant functionality for that. So imagine there was a cross-tenant type of vulnerability, and we discovered, we validated with the dynamic analysis, then we find out that we allow all of our customers to see that particular endpoint. It's behind authorization, but we want all of our customers to see that there. So there are some false positive comp, but it's like fantastic just in general. The other— yeah, go ahead.

24:40Chris RomeoLet me, let me ask you a question in the middle here, because is this the death of legacy or classic AppSec tools that you did? Is that what I just heard that just played out on the— I'm afraid I think I might've just heard that because it sounded like what you just said. Let me read it back and make sure I'm not reading too too much into it, but you virtualized SAST and DAST into your own tool.

25:01Jeevan SinghYeah.

25:02Chris RomeoThat you didn't buy from somebody else. You just built your own best of breed. And it sounds like what dynamic— I've been kind of a hater of DAST for the last couple of years, but what you just described is not how DAST works today in my mind. You just described an experiment that's described that creates a one-time test to see if it's there. Now that's a powerful thing, but back to the original point, like, is this the death of classic AppSec tools?

25:29Jeevan SinghI don't know. For us, we still are finding a lot of value out of our SAST tool. So we've been working with a very known vendor in the SAST space. They've been fantastic. We've been providing them guidance on the things that we need to see. And like, there's a lot of new AI SAST vendors out there. So, We talked about that and they took the feedback and we're seeing hundreds, if not thousands of vulnerabilities, like with very high true positive rates as well. We're not seeing that with a lot of traditional vendors. So we are taking one approach. Our current SaaS provider is taking another approach and we're finding still a lot of value. So I think it really depends on the vendor and if they are evolving with how everything is shifting in itself. So. I guess it really depends.

26:20Chris RomeoThere's been a, it's been, it's, it's, it's been fun to watch the classic AppSec vendors try to embrace AI and how they, it's almost like multiple phases of how they go after AI. Like we're past the chatbot phase. Thankfully, we're past the chatbot phase where AI just means you attach a chatbot so I can ask, what does this finding mean? And it kind of tells you, so they're, they're getting deeper, but I think everybody's trying to figure this out. I saw code review though. So, does code review change in this new world?

26:55Jeevan SinghFor what?

26:56Chris RomeoLike, what's the human in the loop? Like, I've heard 3 terms and I think they're funny when you put them all together. Human in the loop, human on the loop, human out of the loop. And I think the out of the loop is the most scary one, but how does this impact code review?

27:09Jeevan SinghWe're also building agents to help us with code reviews. So, all of the detections that we put in to scan all of our code at a, like a nightly basis. We're also building into our code review bot as well. And the great thing is that bot has a lot of context on code because it's scanning a specific set of code during PR time. So we're still experimenting, but we're finding good success with it as well. So building our own bots for— the thing is that we know our company the best. We know what are our problems. We have seen a lot of these things from bug bounty. So we know how to really tune these static analysis, PR reviews, dynamic analysis just for our specific use cases. And we've, these experiments have been great. Another thing that we've built out when talking about static analysis is that we've started building out objective-based detectors, agents. So we would say that, hey. This particular area of the code looks bad. It's using an eval. So can, can we find a mechanism to get in from the API to hit this eval to find an RCE? It's worked really well. We have been able to find RCEs that way. So you can definitely point your agents at the code and say, this looks bad. This is the reason I think it looks bad. Can you provide me a mechanism and how do I can exploit this? So RCEs, ATOs, all these sort of really bad problems that you've thought about in the past. Again, bug bounty hunters, they struggle because they don't have access to your code. We have access to our code. So we are able to build out these agents to start scanning for these particular items.

28:59Chris RomeoI want to explore another area here because you're describing a whole bunch of build. In the build versus buy scenario. And I know a lot of folks in security that are program operators and department operators like you are asking themselves this same question. And there was in other industries, the funny example is the CRM. Everybody built their own CRM a year ago, and now they're going back to the HubSpots and people of the world because they realized they could build it, But operationalizing and running a system is a whole lot different than creating a prototype that runs in your system. So, how are you processing the build versus buy in this? And do you see like a build is kind of your path, is the path forward for the AppSec engineer V2?

29:49Jeevan SinghYeah, that is a fantastic question that I think about way too often, Chris. I, we build a lot just at Rippling. That's the type of company we're at. But it's really hard to tell the total cost of ownership at the moment. So we're building a bunch of these agents. We're also building the agentic platform in which they run in. We have to maintain all of this for making sure that we continuously scan. We always have to update. So these PR scanners will get feedback from engineering. This is not working well. This is a false positive. So we're always tuning things in itself. I'm very open to build versus buy just in general. So I do think right now build is the right way of going. But I, it could be possible that these vendors catch up and they would be like, and they'd be better. So I only have a team of 18, 20 AppSec engineers. Um, but these companies may have teams of 80, 100, 200 engineers. So they're going to be really good at building something just in general. But, but the other thing is that they're building for the general population where I'm building for Rippling. And making— and so I know everything about Rippling and we can build it very specifically for Rippling. So I'm always open to testing out these vendors because I don't mind offloading this work onto a vendor and just paying someone for it. That means that frees up my engineers to do work on other particular items. So I definitely don't mind, but like right now, definitely it's more on the build route just because We're very heavily in tune with our needs, our company needs, and we can build exactly for that.

31:29Chris RomeoYeah, it seems like every team is going to have a— is there only a certain amount of capacity? Like in, in maybe a year ago, people were thinking, we'll build everything. We can build it all. But the reality is you only have so much capacity and, you know, 18 AppSec engineers, you have one of the largest teams around, right? Like there's, there's not a lot of companies that have AppSec AppSec teams that are that big. There's some, but in general, people are still, that I'm talking to, even, you know, good-sized companies are still in the 2 to 5 AppSec engineer range of, and I don't have any, that's just based on my conversations. I don't have any data to back that up. It's anecdotal kind of, but thinking. So how does this, like, what would you say to those folks that are in that 1 to 5 AppSec engineers? I would just say in general, not even on the build versus buy, just in general, Like, how would you encourage them in this new age of AI to become AppSec engineers V2 based on what you've learned doing this at scale?

32:31Jeevan SinghYeah, the pain, the beginning is pain. It is a lot of pain just in general, but like once you start heavily investing into AI and AI-ifying your programs, we talked about, we talked a little bit about Vulnerability Jail and I didn't share some of the other aspects of Vulnerability Jail that sort of help us in this AI world as well. So part of it is that we have very gracious SLAs. In the past, we've had like 7 days for a critical, 30 for a high, 90 for a medium, 180 for a low. And we hope engineers are fixing things in that time. But when these models are getting so much better and that there are open weight models that you can tune even further, that you have to make sure that you have to move faster because your threat actors are going to start moving a lot faster as well. So we realized that when Mythos was coming out back in March, April, and we were discovering a number of vulnerabilities as part of our, the detections that we were building. So what we ended up doing is we work with the engineering leadership org and saying, hey, we're a new day is upon us. We have to start thinking about these security programs and how they need to survive in the AI world. We have to really change our SLAs. So we had Vulnerability Jail already, but now we're going to be changing SLAs to 3, 5, 7, and 10. 3 days for critical, 5 for high, 7 for medium, 10 for low. And if you still need an extension, you can work with the AI extension bot to extend it. But our expectation is that you're gonna be fixing it that fast. So we have to change our programs, we have to change our approach, 'cause things are gonna move faster. Our threat actors are gonna be moving faster. Our threat actors are gonna be even more malicious in the future. So we have to get into the times with the programs, and we really have to AI-ify all of our programs across the board.

34:30Chris RomeoI like that, AI-ify. Hashtag AI-ify. That's, Kind of a new, kind of a new world. So, let me ask the question from a slightly different perspective, because I know we have a lot of listeners who are in that, maybe they're 1 or 2 AppSec engineers, you know, on the, on their team, and that's all they've got to work with. If I was to take you and just parachute you into a company and you're the only app— let's, let's, let's make it even more fun. You're the only AppSec engineer today, and there's an existing program, but it's, you know, kind of blah. There's not a lot. There's not a lot, not a lot of excitement going on with AI, using AI as a partner here. How would you AI-ify that environment at a small scale?

35:14Jeevan SinghSo I think I go back to the foundations initially. So at most companies, what I end up doing is I fully automate our security tooling programs. So with respect to vulnerability management, because engineers understand vulnerabilities. They don't, it's harder for them to understand risk, but they definitely understand vulnerabilities. So making sure my SAST, my secret scanning, my bug bounty, my SCA programs are fully automated from end to end, which I've done here at Rippling. So like a vulnerability gets discovered, say in your SCA tool, we want to be able to auto-generate a ticket. We want to auto-assign it to the appropriate team. Once they've fixed it, we want to auto-close that vulnerability. and continue on after that. So as a sole engineer, I want to make sure that I've fully automated across the board, all of that, all those toolings.

36:08Chris RomeoHow long is that going to take you if you're— I know you've done this a bunch of times, so it's got— you kind of have an unfair advantage to say it would take you probably shorter than it would take somebody who's trying to figure it out. But what's your time estimate of success there? Like in 6 months, a year?

36:21Jeevan SinghI would say it's— yeah, I think that's about the right 6 to 9 months would be appropriate if you're Like fully focused on this. Once you've established that baseline, then you can start working on your the rest of your vulnerability management program. So like the vulnerability jails, you can work on SLAs because vulnerabilities is very very tangible in itself. And while while those are being built up, then start looking at building detections internally as well. So those are the areas. The other thing that I've noticed a lot that has worked. successfully, like again, this multi-year into your roadmap already, because there's a lot of things that you have to do, is actually working on the risks yourself. It might be harder as a sole practitioner, so maybe embedding with an engineering team to actually work on risks. So we've done that a lot internally. So we've spent a lot of time on our detections and building out our vulnerability detections, a lot of time on security tooling automation. We still are spending a lot of time There, building platforms and other items now. And the third is the really the platform security engineering aspect of things. We're really embedding with engineering teams and fixing vulnerabilities at the platform level, or we're looking at our top risks and embedding with engineering teams or fixing it ourselves, these top risks and moving the company forward that way. So it is definitely a multi-year roadmap. Focus on vulnerability, smallest and most tangible thing. That gets the biggest bang for your buck when it comes to reducing risk in your program. People understand vulnerabilities, and then just slowly build on top of that.

37:58Chris RomeoRobert, why don't you take the final question here to kind of tie these 2 things together?

38:04Robert HurlbutSure. So, what is one concrete investment an AppSec leader can make this quarter to prepare their team for this shift that we've been talking about?

38:16Jeevan SinghYeah, I think I still go back to just vulnerabilities. Like, I don't know if the industry or our community has that sense of urgency yet. Now we're like, our threat actors are armed with a lot of these models that can provide a lot of security value. I know because our bug bounty researchers are doing it. They're finding so many more vulnerabilities. Our threat actors are not far behind, often, and we really have to have that sense of urgency that, no, we have to fix things. So building those guardrails, building vulnerability jails to say that this is it, you have to fix vulnerabilities, you cannot continue focusing on product, there's security technical debt, you actually have to address it. So really having that sense of urgency, making sure that the company has that sense of urgency, and that we're moving in the right direction. We all saw about the Hugging Face and OpenAI incident, and that was accidental. Agents talking to other agents, finding a communication channel, finding ways to get into other companies, all accidental. And we saw like impact happening there. So imagine like a threat actor that knows how to use their models to attack companies, what it would look like. really needing that sense of urgency to start locking down your home and building things properly and pushing all of these fixes out.

39:43Chris RomeoOne of the interesting things I found in looking at that analysis, and we were talking about this before we hit record, the Dwarkesh podcast, he did a write-up on this, is that they actually detected this earlier than anybody thought and they let it run and observed it. They wanted to see what they wanted. They wanted to see how, how it was going to play out because the Hugging Face guy that's quoted in one of the articles said, It wasn't a, it wasn't a mission critical system. So we, we decided to let it run and see what happened just to watch, uh, what was happening. So it is a whole new world, but you mentioned bug bounty a couple times and, and I, I think bug bounty might be on the way out because like you sounds like you've got agents already that you've got virtual bug bounty. I'm gonna keep going back to this virtual idea.

40:28Jeevan SinghYeah.

40:28Chris RomeoEverything's gonna be virtualized, but like you've created, um, almost a, a system that can replicate what the bug bounty folks have been doing from their own knowledge. Like, I mean, I keep saying the thing's dead. I got to stop saying this, but is bug bounty dead?

40:40Jeevan SinghUnfortunately, it is not. Well, I don't know if it's unfortunate. Like, so the very, the low severity, high volume bug bounty researchers are, their time is numbered. So I'm talking about like very authorization issues, smaller ones that are not very impactful. We're seeing a huge uptick in those. Generally, in our bug bounty program, but we're building out detections across the board. We're finding these vulnerabilities. We have strong SLAs that we can close these gaps very quickly in itself. But the really high severity, low volume bug bounty researchers—they're also using AI, and they're finding incredible things. And what I've noticed is vast majority of our bounty pool is going to those ones that are. Finding maybe 2 or 3 critical issues a month in itself. Those are harder to detect or build detections for because they're one-off detections. They found a business logic flaw that happened in this specific case, and it is really hard to write code reviews for that. It's really hard to build detections for it. So I do feel that this is going to level either level up those high, high volume, low severity issues. bug bounty researchers or the ones that are finding those high severity issues. Those bug bounty researchers are just going to be so important just in general. So we have a number of those individuals on our program. One in particular is crazy good. And I like, I continue to believe that they will continue to do way better in the future as well.

42:18Chris RomeoAll right. Well, from a key takeaway and call to action perspective, what do we leave people with here? Like what, what do people need to do? to embrace this AppSec Engineer V2?

42:31Jeevan SinghYeah. So be an engineer. We talked about it 3 years ago when we talked about the future of AppSec engineering. You have to be an engineer and us as security engineers, we have to run as fast as we can towards AI. I do think we need to be at the very forefront of AI research. We have to be more so than engineering. Teams and individuals. I do think the further along that we are with the research and understanding and implementation, the better that we can implement programs in our ecosystem. So be an engineer, embrace AI, be obsessive about it, read everything, practice on your time off, do whatever you need to do, just build, build, build, build. And I think that's where the world is heading. And I'm also seeing a shift in the security engineers as well. Before, People are very highly specialized in just AppSec or cloud security or corporate security. AI has given us the capability of being able to do all of that. So I'm very, as an AppSec engineer, I'm very comfortable with making modifications to our infrastructure now because I reason it with my AI and understand, okay, I can make these particular changes with low impact if something were to go wrong. So embrace, embrace AI. It'll make you a better engineer, security engineer as well.

43:52Chris RomeoWell, Jeevan, thank you for joining us again. I think this is your 3rd visit to the podcast, but to, uh, just share these perspectives from like, you're doing this in the trenches right now. And that's so powerful. Like a lot of people are just pontificating about what to do, but I know you're somebody who's, this is, this is life. This is bread and butter for you right now is, is working through these. And, you know, this idea of the jail, this is a brilliant, uh, a brilliant concept. Um, just so much, so much wisdom that you've already experienced. So I look forward to talking to you again in 6 to 12 months because we know the pace of things is changing so fast just to see what's the, what's the cutting edge, bleeding edge that, uh, you're working on. So we appreciate you, appreciate you, uh, sharing your wisdom with the audience. So we'll do it again soon.

44:38Jeevan SinghI love it. Appreciate you letting me on. 6 to 12 months will be like 7 years of regular time and not AI time. So I'll have a lot of content for you next time. That's true. That's true.

44:48Chris RomeoAll right. Thank you. Thanks for listening to the Application Security Podcast. If you enjoyed this episode, subscribe, leave us a review, and share it with a friend or colleague who would enjoy the conversation. We'll see you next time.