Beyond the Tools: Bridging Product Security Gaps | ft. Neelu Tripathy | Senior Security Architect | Cloudanix | ScaleToZero Podcast

Speaker A: Today's episode is with Neelu Tripathi.

Speaker B: Security is, you know, fundamentally the same thing. And, uh, as an architect, you see the layers much more. So we have to understand the developer mindset. Why does a developer think of authentication? Generally, when you're looking at an architecture, you will not find the industry is moving to more agile ways of development where a lot of this will not apply because they are, they're doing vertical slicing of their requirements. If you look at it holistically and in the larger perspective, we do a lot of ad hoc changes which are need to do basis. You don't really necessarily need to have an R and D to do this. You should have some, um, allocated time for strategic thinking of what kind of systems we need to build. And this applies to all security teams.

Speaker A: Hi everyone, this is Purushottam and thanks for tuning in to Scale to Zero Podcast. Today's episode is with Neelu Tripathi. Neelu is a senior, uh, security architect at Adobe, and she also hosts breakpoint Security podcast. She has close to two decades of experience in the field of security and securing systems and organizations. Thank you so much for joining and if you want to add anything to your journey, please, uh, do share with our audience.

Speaker B: Yeah. Hi, Purushottam, and hi everyone. I'm glad to be on the podcast, um, for my journey. And, uh, mostly I think, um, having been a podcaster myself, I'm so happy to see that we are exchanging a lot more information today, uh, versus what we used to do a decade ago. So it's lovely to see that.

Speaker A: Yeah, absolutely. Uh, podcast has become like a new medium of consuming, uh, learning and consuming content as well. Right. So, yeah, you're absolutely right. Um, before we start though, one of the questions that we ask all of our guests, and we often get unique answers, uh, I want to understand, like, what does a day in your life look like?

Speaker B: Okay, so the day in my life looks like, uh, of course, starting with the usual. I try to squeeze in an exercise routine sometime in the morning whenever I can, unless I'm traveling pretty early to office, uh, and then I'm at work, um, essentially talking to teams. I think a lot of my days talking to product teams because we have a lot of product teams that I work with. Document engineering leads, um, architects, of course, and looking at what requirements are. I think, uh, from the previous, uh, previous few years, it has changed to understand business requirements much better than we do usually in security and then come from the business angle and then start looking into, okay, what do we really need technically to Fulfill these requirements and then uh, go for how the design should look like. Um, it's also interesting to whenever. So there are multiple times when I'll be joining and being involved with people where I, where I have nothing to do with. But it's wonderful to see the perspective of how people can design the same system differently and make it work and make it work efficiently and performantly and, and how there is a clarity, you know, at the end of all of this chaos. That's something very, that has been wonderful particularly um, in work for me as a change from last few years. And yeah, I mean after I come back um, there is still work but then uh, I do some reading. So that's what keeps me going through the day.

Speaker A: So it sounds a good combination of uh, working with other teams, guiding them in the right direction, learning from other teams as well. Which uh, is a good, which is a great uh, mix of uh, learning and also sharing what you're learning and guiding the team so that the overall organization, the products get better.

Speaker B: Yeah, yeah.

Speaker A: So for today we'll focus on product security primarily uh, product architecture and mostly around uh, security like application defense and things like that. So let's dive in. Today we all live in an AI world right? And there is widespread adoption of gen AI, uh whether you are using cloud or whether you're using ChatGPT or any other providers. But everybody nowadays uses uh, Genai. Earlier it used to be engineers who used to write code. Now the product managers can also write code, uh, designers can also start writing code. So a lot of folks have that Genai power and with that also comes a lot of responsibilities that everybody has to fill in. Now connecting that to security. What uh, have you seen, what are some of the non negotiable security controls that must be present when you are building let's say product architecture for AI powered workplaces.

Speaker B: Uh, if you're thinking from the architecture, I think security is fundamentally the same thing. Um, as an architect you see the layers much more. You know as a defender in general you may not, but as architects because you have to build those layers, you have to build those controls, you see those layers much more. So I think the first thing in which I always uh, vouch for is look at the fundamental controls that you need to have. How much ever code is generated by systems is essentially built on top of the data that they have taken from the years of coding that we have done, humans have done. Right. So it's always the same kind of controls that we have. We uh, of course have Additional controls. Maybe we'll talk about that in uh, the podcast later. But look at the fundamental controls. You know, have your basic authentication in place. Are you able to identify entities which can make changes in your system? You know I'm saying entities because it's not restricted to users anymore. Right. So there are, there are machine entities, there are other agent ticket entities. Everything else is coming into place. So look at authentication being one more fundamental control where you can identify or detract a lot of changes that are happening in the system. Um, there is data security controls which are there. I think it's been there perennially for as long as we know. Uh, and now it becomes all the more important because now with everybody developing, there is a lot of access and the access that the code is getting is not necessarily the access that the user has. And there are intricacies within, uh, when the system actually operates, how it goes from there. There are of course fundamental things like you have to take care of, um, auditing and tracking that information, um, things to be compliant, have hardened configurations everywhere. And you will see all of these are very fundamental controls. We have not even touched upon the AI space specific controls. So think of all of these controls, where are you logging, what are you really monitoring beyond just application telemetry and things like that? All of those things I think plays a lot more role now given that there is a lot more generated code which will come with a lot of these flaws as well.

Speaker A: Makes sense. So focus on fundamentals, start from there and then maybe think about AI controls rather than uh, starting all the way from AI. So when you do a security architecture review, let's say you work with uh, engineering team or you working with multiple teams, when you are doing an architecture review, what uh, gaps do you see? Uh, what common gaps do you see, uh, when it comes to product security?

Speaker B: Yeah, so this is not uniform or standard, but you will see at uh, at many places they would have taken care of authentication. Right, because they think so. We have to understand the developer mindset. Why does a developer think of authentication generally? When you're looking at secure at an architecture, you will not find authentication generally standard user authentication is taken care of because they consider it almost like functionality. And a lot of security requirements are quality requirements and not functionality requirements for them. So this is how developers treat it. And hence you will find, okay, this is always there. And I've seen in multiple architecture they're always taking care of care of user authentication. Whether they do that correctly or not is something that of course you can review in the architecture. Um, but then that is something that is taken care of. But the gaps that I mostly see are in the other places. So today, um, and this is not directly related, you will see gaps in areas like what about your build systems? Right? So you have. So I'm completely jumping off of architecture right now and telling you that there are huge gaps outside of the architecture as well where your entire build systems are in places where, because you're talking about supply chain attacks which will impact your application downstream. And then you have not at all thought of where your build systems are. How do you develop, what does the development environment look like? What is the promotion strategy for, uh, promoting from one environment to another? All of those things we have to look at from a specific security standpoint. So that is for a development angle. From a product perspective itself, uh, you will see there are a lot of application gaps. So there are implementation gaps as well. But from an architectural standpoint there'll be things like um, the encryption of data. Okay, so you have for example data storage. So they have thought about data and what is the business data, uh, where they are storing. It is one area you have to look at. How many storages are there, what is the network segregation between that storage. Is there encryption around specific data sets where you need that encryption? And a lot of that of course ties back to compliance. Are there any kind of observability monitoring systems which are present, uh, in the overall architecture? Uh, you also think of availability in terms of not just denial of service and stuff, but more in terms of throttling. Because today there are more systems, given that there are more entities accessing these systems, there will be for example splurge of access uh, to some of these specific features. So from the. So when you're looking at, for example if it's a microservices architecture you're looking at, do we need to now segregate specific services in specific zones, Depending on how quickly the, the splurge in access or requests will be there. Because there is a splurge as in the spike in requests is there. So all, is all of that uh, in place. So from that perspective we have to look at, in some cases we also have to look at if it's able to scale to the requirements of the users. Because um, we will have systems like um, the pub sub and the message brokers that are there which can help them scale. And I'm talking about some of these new systems you will see. I'm also seeing on the other side in the industry there are A lot of, we don't talk about it much but there are a lot of, there's a lot of research happening and a lot of issues that researchers are finding and of course, and hence uh, attackers would also find is in all of these systems that enable and support your microservices, for example, you have the message broker, you have your redis cache, you have all of these caching systems systems and you know, all of these supporting systems that help become the glue for our services also um, can be equally attacked. So we do have to see. So when you're thinking of okay, where, where does my service sit? You also think of where do all of these sit? When you think of if users are authentication authenticating to the system, you also see are services authenticating to each other? You know, are these, is this authentication, if it is based on tokens, is it, is it short lived or not? So all of those things also we have to actually consider when we are looking at the architecture.

Speaker A: So there are so many areas, right? And you spoke about functional, non functional, your application, uh, related areas, the build areas and you rightly pointed out the supply chain as well. I think this week itself there were uh, I think Step Security probably published that uh, there are more attacks happening in the build systems than the application system like applications itself. Uh, so there are so many areas, right? As a product security leader, when you are doing that analysis, where would you start? Like which area would you focus first? Let's say there are 20 items out of those. How do you prioritize where to focus and what would you fix?

Speaker B: So see, I'll be a little practical here. Um, ideally you would prioritize all of this, um, depending on the phases. So generally, or what we traditionally have been hearing is okay, now you're in the design phase, look at the design and then you're in the coding phase. Of course focus on the, on the coding standards and make sure that you have all of this, your developers are trained, um, after that you're in implementation. So of course do code reviews have everything shift left? All of this. We have heard that you, you start very early, be in the ide, keep looking at the code. And I think that does serve if you have a waterfall way of development.

Speaker A: Mhm.

Speaker B: But a lot of the industry is moving to more agile ways of development where a lot of this will not apply because they are, they're doing vertical slicing of their requirements and then they pick up one flow at a time which goes through the entire flow and then another and another. Right. So a lot of that works very, very differently in Agile and for any teams moving fast and with Genai coming in, I think it's moving in that direction where teams will be moving fast. I think some fundamentals in development you can keep in mind where since I was talking about build systems and how you build your build environments and securing that first should be a priority because even before you start development you would start thinking of all of that.

Speaker A: How do you roll out?

Speaker B: How you're looking at. Yeah, how do you roll out? Is there infrastructure? Is your build infrastructure secure or not? Not the security of the code. We'll come to that the infrastructure itself that you're using to build is secure or not. And then you start looking at, on those, on the other software layers where you're looking at for example other requirements, secure or not. So, so when you start gathering requirements, are you thinking of everything including compliance? But then you're thinking of all your um, commonsensical security, uh, controls that need to be there. Right. So all of those things need to be there at the requirement phase. Of course when you started development, even if it is agile, I do say be release focused. Look at all of this, what is necessary in the context of the code, in the context of the requirement that you're delivering, have all of that in place. So keep looking at that. It's, it's not very black and white when you're developing pretty fast and you have to focus on the releases. So if you have for example you have uh, a checkout feature going into release, uh, it will not be wise to look at it later, right? And then everything else is for example put for later. You have to look for, for the entire requirements. If everything has been um, added to the epics and the stories, it's become a part of the developer backlog. If it's actually going as a control, is it being tested by the qa, is it being tested on the pipeline? So when you're looking at the security of the build systems, um, the infrastructure after that you also look at is security automated and as a part of your build pipeline. So then starts coming in, do we have your uh, DevSecOps in place, do we have security automation, your SaaS, Dash, uh, all of this, these things are in place. And then you look at the application, the requirements there, the design, is the design correct or not? Get it reviewed thoroughly and then when the development happens, uh, look at specific features, if it is a faster development and then get it tested. And testing has to be thorough. Of course there will be a lot of testing in the pipeline if you have set up everything. But then there uh, can be also external testing, right, that we always used to do or the only thing that, that we used to do earlier like a decade ago. But then that can also come in. I think for faster development you will have to have a very iterative mindset. How do we iterate? Even as an architect or as a security expert, how do we iterate? Iterate correctly so that we deliver in every release.

Speaker A: So good that you highlighted those. And the key thing that uh, I gathered is like you have to think in a faster loop. Uh, like you are in a loop and you are trying to move as fast as you can. So security should also follow something similar. So with that mindset, uh, like one of the questions that we have got from Arun Vishwanath is what are some security activities that companies overdo which deliver less value?

Speaker B: Okay, just as a joke, okay, I think it would be compliance. But uh, that was just to keep the mood light. I think uh, compliance has, is a big place and I think an entire podcast could be dedicated to that. But, but I think what I have seen and this is I can tell you that they do you know, um, maybe DOM based exercises and we should focus on RCS and then um, you know, they do more of course and we should focus. I mean I think it is not. We have to. If, if you look at it holistically and in the larger perspective, we do a lot of ad hoc changes which are need to do basis rather than building those changes into the system which is happening very very less as of today, which has maximum impact. So I'll give an example and this is something that I have learned at my company. Thanks to them is a lot of your security controls, even if you automate are not good enough if they are not a part of the system or the platform. So okay, whenever you're building a system. Mhm sorry A control into your application. So suppose it is whether it's a product organization or you're building, uh, if you're a service organization you're building for your clients. In any case think of pushing controls to your platform where you're building it. Okay. And not all companies, it's not applicable for all companies because you need to have, have a platform to build that. So in my recent uh, talk that I was giving about uh golden image creation platform that, that uh, we built a lot of controls are in the platform where we do what we do. A lot of which does not work is we keep pushing the developers for One off things all the time. We should try and push everything to the development platform. Wherever you have uh, a development platform or whatever your build system, systems that you're using, push those controls down to these systems so that developers don't have too much worry about okay, this line of code is correct or not or you know, they don't have to worry about from the infrastructure I got wrong or, or a bad image or we had. So for example they had an internal artifactory or they just went outside and picked something.

Speaker A: Yeah.

Speaker B: As an image and that was malicious and it got compromised. Things like that. Build systems where all of these controls can be part of it and then automation will give you 100 times the result rather than automating in pieces because automating in pieces will, will give you a temporary satisfaction that okay, this leg is automated or that tool automates that. But I think a lot of these controls should be a part of the system itself. So I think that we do very less of on the security side.

Speaker A: And why do you think uh, we do that? Is it the availability of resources or budget that you can't invest in that or you think there is a lot on security teams plate? That's why it doesn't get prioritized. Why do you think that's the case?

Speaker B: Actually none of that. I used to think that um, until I saw the power of this and what I realized was, was it is the lack of strategic thinking. So you know, sometimes you could say that, okay, now I am, you know, very much focused on, on the tactical. I'm doing this, I'm solving this for a client or I'm solving this for the company. And I, I need to go for this release right now. But there has to be some dedicated effort, whether it is 10%, 20% depending on how much the company can afford to be able to build these systems. So you will see that's why in some of the very large enterprises they would have something like an R D. But you don't really necessarily need to have an R D to do this. You should have some um, allocated time for strategic thinking of what kind of systems we need to build. And this applies to all security teams where you can. And I'm seeing some of the startups also coming up with that, which is wonderful to see that they are giving up some time and they're strategically thinking on what they need in terms of these systems or these platforms where all of this comes together. And you don't have to separately think of it all the time because you will, you will invariably end up making those errors if you are thinking of it piecemeal. So it is a strategic thinking, not necessarily the budget. Budget comes in play if you're buying something or, you know, which could be the case. But then it's very clear to the leadership that yes, we are, we are going to lose so many uh, man hours or effort or overhead if we don't have the system in place.

Speaker A: And I think you brought up a good point like why organizations have specific R and D teams versus engineering or product. Because often when you are uh, in the process of, let's say rolling out a new capability, uh, or rolling out a new feature, you are in a sprint. You do not take a step back to look at a holistic picture that how can you make the whole system better than just looking at a smaller subset of your task and just focusing on that? This happens with not only security, even in engineering, product design, in every aspect of uh, a product development lifecycle, this happens if you are narrowly, uh, focused. Uh, then you often miss building that, uh, looking at it from a strategic perspective so that it yields better results in longer run versus just focusing on the task at hand and just solving for it rather. Uh, no, that's a very good point. Um, so earlier you touched on that, uh, when it comes to security, uh, now as companies are following more agile, you are constantly trying to uh, sort of build or secure your products. Whatever is getting rolled out, you review, you do things like that. Now with AI that has sort of increased multifold, right? Security in itself is complicated now you're adding the pace at which everybody is building. So I have a couple of questions. When it comes to that intersection, AI and security, product security, uh, how do you use AI to secure products? Like do you have any, uh, do you follow a playbook when it comes to building products, uh, securing products and uh, using AI for it?

Speaker B: Okay, so I think for using AI, there are actually, I would say multiple ways that we can use AI. I think for starters, many of the companies in the industry, and I'm speaking for most of us, um, we have been sitting on a lot of um, ideas for automation. And I have been there because, you know, we knew that, okay, we can automate this also. We can automate that also. But then you're, you're measuring your bandwidth and the number of people that you have in the team and you know, all of that juggling was going on for a long time. And I think AI solves a lot of it. Um, you have a lot of standard and of Course mundane M activities that you do as a part of your, whether you're doing offensive security engagements, whether you're doing actually testing, uh, in the environment where you're doing anything, uh, and including coding, uh, all of that is there where you can streamline that, automate those activities using AI now. And just like you said, right. You don't need security engineers to do that anymore. You know, you can also have your pen testers give instructions and get something working. It's only when you are, I think um, I think a lot of engineers are realizing that. So when we do create systems which will cater to scale, need more efficiency, performance, uh, real production systems. Yes, there are more nuances to developing than that. But I have seen in the industry we have a lot of teams that can benefit heavily from simple automation. So whether for example we would write, we used to write a lot of scripts for uh, different legs of our attack chain. So whether it be recon, whether it be OSINT fingerprinting systems to you know, the entire life cycle can be automated using now uh, the AI, uh products that you have. So that is when you write code and then you create these scripts or you create the systems and things like that. Um, with respect to AI systems themselves, there are other things that we can do but that will include a combination of our fundamental controls which are there plus the AI specific controls. So apart uh, from automating scripts, there are a lot of things like for example you're building a dashboard.

Speaker A: Mhm.

Speaker B: Right. You will see that. So there are different skills. For example security or it's depending on your size need, even in the defensive side will need different kind of correlations when it comes to threat intelligence. And a lot of that correlation or triaging can be done to a good extent when you automate that using AI.

Speaker A: Mhm.

Speaker B: Um, there are also things like um, Playbooks. Right. So you have IR Playbooks where to an extent it can go the initial, I think the initial leg to a good extent AI can take care of if you are able to create that kind of automation for these systems.

Speaker A: You mentioned a very good point where if you have Playbooks, uh, and uh, you need to automate them, you can very well leverage like Genai to just use Claude or something say that hey, this is my Playbook, just automate it. Right. And Claud would happily do it for you, uh, uh, without taking a lot of time and things like that. So yeah, you can sort of strike off a lot of mundane tasks. You can hand it over to uh, AI if you have a well defined playbook already in place actually.

Speaker B: So apart from mundane. So what I was um, also trying to add is see you will see in larger organization we also need not just so a lot of development through security engineering that is happening. You know, larger security engineering organizations are doing back end development, uh, but then there is looking for front end development separately. Right. So front end development, which was you would need front end developers, uh, specifically it's become easier with something like this, at least for security or yes, you can use these. Uh, there is also SREs, the SRE work which is around deployment and things like that, uh, infrastructure provisioning to you know, other kind of these activities. A lot of that has been simplified using AI.

Speaker A: Mhm.

Speaker B: Because you can use AI now to generate that code, to verify that code, to test that all the entire leg of security engineering is also simplified. So it's not just the mundane task. Actually your primary tasks also to a very good extent can be done unless you need a human in the loop. So you will need a human in the loop sometimes, uh, which you need to be aware of.

Speaker A: Yeah, makes sense. So we spoke about using um, AI to sort of improve product security. Uh, do you have a sort of checklist that you follow so that you gain confidence uh, in your product security that you have that uh, it is ready for uh, the world, um, when you're using, let's say AI to uh, improve your product security? Because nowadays there are many attacks that happen. Like we hear about attacks using AI, uh, two different systems, uh, on a weekly basis. Uh, do you follow a checklist that hey, if we have done these five things then we are confident enough to launch uh, a product, let's say.

Speaker B: Yeah, so I think it's not specific to AI. So AI is helpful in every single leg of the product security is what I would say. So for example, uh, what would some of the things that we would look at when we are, um. Um, I would, you know what I have learned through all these years is first of all, uh, what level of automation. And again I know I'm coming back to functional and engineering side a little more is because for us to be able to see what level of automation actually exists because you cannot go with a DevSecOps mindset in a place where there is manual deployments and manual uh, integration happening.

Speaker A: Right.

Speaker B: So if there is, what level of maturity is there in your CI CD? How much automated is your DevOps process? Once you know and understand that entire thing, it makes sense to first look at um, what you can automate on the coding side.

Speaker A: Okay.

Speaker B: And this is, this is irrespective of the pipeline. Okay. So one is that on the coding side itself you can automate a lot of things. Can we add anything on the ide? Can there be basic skills or basic checks, basic guardrails which you can provide on the IDE its itself. And depending on whether it's cursor or you know, whichever other visual studio, whichever ID that you have, can we have a basic set of checks which standard baseline security checks that can be there on the IDE itself. So whenever developers are coding they're able to you know, um, just see where the issues are rather than going back, generating tickets and going from there. The second is the pipeline itself. So your CI or CI pipeline. See what are the checks at the build time that can be performed. If uh, you also have AI, you can do certain level of correlation also within different results that come up. So for example you have uh, a bunch of tests and I'm talking of slightly more advanced systems, uh where in your pipeline you're checking for. So you have sast. Suppose you have sca, uh, you have, have your secret scanning and things like that. But you also have a correlation module that can tell you whether for example the dependency was sourced from um, a specific public place. And then you, they point developer, hey, why don't you go to the internal artifactory and pull it from there?

Speaker A: Mhm.

Speaker B: Right. So this is the kind of correlation that you can do on the pipeline if you have AI built in. So you see the, so I'm when, when I say the traditional controls you are task, task. All of these is traditional controls. But the correlation module is your AI coming in and saying okay, you're guiding the developer to go and take it from there or, or generating a PR for some change. For example, we have found this, we have upgraded and this is the pr. You know, go ahead and do it.

Speaker A: Yeah.

Speaker B: Or accept it and, and test it and so on the fly. There are a lot of things you can do. Of course you will have to customize that. I, I don't know. There is a, there's such a product, it's a good product idea by the way, that there is such a product that can tell you on the fly in the build that okay and correlate and tell you that okay, now you do this. So with AI like there is no limit to what you can do. You definitely. There's a lot of value in correlating results of our traditional tools that we use in different legs of um, this if There is on the fly you want to generate a webhook hook for something specific where the developer is pushing for example secrets or something else. And you can use AI for those kind of it recognizes, identifies, correlates and then creates a webhook. All of those workflows can be created on the pipeline itself.

Speaker A: Mhm. Yeah, I think with AI these things have become uh, a little easier to incorporate. As you gave an example, uh id, uh like earlier what used to happen is uh, or like many organizations still work in that mode uh where developer writes all the code, they push their changes and raise a PR and that's when the scan happens and you find out what are uh the security gaps like as you highlighted like SAS test, sca secret scanning, all of that happens in the pipeline. But with the M, like Genai and the coding agents that we are using, coding harnesses, you can very well do some of those things while the developer is writing the code itself so that you reduce that uh, back and forth in a way. Uh instead of uh, earlier where there would be feedback in the pr now that happens as part of the development process or code writing process. The number of issues that we see in the build process will go down, are going down significantly rather. One question on this uh, that Arun has asked, uh, is that a lot of organizations buy tools for the very same problems that we spoke about. Sas, dast, sea API security or cloud security, all of that. Yet we still see a lot of breaches. Um are ah there some security practices that organizations take can follow which will reduce the risk of attacks. Like the correlation part that you are mentioning is that one of the key aspects, what are top two, three product security practices that you think can reduce maybe the attack surface.

Speaker B: So I think if we want to correlate having tools with breaches, um, it's not a very direct correlation um because so some would argue, and it's a valid question that we are keeping the control is in place for avoidance such breaches only. Right now one of the reasons I suggested we should do this correlation is because a lot of the times these tools, first of all if they are present, if they are in running in a blocking mode, that means it's blocking the build. If you don't go ahead can be very overwhelming for the developers. And I have, I've actually spent a lot of time sitting with developers looking at okay now let's. And this was like very new days of um, me getting into DevSecOps and I remember it was, it was actually funny and um, humbling M. In many ways that we propose a lot of things. Just look at the sea results. And there are, um. I used to work with, I think the first time I saw I was working with a retail application and it was a huge, huge client, of course, a huge code base. And then we just started doing dependency checking for them.

Speaker A: So you must have seen like thousands of vulnerabilities, right?

Speaker B: Yeah, thousands of them. And then, you know, first of all, to even say that this is a true positive and there's a false positive is a task is a nightmare for the security teams.

Speaker A: Yeah.

Speaker B: And I was doing of course single handedly for that project. So I, I realized what that means for me. First forget about the team. And once I did that I realized that yes, there are so many. In many cases there are false positives. There are things that will actually not reach that piece of code or that, um, reachability analysis. And all those issues are also there. So apart from reachability also sometimes it is valid, but it may not really be exploitable. Right. Um, and in some cases it is valid. And then there are controls in place which even developers may not know about. You have network controls that I knew about because I was in security. But you may not expect a developer to know about. And now think of with a thousand issues, where does the developer go? Yeah, right. Um, and this is why many times they will not address these issues and these issues will remain and then something gets exploited, uh, someday. And, and I think in, in many cases you will also not be able to actually trace it back. So in case of uh, Equifax, because there was a lot of investigation and then you figured, okay, it was, was just giving an example. It was Apache struts, uh, Apache Struts 2. And of course it was a dependency that should have been up. All of those things came in because there was a huge investigation. But there are a lot of cases where these would be exploited which would otherwise have been fixed. And that is why the, the more you put it, build it as a part of the system, the more you automate that takes care of it. The lesser and more complex problems is something the developers can solve solve. But since there are a lot of these mundane issues that we throw at the developers, I think many times they also are not resolving some of these. And not all breaches are happening because of issues that are found by SCA or sast. Some of them are zero days, you know, some of them are issues that um, were introduced because of a new uh, change that, or tech change that happened in the system and then suddenly these libraries were pulled in and yet that exposed the attack surface and something else got exposed. So I think there's no direct correlation for this. Um but a lot of threat actors today are uh, becoming smart enough to either use um, of course use AI for their own development, deployment and things like that but also change form from time to time. So that is where I, I talk more. You will see me I think even in my socials I talk more about it that we need to have these fundamental controls in place. So focus more on controls than the tools that you're using to detect as a defender. Because a control is worth a thousand attacks.

Speaker A: Uh yeah.

Speaker B: Right.

Speaker A: And even the tools are trying to solve for the controls. Right. Uh tools are uh, giving you a way to identify against those controls and remediate. But yeah at the end of the day at the core of it it's the controls that they are trying to cater to.

Speaker B: Yeah. And one see many times I have, I have so we, you would have seen like if you have been on the offsec site. It's not that the tools don't find 100 of the issues which are there. Yeah they find what they can find and they give you so.

Speaker A: Mhm.

Speaker B: Like everything always should be taken with a pinch of salt. Like it's never 100% coverage with security

Speaker A: but often what happens is you gave a very good example that when uh, like for the project that you were working on you started with SCA and you saw so many uh findings uh and you go in front of the engineer and say that hey there are thousand vulnerabilities and you have to fix then you. That impacts the relationship, the trust that you build with the team as well. Uh if you are saying that it's a must that you have to fix, let's say 20. That often impacts the velocity of the engineer as well. On similar lines Ashish uh, has asked a question. Especially in the agent driven development world uh that we live in. How do you, you sort of uh calibrate how do you adjust your product security strategy so that the engineering velocity doesn't get impacted.

Speaker B: I think this is the North Star from where you should move and that will course correct security teams a lot and I, so I have work being embedded in the project teams where they're working with a certain velocity generally you know um, 70, 80 points a week is a lot like if you're, if you know the points way of calculating. I think there is a lot of pressure for deliverables and it is something that we should look at because time is currency when it comes to faster developments. And that will be for agenting development. Also if you're using um, more agentic developments, you'll have agentic pods. Yeah, I mean this is uh, this is not like um, right now, but I think in near future we will have things like that where you'll have you as a human in the loop. You'll be the only bottleneck to speed. Right?

Speaker A: Yeah.

Speaker B: So uh, first of all, coming back to the human system, which is much slower than that when you're looking for uh, time being uh, the currency for these systems. How we can look at product security? I think first as a security team, as a security org in your organization, think of what systems you can build. This is long term, this will not happen in a day. But if this is your day job, that you're securing product teams or you're securing development teams, see what systems you can provide. First, systems as in maybe applications, products. It could be anything. Whether you build or you buy, that's, that's another thing. But then what are the systems that you can provide given your requirements? We understand security requirements very well whether we understand product or not. Second, look at which are the existing systems, platforms, pipelines which are being used by development teams where you can embed m your security requirements. So there are some of these. Sometimes you will have these powerful systems which are being used internally. And when I'm saying systems, it's not just pipelines, it's not like just the CICD pipeline that they use. For example, they have an artifactory, right. They have a registry, they have specific shared storage systems that they're using. So where can you be to include an embed security requirements where you can have maximum impact on thousands of developers or maximum developers that you have. So these, look at these, these concentrated places of um, engineering power as I would put it. So generally speaking, if you have these platforms or these storage systems or these artifactories, these centralized places within the organization where you can embed security requirements where you can impact maximum developers. Because security is always fighting with scale. You know, there are always a lot of developers, there are very, very few of us. So where is it that you can put in these controls so that you can impact maximum set of people? And third, when you are in the team itself, one is guiding them to these security baseline. So one of the things that we were talking about in uh, in the talk that I gave on uh, golden image creation platform was we are essentially creating through an image, through a secure image, a secure baseline so it's like we are trying to package security in that image. I mean it will not be 100% but it will be very, very effective on a day to day basis. So think of this way of packaging security in one way which you can of course through automation, through AI, you can do that and you can provide it to the developer so it's much easier for them. So it's like for example when you have something like dependable or innovate where they upgrade their sense, you and PR or an. Mr. Yeah, you just have to, so most of the work is done, you just have to you know, review and accept. So your entire mindset needs to change to be able to provide something which is packaged, which is something that is consumable by them easily. And of course you can take engineering help for that as well. I have been in smaller organizations where we have worked with engineering teams to help develop that and then share it with rest of the hundreds of thousands of developers.

Speaker A: Yeah, no, that's a very good uh, suggestion that you shared that uh, instead of completely bringing a uh, new thing or changing how the engineering is working, you're along working, sort of injecting security into it, uh, so that they don't see this as a completely new way of working. Rather it co lives together uh, and you are building a secure uh, artifact or secure golden image let's say in your case, uh, in your example um, you are not completely changing the process. Rather you are saying that hey, maybe add some checks, uh, and then improve the image to make it a golden image so you have security baselines there. Uh, makes sense. One question I have is how do you see AI being leveraged to develop some of these uh, security practices or security tooling? Um, do you see AI can help or if yes then how.

Speaker B: So yeah, I think a lot of this, which I said can be done using AI because essentially when we have smaller teams how do you, how do you build these systems faster which will also help you scale. It's of course one of the places where you can use AI, uh, the platforms where I said you could embed security requirements. So the entire point where you generate the security requirements to you integrate it on the platform or you package it for the platform or create a module for example that gets called by the platform every time um, developer is running something. Uh, can you have checks in terms of uh, what is being pulled from a certain registry? Right. Can you do a correlation? Can you do an on the fly check? Can you have, yeah, organization policies being written for your requirements. So today you can also have your standard compliance requirements for example and then translate that to OPA policies if you have uh a centralized system and then AI can help you the entire like it's just a matter of figuring out what is the pathway that you want to cover and which are the systems you have. So I'm saying more from an org standpoint that and especially for security leadership where they can all use AI um to not just for day to day mundane tasks but for all of these strategic tasks as well because now you have much faster engines. So I, I'm reading AI like an engine that can be used in any direction that you put it and can because there's no. There are specific ones. Like for example if you have access to uh my thoughts or Mythos, I don't know how you pronounce it. You can just focus it on um security and generate, for example figure out Discover your Zero Days. Right. But then a lot of organizations don't have that today and I am a big proponent of you know use that for defense rather than you know attack. And of course attack you can use the normal models also will give you some good level of results.

Speaker A: Yeah, yeah, uh, yeah, I mean uh, on a lighter note like there a lot of folks I speak with they have that confusion whether it's called Mythos or, or mythos. So I don't know what's the right way to say it um, but um a good thing that you uh pointed out when it comes to using uh AI and uh sort of uh building some of these or rather infusing some of the organizational practices into it so that the sooner you like wherever let's say the code is getting generated uh it knows that what organizational controls need to be uh checked against or what in real time you can do the correlation and find out and maybe remediate then and there itself. So this week there was forward Cloudsec in Seattle and one of the talk was given by Pratish from Xai and he was talking about paved roads for agentic uh development. Like nowadays everybody uses agents to write code and build products. How can you infuse your own security controls, organizational policies uh right into the developers uh ecosystem or developers world so that uh whatever code is getting generated it knows what controls it needs to cater to, what policies it needs to, to satisfy and things like that. Uh we'll share that as part of the uh show notes so that our audience can listen in as well. But yeah it sort of matches with what you said. Right. Like how do you Ensure your organizational policies are also uh, infused so that security is coming from get go rather than again it goes through the pipeline and then uh, you're going in a cycle right at that point. Point.

Speaker B: I am a little excited for this one, I think. So when you mentioned. I have not gone through that, but I have a lot of uh, of course ideas around, you know, um, and things that. Some of the things that I've tried as well is then we're talking about paved roads for ah, agentic development. There is an entire world, okay. And this is this. I'll not talk about the traditional security that I've been talking about so much, the fundamentals and all of that. Okay, that is there. That of course course you need to have. But there are some specific components when it comes to agentic development. Right. Which you have to be aware of. Um, you may have a platform, you may not have, but you will need to have these for maybe any kind of harnesses that you're building or any kind of agentic development that you do. So one is you have to think of the registry, um, and different organizations. You may be calling it differently but more like the place where ah, it's like an artifactory where you'll have all your um, organizational practices. Yeah, AI tools. AI tools, I'm saying a very generic word. For example your tools, your MCP servers, any other AI artifacts being stored and retrieved and all of that. That's one big place. So until now you've been thinking of artery factory in a certain way, right? Dependencies in a certain way. And I look at MCP servers very much like dependencies. A lot of those are created, um, there's a marketplaces for that. A lot of those are created in open source manner. Some of those are proprietary and we do not have a visibility on most of those that we are using that any organization is using today. Right. So just like depend, treat them like dependencies, right. You have to vet them every time that you import them. There could be any kind of changes. You have to be able to have uh, now think of it in the context of AI supply chain and AI supply chain is a topic in itself, so I will not go there. But your registry should always, always be vetted for all of this. So you can have MCP scanning, you can have tool scanning, you can have all kinds of scanners which are deployed on that. But since you're doing agentic development, it's important to have, for example, do you identify your agent? Do you register your agents whenever agents are created? Because agents There's a lot that agents will do. Um, and tomorrow if something goes wrong, will you be able to trace it back? Okay. If you've not identified the agents, if all of this is registering and all of that is not done, you'll not have any clue. So do you have that? That is one component of the entire scheme. Um, there are other things. Like for example you will have your gateway, um, gateways itself, right? You will have maybe the agent to agent. So A2A protocol you might have heard of that Google came up with where agents are talking to each other. You'll have agentic gateways, you'll have LLM gateway where your system is interacting with the LLM M. What kind of controls do you need for that traffic? The agent communication with uh, the LLMs. Right. So there is an entire set of controls there. Um, there's also the agent runtime. But because with agents now that you are uh, executing essentially any instruction that's coming in right, does the agent execute in the sandbox? Is there isolation for that? Is there ephemerality where you know, just agent executes and uh, like more like in a containerized environment. And you know that every time there is a fresh one that is spun up. So all those considerations are um, are there as well. And then there is the big part that is context. So context today is being managed in very creative ways by different organizations. But context needs its own security, which is not the traditional security. You have to look at context in the sense of uh, not just in terms of storage and memory that context has. There's a lot of different kind of memories that constitutes the context management system. Ah, how do you identify the context? Can you trace the context? Uh, how does it link to the previous context?

Speaker A: Right.

Speaker B: What kind of access you're giving to data based on the context for the agent. So a lot of that will come into play when you have context management for your agentic development. So I think these are some very fundamental pieces to just agentic development that are relevant to security.

Speaker A: I can clearly see where you are excited and where uh, ah, you have been spending a lot of time learning and building uh, around. So one question I wanted to ask, like you have been in the security uh, industry for a while and what keeps you motivated? It clearly looks like gen and the uh, challenges uh, that it brings in, it is keeping you excited. Uh, anything else that keeps you going and in security space?

Speaker B: Yeah, I think I, I was in security earlier for the you know, the thrill of hacking. Uh, and that was uh, that was so Lovely. Because I think it kept changing from time to time. You have new systems and you would hack new systems. And I think now it's a reverse. You have new technologies coming in and we are defending new technologies every time and you're thinking creatively to try to defend each of these technologies. So just. I think it's the change in technologies and the challenge that comes with it is what keeps me going. Uh, I don't know if others would relate to it.

Speaker A: But speaking of change in technology, uh, like since our focus is product security, how have you seen product security evolve, like throughout your career? Like especially let's say when it started from on premise to cloud, cloud to mobile and now let's say to agentic applications. How have you seen this evolve?

Speaker B: I think so. On a lighter note, we do very well when you focus on one layer. So initially, um, we solved for. And I'm saying it's not an ideal way in the way that we solve. When we say that we solve that we productize, we productize and we have bunch of tools in the network layer already, uh, when the network boundaries were considered to be the point of threat or threat entry. And then we moved to the web apps, uh, application there and then there are a bunch of products that came in. Um, and that's how it evolved because we are evolving layer by layer by productizing some of the, automating some of these controls across the layers. Then there was cloud, um, and um, infrastructure as service and all of that. And then we evolved there where we are. I think we have evolved because we have automated a lot of this and it applies to a lot of individual security teams. Also the more you automate, the more you evolve because you can think of more complex problem statements for security in the org and the business. Uh, but I think it's also important to keep the larger context in mind. Like you cannot have uh, an ASPM or just a CSPM and think your cloud is secure.

Speaker A: Yeah.

Speaker B: You know what I mean? So you cannot have a product and think your entire domain is secure because there's always a lot which is beyond the product in a real organization.

Speaker A: Going back to what you started with also. Right. That uh, these products and all, they cater to certain countries controls. So as an organization you have to keep in mind what are some of the foundational controls that you want to have in place. And then as systems evolve or ecosystems evolve, you add additional controls. Like nowadays, as you highlighted just a few minutes ago around AI controls, how do you do, uh, for context, how do you do for LLM, how do you do for, for agents? All of these are sort of new controls that you have to think about on top of the foundational controls for your organization. Um, so yeah, that makes sense and that's a great way to sort of end the security questions as well. But before we end the podcast though, I have one last question for you. Do you have any learning recommendation for, for our audience? It could be a blog or a book podcast, anything that you would recommend.

Speaker B: Uh, of course, check out the Breakpoint Security podcast. Uh, but um, beyond that, I think recently there have been lot of changes in uh, the AI domain and there is a lot of sources that I see. I think for anybody who's interested in AI, especially in security, we must be aware there is a, there is a very good resource that I have found is it runs. It's not like a podcast. It's more like um, like a mini conference. But they discuss very like important things like AI Engineer. I don't know if you have checked it out. It's AI Engineer is the, the YouTube handle that they have. They're actually touching upon very, very foundational pieces from an engineering standpoint on AI. And, and the more we understand that from security, the better we can secure it. So these nuances of you know, how does the code change when you're refactoring now brownfield applications using AI, now you have AI, right? You can, you can refactor the whole thing, but there are a number of nuances that are there. So similarly when we are building or using or securing these AI products or in general production, uh, it's important to see where AI can step in, how it needs to be used, where does human need to be in the loop. So all of these things will build a better picture when we are strategically defining security for our organizations.

Speaker A: Yeah, we'll definitely, I'll check out and we'll also add it to the show notes, your podcast and also AI engineering, uh, YouTube, uh, handle so that our audience can go in and uh, uh, sort of subscribe and learn from uh, from that as well. Thank you so much uh, Neelu, for the engaging conversation. Uh, here are a few points which stood out for me. The first one is when it comes to product security, always start with foundational controls and add additional uh, controls as you expand the scope. Like let's say as uh, with the introduction of AI usage, add AI controls. Uh, the second one is incorporate organizational policies, paved roads, uh, into engineering practices starting from let's say IDEs or build pipelines or infra and all other touch points. The last one is for better collaboration with engineering, uh, provide security systems or platforms and embed security controls into existing workflows to work alongside existing practices rather than completely replacing and uh, uh, building completely new engineering workflows. Thank you. Uh, yeah, with that I think we come to the end of the podcast. Thank you so much, uh, Neelu, for joining and uh, sharing your knowledge. And I see that even after close to two decades, you're still excited because there is a new chapter in a way, uh, new ecosystem is getting built and how do we secure that or how do we stay ahead of it? Thank you so much for coming to the the podcast and uh, sharing your.

Speaker B: Yeah, thanks. Thanks Purushwathan for having me.

Speaker A: Yeah. And to our audience, thank you so much for watching. See you in the next episode.