Beyond the Tools: Bridging Product Security Gaps & Calibrating SDLC with Neelu Tripathy

TLDR;

• For product security, always start with foundational controls and add AI controls with introduction of AI usage.
• Incorporate organizational policies, paved roads into engineering practices starting from IDE Checks, Build Pipeline Checks, Infra Checks and all other touch points.
• For better collaboration with Engineering, provide security systems / platforms, embed security controls into existing workflows to work alongside engineering practices instead of replacing engineering workflows.

Transcript

Host: Hi everyone, this is Purusottam and thanks for tuning in to ScaleToZero Podcast. Today's episode is with Neelu Tripathy. Neilu is a seniors security architect at Adobe and she also hosts a Breakpoint Security podcast. She has close to two decades of experience in the field of security and securing systems and organizations. I'm excited to welcome you, Neelu. If you want to add anything to your journey, thank you so much for joining. And if you want to add anything to your journey, please do share with our audience.

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

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

Neelu: Okay, so the day in my life looks like of course starting with the usual, I try to squeeze in an exercise routine sometime in the morning whenever I can, unless I'm I'm traveling pretty early to office. and then I'm at work, 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, dominant engineering leads, architects of course and looking at what requirements are.

I think from the 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 go for how the design should look like.

It's also interesting to whenever so there are multiple times where I've been joining and being in call 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 in in work.

For me has changed from last few years. And yeah, I mean after I I come back, there is still work. But then I I do some reading. So that's what keeps me going through the day.

Host: Mm, awesome. So it sounds like good combination of working with other teams, guiding them in the right direction, learning from other teams as well. which is a which is a great mix of learning and also sharing, right? What you're learning and high guiding the team so that they the overall organization, the products get better.

Neelu: Yeah, yeah.

Host: So, for today, we'll focus on product security primarily, product architecture, and mostly around security, like application defense and things like that. So let's dive in. Like today, we all live in an AI world, right? And there is widespread adoption of Gen AI, whether you are using cloud or whether you're using Chat GPT or any other providers, but everybody nowadays uses Gen AI.

And earlier it used to be engineers who used to write code. Now the product managers can also write code. designers can also start writing code. So a lot of folks have that Gen AI power. And with that also comes a lot of responsibilities that everybody has to fill in, right? So now connecting that to security, what have you seen? Like 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.

Neelu: So if you're thinking from the architecture, I think there are security is, you know, fundamentally the same thing. And as an architect, you see the layers much more, you know. As 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 and which I always 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 of course have additional controls. Maybe we'll talk about that in 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.

There are data security controls which are there. I think it's been there perennially for as long as we know. 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. you know, and there are there are intricacies within when the system actually operates, how it goes from there.

There are there are of course fundamental things like you have to take care of auditing and tracking their information, things to be compliant, have have hardened configurations everywhere. And you will see all of these are very fundamental controls. We've not even touched upon the AI 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.

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

Neelu: Yeah, so this is not uniform or standard, but you will see at 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, it's 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 this is I have seen in multiple architectures, they're always taking care of user authentication, whether they do that correctly or not is something that, of course, you can review in the architecture. But then that is something that is taken care of. But the gaps that I mostly see are in the other places. So today,

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 is the development environment look like.

What is the promotion strategy for promoting from one environment to another? All of those things we have to look at from a security standpoint. So that is for a development angle.

From a product perspective itself, 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 the encryption of data. Okay, so you have, for example, data storage.

So they have thought about data and what is the business data. Where they are storing it is one area you have to look at. How many storage units 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 in the overall architecture? 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'll be, for example, splurge of access 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 this the splurge in access or requests will be there. Because there is a splurge again, the spike in requests is there. So all of is all of that in place. So from that perspective, look at we have to look at in some cases, we also have to look at if is it's able to scale to the requirements of the users.

Because we will have systems like the pub sub and you know the message brokers that are there which 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 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 and you know all of these supporting systems that help become the glue for our services also 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 when we are looking at the architecture.

Host: So there are so many areas, right? And you spoke about functional, non functional, your application related areas, the build areas, and you rightly pointed out the supply chain as well. I think this week itself there were there were I think Step Security probably published that there are more attacks happening in the build systems than the application system, like applications itself. So 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 twenty items. Out of those, how how do you prioritize where to where to focus and what would you fix?

Neelu: So see I'll I'll be a little practical here. ideally you would prioritize all of this 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. after that, you're in implementation.

So, of course, do code reviews, have everything, shift left, all of this. We have heard that you know 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.

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 the another and another, right? So a lot of that works very, very differently in agile. And for any teams moving fast, and with Gen AI 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 you're so since I was talking about build systems and and how you build your build environments and securing that first should be a priority because when even before you start development, you would start thinking of all of that. While you're also looking at, yeah, how do you roll out is there infrastructure your if is your build infrastructure secure or not? Not the sick the security of the code, we'll come to that.

Is the infrastructure itself that you're using to build is secure or not? And then you start looking at on on those on the other softer layers, where you're looking at, for example, are the requirements secure or not? So when you start gathering requirements, are you thinking of everything including compliance? But then you're thinking of all your commonsensical security controls that need to be there, right? So all of those things need to be there at the requirement phase.

Of course, when you're you've started development, even if it is agile, you

I I do say be release focused. You 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 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 a checkout feature going into release, it will not be wise to look at it later.

Right. And then everything else is, for example, a portfolio. You have to look for the entire requirements. If everything has been 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 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, 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 devse ops in place? Do we have security automation? You have SaaS Dash, 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, look at specific features if it is a faster development, and then get it tested.

So 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 can also be external testing, right? That we always used to do, or the only thing 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? Yeah, even as an architect or as a security expert, how do we iterate? alterate correctly so that we deliver in every release.

Host: So… good that you highlighted those, right? And the key thing that I gathered is like you have to think in a faster loop. 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, 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.

Neelu: Okay, I just as a joke, okay. I think it would be compliance. But yeah, that was just to keep the mood light. I think no compliance has is a big place. and I think an entire podcast could be dedicated to that. But I think what I have seen and this is I can tell you that they do, you know, maybe DOM-based excesses and we should focus on RCs and then you know, they do more of cores 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 you an example. And this is something that I've I've 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 a whenever you're building a system… sorry, a control into your application. So suppose it is whether it's a product organization or you're building 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 a platform to build that. So in my recent talk that I was giving about golden image creation platform that that 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 of things all the time.

We should try and push everything to the development platform wherever you have a development platform or whatever your build 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 the wrong or or a bad image. Or we had as for example they had an internal artifactory or they just went outside and picked something 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 hundred times the result rather than automating in pieces right?

Because automating it 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.

Host: Mm-hmm. Hmm. And why do you think we do that less? Is it the availability of resources or budget that you can't invest in that? Or you think the there is a lot on security teams played, that's why it doesn't get prioritized. Why do you think that's the case?

Neelu: Actually, none of that. I used to think that until I saw the power of this, and what I realized 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 the tactical, I'm 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 RD, but you don't necessarily need to have an R&D to do this. You should have some 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 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 the 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 it's very clear to the leadership that yes, we are we are going to lose so many man hours or effort or you know overhead if we don't have this system in place.

Host: Yeah. And I think you brought up a good point, like why organizations have specific R&D teams versus engineering or product. Because often when you are in the in the process of let's say rolling out a new capability 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, right?

And this happens with not only security, even in engineering, product design, in every aspect of a product development life cycle, this happens, right? Like if you are narrowly focused, then you often miss building that like looking at it from a strategic 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. no, that's that's a very good point.

So earlier you touched on that when it comes to security, now as companies are following more agile, you are constantly trying to 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. How do you use AI to secure products? Like do you have any do you follow a playbook when it comes to building products, securing products and using AI for it?

Neelu: 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, we have been sitting on a lot of 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. you have a lot of standard and of course mundane activities that you do as a part of your whether you're doing offensive security engagements, whether you're doing actual testing in the environment, where you're doing anything and including coding, 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 then get something working. It's only when you are, I think, and I think a lot of engineers are realizing that. So when we do create systems which will cater to scale, need more efficiency, performance, 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 different lengths of our attack chain. So whether it be recon, whether it be OSINT, fingerprinting systems, to you know, the entire lifecycle can be automated using now the AI 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. 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 from automating scripts, there are a lot of things.

Like, for example, you're building a dashboard, right? You will see that. So there are different skills. For example, security awards, depending on your size need, even in the defensive side, will need different kinds 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. there are also things like playbooks, right?

So you have IR playbooks where to an extent it can go. The initial I think the initial like to a good extent AI can take care of if you are able to create that kind of automation for these systems.

Host: You mentioned a very good point where if you have playbooks and you need to automate them, you can very well leverage like Gen AI to just use Claude or something, say that hey, this is my playbook, just automate it, right? And Cloud would happily do it for you without like 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 AI if you have a p well defined playbook already in place.

Neelu: Actually so apart from mundane, so what I was 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 backend development, but then there is whether they're looking for front-end development separately, right? So front-end development, which was you would need front-end developers specifically, it's become easier with something like this. At least for security org, yes, you can use these. there is also SREs, the S SRE work which is around deployment and things like that, infrastructure provisioning to you know other kinds of these activities, a lot of that has been simplified using AI.

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, which you need to be aware of.

Host: Yeah. Makes sense. So we spoke about using AI to sort of improve product security. do you have a sort of checklist that you follow so that you gain confidence in your product security that you have that it is ready for the world. when you're using let's say AI, right, to improve your product security.

Because nowadays there are many attacks that happen; like we hear about attacks using AI two different systems on a weekly basis. do you follow a checklist that hey, if we have done these five things, then we are confident enough to launch a launch a product, let's say.

Neelu: 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, what would some of the things that we would look at when we are I would, you know, what I have learned through all these years is first of all, what level of automation, and again I 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 CI integration happening, right? 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 what you can automate on the coding side.

Okay, 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 we can provide on the IDE itself? And depending on whether it's it's cursor or or you know, whichever other Visual Studio, whichever IDE that you have.

Can we have a basic set of checks which standard baseline security checks that can be there on the ID itself? So whenever developers are coding, they're able to, you know, just see where the issues are rather than going back, generating tickets, and and going from there. the second is the pipeline itself. So your CI, your CI pipeline, see what are the checks at the build time that can be performed. if you also have AI, you can do certain level of correlation also within different results that come up.

So, for example, you have a bunch of tests, and I'm talking of slightly more advanced systems where in your pipeline you're checking for so you have SAST, suppose you have SCA, you 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 specific public place, and then you they point the developer, hey, why don't you go to the internal artifactory and pull it from there? 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 fundamental. So I'm when when I say the traditional controls, your SAST as all of this 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. 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 is 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 is a lot of value in correlating results of our traditional tools that we use in different legs of this. If there is on the fly you want to generate a webhook for something specific.

But developer is pushing, for example, secrets or something else, and and a you can use AI for those kind of it recognizes, identifies, correlates, and then creates a webhook. You know, all of those workflows can be created on the pipeline itself.

Host: Mm-hmm. Yeah, I I think with AI, these things have become a little easier to incorporate. Like as you gave an example, right? Like ID, like earlier what used to happen is or like many organizations still work in that mode, 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 the security gaps are, like as you highlighted, right? Like SAS, DAST, SCA, secret scanning, all of that happens in the pipeline. But with the like Gen AI 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 sort of reduce that back and forth in a way, right? instead of earlier where there would be feedback in the PR.

Now that happens as part of the development process or code writing process. So the number of issues that we see in the build process will go down, are going down significantly, rather.

One question on this that Arun has asked is that a lot of organizations buy tools for the very same problems, right? That we spoke about SaaS, DAST, SCA, API security or cloud security, all of that. Yet we still see a lot of breaches. are like are there some security practices that organizations can follow which will reduce the risk of attacks? Like the correlation part that you were mentioning, is that one of the key aspects? W wha what are top two, three product security practices that you think can reduce maybe the attack surface?

Neelu: So I think if we want to correlate having tools with breaches, it's not a very direct correlation, because so some would argue and it's it's a valid question that we are keeping the control is in place for avoiding such 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 a in running in a blocking mode, that means it is 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 me getting into DevSecCOPs.

And I remember it was it was actually funny and humbling in many ways that you know we propose a lot of things. We just look at the SCA results.

And there are and I I used to work with I think the first time I saw it I was working with a retail application. Okay, and it was a huge, huge client. Of course a huge code base. And then we just started doing dependency checking for them. And you can imagine exactly.

Host: So you must have seen like thousands of vulnerabilities, right? Yeah.

Neelu: 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. and I was doing of course single-handedly for the 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 the dependency or that those issues are also there. Then are so apart from reachability also sometimes is it is valid, but it may not really be exploitable, right? and in some cases it is valid.

Host: Hm. Reachability analysis and all. Yeah, yeah.

Neelu: 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 with a thousand issues, where does the developer go? Right? and

This is why many times they will not address these issues and these issues will remain. And then something gets exploited someday. And and I think in in many cases you will also not be able to actually trace it back. So in case of equifax.

Because there was a lot of investigation, and then you figured okay, it was just giving an example, and it was Apache struts, Apache Struts 2, and of course it was a dependency that should have been up. So 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 could 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. 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 were introduced because of a new change that or tech change that happened in the system and then suddenly these libraries were pulled in and yeah that exposed the attack surface and something else got exposed. So I think there's no direct correlation for this but a lot of threat actors today are becoming smart enough to either use 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. Right?

Host: Yeah. And even the tools are trying to solve for the controls, right? tools are 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. One

Neelu: Yeah and see many times I have I have so we you would have seen like if you have been on the offsec side, it's not that the tools don't find hundred percent of the issues which are there. They find what they can find and they give you. So like everything always should be taken with a pinch of salt. Like it's it's never hundred percent coverage with security.

Host: Yeah, yeah. Yeah. But often what happens is like you gave a very good example, right? That when like for the project that you're working on, you started with SCA and you saw so many findings, and you go in front of a 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, right?

And if you are saying that it's a must that you have to fix, let's say a 20, that often impacts the velocity of the engineer as well. So the on the on similar lines, Ashis has asked a question like especially in the agent driven development world that we live in, how do you sort of calibrate, how do you adjust your product security strategy so that the engineering velocity doesn't get impacted?

Neelu: I think it's a 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. seventy, eighty points a week is a lot.

Like if you're if you know the points way of calculating or I think There is a lot of pressure for deliverables, and it this is something that we should look at because time is currency when it comes to faster developments, and that will be for ingenic development also. If you're using more ingenic developments, you will have agentic pods.

Yeah, I mean this is this is not like 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? So first of all, coming back to the human system, which is much slower than that. When you're looking for time being 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 product you're securing product teams, 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 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 CI CD 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 and embed security requirements where you can have maximum impact on thousands of developers or maximum developers that you have?

So these look at these concentrated places of 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, very, very few of us. So, where is it that you can put in these controls so that you can impact the maximum set of people? And third, when you are in the team itself, one is guiding them to these security baselines. So, one of the things that we were talking about in in in the talk that I gave on 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 hundred percent, but it will be very, very effective on a day-to-day basis. So think of this 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 it's like for example, when you have something like dependabod renovate, where they upgrade that sends you an PR or an MR, you know, 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 internet teams to help develop that and then share it with the rest of you know the hundreds and hundreds of teams or thousands of developers.

Host: Rest of the orc, yeah. Yeah, yeah. No, that that's a very good suggestion that you share, right? That instead of completely bringing a new thing or changing how the engineering is working, you're along s working sort of injecting security into it, so that they don't see this as a completely new way of working, rather it's sort of co-work co-lips together and and you are sort of building a security secure artifact or secure like golden image let's say in your case in your example right you're not completely changing the process rather you are saying that hey maybe add some checks and then improve the image to make it a golden image so you have security baselines there. makes sense.

One question I have is like do you how do you see AI being leveraged to develop some of these security practices or security tooling. do you see AI can help or if yes, then how?

Neelu: So yeah, I think a lot of this which I said was 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? is of course one of the places where you can use AI. 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.

You package it for the platform or create a module, for example, that gets called by the plot platform every time developer is running something. can you have checks in terms of 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 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 a centralized system and then AI can help you the entire leg. 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 to not just for day to day maintained tasks but for for all of the strategic tasks as well because now you have much faster engine.

So I I'm reading a like a an engine that can be used in any direction that you put in. And can because it there's no there are specific ones like for example if you have access to mythos or you know mythos, I don't know how you pronounce it, you can just focus it on security engine rate, 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. Or of course attack you can use the normal models also. We'll give you some good level of results.

Host: Yeah, yeah. I I mean mm o on a lighter note, like there a lot of folks I speak with, they have that confusion whether it's called mythos or mythos. So I don't know what's the right way to say it. but a good thing that you pointed out like when it comes to using AI and sort of 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, it follows it knows that what organizational controls need to be checked against or what in real time you can do the correlation and find out and maybe remediate then then and there itself.

So this week there was forward cloud sec in Seattle and one of the talks was given by Prahathess from XAI. And he was talking about paved roads for agentic development. Like nowadays everybody uses agents to write code and build products.

How can you infuse your own security controls, organizational policies, right from right into the developer's ecosystem or developers' world so that whatever code is getting generated, it knows what controls it needs to cater to what policies it needs to satisfy and things like that. we we'll share that as part of the show notes so that our audience can listen in as well. But yeah, to it sort of matches with what you said, right? Like how do you ensure your organizational policies are also infused so that security is coming from get go rather than again it goes through the pipeline and then you're going in a cycle, right, at that point.

Neelu: For 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 of course ideas around you know and things that some of the things that I've tried as well is that when you're talking about paved roads for a gentic 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 you need to have.

But there are some specific components when it comes to agentic development, right? Which you have to be aware of. 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. Okay.

And different organizations you may be calling it differently, but More like the place where it's like an artifactory where you'll have all your AI tools, AI tools. AI tools, I'm saying a very generic world. 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 artifactory 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. there's there are marketplaces for that, a lot of those are created in an open source manner, some of those are proprietary.

Host: Organizational practices, yeah. Yeah.

Neelu: 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. Now think of it in the context of AI supply chain.

An AI supply chain is 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 agents? Do you register your agents whenever agents are created? Because agents, there's a lot that agents will do. 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? So that is one component of the entire scheme. there are other things, like for example, you will have your gateway, gateways itself, right? You will have maybe the agent-to-agent, so eight to a protocol, you might have heard of that. Google came up with where agents are talking to each other, you'll have agentic gateways, you will have LLM gateway where your system is interacting with the LLM.

What kind of controls do you need for that traffic, the agentic communication with the LLMs, right? So there is an entire set of controls there. there's also the agent runtime.

But because with agents, now that you are executing essentially any instruction that's coming in, does the agent execute in a sign sandbox? Is there isolation for that? is there ephemerality where you know just agent executes and like more like a in a containerized environment, and you know, then every time there is a fresh one that is spun up. So all those considerations are 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 it context needs its own security, which is not the the traditional security, right? You have to look at context in the sense of not just in terms of storage and memory that context has. So there's a lot of different kinds of memories that constitutes a context management system. How do you identify the context? Can you trace the context? how does it link to the previous context, right? 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 agent in development. So I think these are very fundamental pieces to just agentic development that are relevant to security.

Host: Hm. I can I can clearly see where like you are excited and where you have been spending a lot of time learning and building around. so one question I wanted to ask, like you have been in the security industry for a while and what keeps you motivated? It clearly looks like Gen EI and the challenges that it brings in, it is keeping you excited. any any other area like

Anything else that keeps you going in in security space?

Neelu: Yeah, I think I I was in security earlier for the you know the the thrill of hacking. and that was that was so lovely because I think it kept changing from time to time. You would have new systems and you would hack new systems, and I think now it's the 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 this I think it's the change in technologies and the challenge that comes with it is what keeps me going. I don't know if others would relate to it.

Host: But speaking of change in technology, 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?

Neelu: I think so on a lighter note, we do very well when you focus on on one layer. So initially we solved for, and I'm saying it's not an ideal way in the way that we solve when we say that we solved that we productize, right? We productize and we have a bunch of tools in the network layer already. When the network boundaries were considered to be the point of threat or threat entry.

And then we moved to the web apps application layer and then there are a bunch of products that came in. and that's how it 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 and infrastructure as service and all of that and then we we evolved there where we are I think we have evolved because we have automated a lot of this and it it applies to a lot of individual security teams also. The more you automate, the more you reward because you can think of more complex problem statements for security in the org and the business. But I think it's also important to keep the keep the larger context in mind.

Like you cannot have an ASPM or just a CSPM and think your cloud is secure.

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

Host: Yeah. Yeah. Yeah right. Yeah right. And and going back to what you started with also, right? That these products and all they cater to certain controls. So you 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 mm nowadays as you highlighted just a few s minutes ago around AI controls, right? How do you do for context? How do you do for LLM? How do you do for agents? Like all of these are sort of new controls that you have to think about on top of the foundational controls for your organization. so yeah, the that makes sense. And that that's a great way to sort of end the security questions as well.

Before we end the podcast though, I have one last question for you. do you have any learning recommendation for our audience? It could be a blog or a book, podcast, anything that you would recommend.

Neelu: Of course check out the breakpoint security podcast. but beyond that I think recently there have been a lot of changes in the AI domain and there is a lot of sources that I see. I think for anybody who's interested in AI and especially in security, we must be aware. There is a there is a very good resource that I've found this It runs it's not like a podcast, it's more like a like a mini conference, but they discuss very cute 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 products.

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.

Host: Hmm. Makes sense. Yeah, we'll definitely I'll check out and we'll also add it to the show notes, your podcast and also AI Engineering YouTube handle so that our audience can go in and sort of subscribe and learn from learn from that as well. yeah, with with that I think we come to the end of the podcast. Thank you so much, Nilu for joining and sharing your knowledge. And I I see that like even after

close to two decades, you're still excited because there is a new chapter in a way, right? Or new ecosystem is getting built and how do you how do we secure that or how do we stay ahead of it? So yeah, thank you so much for coming to the podcast and sharing sharing your learnings.

Neelu: Yeah, thanks. Thanks Purushwatam for having me and have a nice day.

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

Neelu: Thanks. Goodbye.