Loading summary
Transcript45 lines
- [00:02]
A
You're listening to the Cyberwire network powered by N2K.
- [00:14]
B
You have to meet where these tools generate which is ide. Like you know, if you take it simply like a spell checker, right? Like you should have a security checker as you are developing or AI is developing code recommend the, you know, connections right there. That way you are able to find and fix a lot of I heard.
- [00:33]
A
Prevent first and AI is changing the way application security is working and you have to think about it differently. It's always better to plan ahead rather than, you know, end an incident in production. If you plan correctly, you will need and you will sleep better at night. By the way.
- [01:12]
C
Today I'm joined by two exceptional leaders from Palo Alto Networks. Sri Tajir, Vice President of Product Management, has led security strategy and R and D across multiple global security organizations, driving advances in application security and DevSecOps. Kriti Vasan, senior Director of Product Security, is a veteran in AI, cloud and application security with deep expertise in software development lifecycles and scaling security teams. Together, Sarit and Krithi bring complementary perspectives, one from product innovation, the other from product security on how organizations can move from reactive fixes to prevention first strategies, how AI is reshaping code security security and what it takes to evolve DevSecOps maturity. This conversation is about aligning speed with resilience and why now is the time to rethink how we secure development. Suret Krithi, welcome to threatvector. I'm really excited to have both of you here today.
- [02:19]
B
Thank you David, Great to be here.
- [02:21]
A
Hey David, great to be here.
- [02:24]
C
And you're at headquarters today. Normally you're coming in out of our Tel Aviv offices, right?
- [02:29]
A
Correct. I'm in headquarters today.
- [02:34]
C
Serila, actually, let me start with you. What drew you into product management and security leadership? You know, really across so many innovative companies. We're fortunate to have you here with us at Palo Alto Networks.
- [02:46]
A
Thank you. So I will start from my background. I started as a developer and I was a team leader and kind of an engineer for a long time handling all this crazy stuff of application security just from the user perspective. So I spent a lot of nights trying to fix all these issues usually before production. So it's kind of got into my mind that I have to provide something that will be easier for developers and will still keep the security level that we need within larger organizations as we serve today. And once I understood that I want to go into product management, I kind of did different things around security for image scanning, for cloud security for application security. I really feel that I am on a mission to make it simple. And I would say that developers and application security will leave ever after, but at least they will like each other. And I'm very glad to have Kriti here as well. He's a great partner for our journey for a best application security product.
- [03:58]
C
I think when we were talking about this episode, we were saying number one customer, right?
- [04:03]
A
Yes.
- [04:03]
C
The customer inside the house.
- [04:08]
A
Gives the best feedbacks and also open most of the bugs.
- [04:16]
C
Well, that's amazing. I remember giving or being given an opportunity to go into product management with IBM and then things changed and I stayed in design, but I too had that mission of like, how do you find the balance between an incredible product but a significantly better ux? And that's probably better left to somebody with your talents than mine. So that's an awesome story. You know, Kriti number one customer. But let me take it over to you. You've built and scaled product security teams across cloud, AI enterprise environments. Obviously what motivated you to focus on AI and product security here at Palo Alto Networks?
- [04:58]
B
This is fantastic question, David. Glad you asked. This is exciting times for a security practitioner to be in. In the times of AI. Why AI is a force multiplier. That means attackers are using AI. You see well crafted phishing emails, attackers adversaries using AI to find vulnerabilities in minutes. It is very, very important for security teams to use AI to respond faster because you need to AI to define AI based attacks. That's one the second in Palo we use AI powered products, our own products. We call it drinking in our own champagne to one analyze terabytes of data, detect anomalies, automate response. My role ensures that make our products secure using our own products. That's why I called it drinking our own champagne. That's one part. The second part is, hey, when you introduce AI into the development lifecycle, it opens up a different set of attack vectors. Right. So data poisoning, prompt injection, model inversion attacks. So how do we inject AI early into the development cycle, AI security early into the development cycle, Give the engineering tools, the necessary security tools process to achieve this security bug design within the new development process. So that is why I'm saying it is super exciting times to be in here right now, to be in this industry when AI is in the forefront.
- [06:40]
C
Absolutely. I mean it's a big, big job and an important one, but I think it's also one of those things that lights us all up here. And man, I hope that we're able to get it right because it's moving so fast and there's so many of us counting on the, the work that both of you are doing. And I think that's why I was so excited to have this conversation today. So today we're going to be talking about prevention for security, AI's effect on code velocity, and what it takes for organizations to drive cultural and strategic transformation in DevSecOps. Both of you have built these really impressive careers shaping Product Security and DevSecOps. Sarit, let me start with you. What's a key lesson from your journey that shapes how you approach application security today?
- [07:35]
A
So it's kind of a changing method, I would say, in a way, because if we think about application security back in the days then developers were writing a code and then the code was scanned after the fact. Usually when there were builds, the builds were not that often. And then usually you will get your problems only later in the process, if at all. In most cases. And this is also coming today, things were not blocked within the prs or the build process because when you think about developers, they are very unique and usually you don't want to hurt their velocity and you say, okay, we will develop as fast as possible and see how we can actually mitigate some of the problems later in the process. However, if you think about it, if problems arrive to production and you try to fix them after they are in production, you usually meet a developer like three months after he actually wrote the code and he may not remember what he wanted to write there and what was the meaning of the code or how he should fix it. And eventually you spend much more time on trying to figure out who is the ownership, how to fix it, build again, ship it again to production. And basically this was kind of a vicious cycle till now that everything is going into production and you have to figure out what is the problem, how to fix it, who is the owner. We do see a lot of customers understanding that it's not about trying to fix it in production, but trying to prevent it beforehand. Because if they meet the developers at their system, whether it's in their IDE or when they submit a pull request, then the developer itself can say, oh, okay, I know how to fix it, I can do it now, I don't need to wait for something to be shipped and deployed, only then fix it. And this becomes something which is much more urgent in a way. If you think about all the vibe coding and the fact that developer is no longer the only responsible for the code that is being generated so you must make sure that you fix it as early as possible or even create it securely early as possible.
- [09:56]
C
You know, when you're talking about this, I wish that that mentality had been available back in seventh grade math for me. And it occasionally showed up when Mr. Gawker shout out to Schmucker Middle School there, would sit down with me and watch how I was going through math problems and he'd correct me at the point that I made the mistake, not at the point that I turned in the work or the homework so they understood how to stop making that mistake in real time. And what you're talking about has a different level of implication when you're shipping code, when you're shipping an application and you're counting on your qa, you're counting on the teams after the fact to catch it and route it back and get it fixed, not only are you losing velocity, but it seems like you're enforcing the same mistakes to be made over and over with a really slow feedback cycle. So it's amazing to think that that mentality shift is available to the teams here and maybe it'll show up in middle school math classes everywhere. Kriti, let me take it over to you. How does that resonate with your own journey building and scaling product security teams?
- [11:05]
B
I agree with Sarit 100%. I used to be a developer before I moved into security, so I understand the landscape. Traditionally, security, you will build the application you go to, go live. Then security comes and scans and say, hey, here's the 50 things you need to fix. It became kind of a blocker for things to move faster. The biggest challenge was always integrating security early in the life cycle to address the vulnerability. So our shift approach with great partners like Sarit building amazing products is to streamline AppSec, integrate it early into your development process, id pre receive commits integrating with source code management systems give real time visibility to the developers who are actually the owners of their applications. As Sarit said, how do we automate? Instead of saying here is 10 things, can we automate fixes? Can we enable developers to fix while they are developing the application? Was the success here. And the second thing, what we learned is the toughest thing for any secure team is to find the right owner. When you integrate early, you are able to address this with the right stakeholders and the right partners, which actually helps you accelerate the vulnerability fixing process too. And this is kind of the central mission of my team at palo, make sure all the vulnerabilities are identified, fixed and addressed before even it gets released. So that's kind of, I feel, is the right way to implement shift left in the industry.
- [12:41]
C
So let's jump into application security, posture management or ASPM for those who have a lot less time. And then thinking about some security backlogs. A lot of organizations face this overwhelming security backlog. Millions of alerts with maybe only a fraction of those remediated. Why does that problem still exist and persist so prevalently?
- [13:08]
A
So maybe I will take this one. Usually when you write code, you add more vulnerabilities. Like code come with vulnerabilities come with more security problems. When customers or companies look at this and say, okay, I have too many and I cannot actually block anything, this is quite a challenge because they say if I will block something, it will block the entire pipeline. So I will block the entire velocity of the developers. I will never be able to shift anything to production. And this is super scary if you think about it. When we talk about how this should be managed. It's a journey. And application security maturity is a journey. It's not something that you do once and then it just solves anything. The idea is to build it in steps. For example, the first step should be, and this is something that was implemented also in our company is let's first stop all the new stuff from coming and then try to see how gradually we can also fix some of the backlog and some of the technical depth. But try to fix first all the new stuff is very important as a method to be able to actually solve this problem. So this is one issue. The second one I would say would say is more about remediation. Like how do I do remediation? Is it simple? Do we give the users all the steps to remediate things? Do they know how to remediate it? I would say that when you look at kind of the evolution of all these application security scanners, they focused a lot on finding the problem, but not necessarily helping remediate it. And I think these two barriers of just overwhelming number of issues and the fact that the remediation is not simple is something that kind of become very hard to maintain and fix and keep the level of security needed for a.
- [15:08]
C
Company that makes sense. Krithi, let me take it over to you. How do you help executives and security leaders reframe that backlog reduction as a real strategic priority rather than just this like technical work that needs to be done and maybe ignored to actually help.
- [15:31]
B
Frame a security vulnerability to a business executive, we need to talk to their language, need to translate vulnerabilities into a business risk or a reputation list or a loss of customer trust. So I'll give you an example. Say instead of saying hey, there are 50 vulnerabilities in your product or an application, you should say hey, here are five or ten top issues. It doesn't get addressed, gets turned into a product vulnerability which in turn results loss of customer trust or a competitive disadvantage. That helps. Say hey, this needs to be prioritized along with the release. That's one way to look at it. Second, is every vulnerability priority? Probably not. One way to do that is to have smart prioritization. Is it external facing? Does it have customer data involved? Is it like a public facing application? So you add this framework to actually say hey, out of this 500, here are the five things you need to go address before you go live. See that kind of helps get you executive buying. Second, for the engineering or engineering leaders, you need to frame this differently. Instead of saying hey, I needed to fix this 150 Jira tickets, you're going to say hey, let me give you golden templates, let me give you secure base images, let me give you automated pr, let you me give so that you can actually burn down the backlogs, you can prioritize the business critical bugs to go fixed and then you can move faster without compromising security. In Palo Alto Networks we actually embrace this shift left strategy, integrating our own products into the CI CD pipeline which helps developers get real time vulnerability visibility, enable quick fixes, drastically reducing the security backlog and then boosting developer productivity too. Which is which is kind of always not much spoken about, which I think is a very important metric where security teams can use it to get more adoption.
- [18:08]
C
I'm wondering how you balance that prevention first mindset in an environment that is so intense, intensely focused on the build and deploy of new AI capabilities. It sounds great, but there is a lot of pressure from the business to not just keep up but to land that innovation. What's your perspective on balancing the speed with the prevention that you're talking about?
- [18:39]
B
So I would frame it a little differently. So the key is you have to go from manual to and reactive process to automated and proactive process. What do I mean by this is for example, developer normally develops codes he commits into a source code management system, a build get run and then it gets deployed. The more closer you get to the developer, the better outcome you're going to get. That means you have to one integrate the scanning well ahead before something happens. That means it has to be part of your commit Process or a build process. Second, you have to empower developers with the right frameworks. As I said, golden templates, security tools, process integrated early gives you that advantage. Also, automating PR fixes like what our tools does gives a lot more developers power to address this. And then this becomes more a reactive process to a more proactive process and then more from manual, where security teams used to do it at the end of the cycle, to a more proactive where it's constantly being scanned and constantly being addressed before it gets even built and deployed. So effective in TLDR is Automate, automate, automate as part of the sdlc.
- [20:01]
C
Sree, can you talk to me about how ASPM and context aware controls help ease that transition?
- [20:09]
A
So the idea is that when you think about the overwhelming amount of issues we have in application security, you think about the code. And usually when code is being written, there are some things that go into testing, there are some things that not necessarily go into your application. And if you look only at the code, it will be hard to do to understand what need to be prioritized. There are of course, things that can be done on the code side. When we talk about aspm, the idea is that we take the prioritization from everything, all the signals we have within the system, and the fact that we also see the entire production environment, that we know exactly where the container or the VM is residing, whether it's a production environment or a development environment, whether it has an access to the Internet or not, whether it contains a sensitive data yes or not, if it has an excessive permission. So there are a lot of signals that we can take and say this is the environment in which your code is going to be deployed. And because we know that, we can say, okay, so issues or problems on this specific code base has to be solved earlier than others. And this is a major part in trying to prioritize the way we look at things. And it's also the way we do the policies. Like we take all this information into the gardeners and say let's block first for all the things that are more risky than others. And SPM come here and say not everything can be solved in the first hand. We have to prioritize in a way. And the way to prioritize is to actually understand how your application is going to look in production and take all this information back to the developer, back to the PR back process and understand exactly what need to be done to be able to solve the important things first.
- [22:05]
C
All right, let's shift our gears and start to talk about AI and code security specifically. You know, I know that AI is rewriting the rules of development. It's accelerating code delivery by at least 10x Sree. What security risk do you see this creating?
- [22:25]
A
So this is a great question. Actually it's not one, but it's few problems. So one will be that I would say the shift in responsibility. If you think about it, before developer was the one that's responsible for the vulnerabilities or the problems that were getting into the code. Now we have some kind of an agent that is writing the code and the responsibility is kind of being shifted between the developer and the agent. So sometimes the developer accept or reject, approve or reject things from the agent. But this will be the first one. It's not just a shift in responsibility, it's also a shift in knowledge. If I like I was a developer like a few years ago, then I knew my code, I understand exactly what I did and hence I could have remediated it. Now that an agent did it, this is kind of a surprising one. The second one will be if you think about agents and the way they even if they kind of have like MCPS and you add your scanners and you say yes, let's do scanning. It has to be done as a prerequisite and not a post one. A post scanning like we do today. Like today we first write the code and then do the scanning. In an AI coding vibe coding, it has to change, has to be part of the way you generate the code.
- [23:45]
B
And.
- [23:46]
A
And then comes some questions. For example, will the agent adhere to the requirement by the scanners? It's not necessarily happening. So this is something that we need to kind of take care of. And another one is the entire new attack surface that are being created by this wipe coding. Think about how cursor or windsurfer walking. Just an example. Of course they have an agent, they have the LLMs that they are working on, they have the MCPs, not all of them are secure. You may find yourself and Preeti can say that with a lot of MCPS servers that are not approved by your application security practitioners and they are not part of your organization approval whitelist or something like that. And then you may find yourself in a way that things the agent will do things in the computer that you are not protected from. So first will be the problems of the post scanning. The fact it's not longer only the developer that is responsible for. The second will be the new attack surface. Like there are MCPs, new supply chain attacks. So There are a lot of different areas in which vibe coding is bringing value by generating code velocity. Very important. But it also has a risk in which you have to protect your environment in a better way and make sure that you know exactly what is going to be applied to your code. How do you protect the users? So a lot of interesting stuff ahead.
- [25:22]
C
Yeah, you know, I was just on a interview with a research firm asking about AI and its usage inside of marketing organizations. That was specifically what she was looking at. And I think that alongside our, like different corporate trainings for security policy or for, you know, how to be inclusive, how to make sure that we're upholding our ethics and our values as an organization, there's got to be AI training. And I think what you're talking about is beyond just the regular security training of don't click on the phishing link and you know, stay away from some of those things that we see as patterns. But what are the types of things that are going to happen when you are using AI tools to accelerate your ability to succeed in a corporate environment? And what are the types of things that you open the business up to? And maybe that's not necessarily the path that both of you are, you know, thinking about, but I think if we don't see that in the training within the next six months, that there's been a massive miss because the amount of risk and the ease at which the risk is taken is. It's just, it's everywhere right now. It's actually quite wild to me. Kriti, I want to switch it over to you. From your vantage point in AI security, what vulnerabilities do your teams see that are often overlooked in that AI generated code?
- [26:38]
B
That's my favorite question actually out of in the podcast. So here's my take. Okay, so with the amount of choices developers have of using different models, different code generation tools, right. These are all built on functional correctness, lacks sometimes security context, so leading to many code related vulnerabilities. Most of the times we have seen input validation, missing, weak access control, hard coded credential. So it becomes super important one, to understand how these tools work fundamentally. Second, also we have seen because of hallucinations, models and tools recommending packages which don't even exist, which leads to typosquirting, recommending packages, older versions of vulnerable packages. So it kind of opens up an interesting perspective because you have to now detect everything at scale. That is what I say it is as a challenge and an exciting problem to go solve from a practitioner's point of view.
- [27:47]
C
Let's talk about economics and security strategy for a minute. Fixing issues in production. I think I've seen a stat that says it cost 100x more than just preventing them earlier. Why do you think organizations are still so accepting of that kind of inefficiency?
- [28:09]
A
I would say mostly because they are afraid to block the velocity of the business and not create. It's kind of blocking the things you know rather than the things you don't know. If you have vulnerabilities within production and nothing is being exploited, then you feel safe in a way. But if you think about it, today, developers spend a lot of time on security problems that come from production and again, they are the end of the chain. Like trying to get to the right developer is really a challenge. It is challenged by the AppSec teams, it's not challenged by the developers. Like the AppSec team needs to understand, okay, this incident or this posture problem, what happened. It's actually something that we need to track back, understand who is the owner, see if we can fix it. You're probably already working on the next version. It's not the one that is currently in production. So I think because it's not in one place then you don't necessarily see the impact in one group. But if you do look at it as a narlistic way of things, you will see that while you may spare your developers by fixing things when they were part of the development cycle, you will spend their time while they do it on the production. It's the same as bugs. If you think about it like the reason we have QA and testing is because we want to make sure that we find things before they go into production and before it's actually been malfunctioned on production. This is the same for vulnerabilities. We need to shift it left. And I do believe that once all these tools will be much more integrated, remediation will be simple and it won't take that much time, then organization will move to working much more in the developer area rather than in production.
- [30:04]
C
Speed versus security is often painted as this zero sum game. Krithi, what strategies have you seen work to achieve both speed and security?
- [30:18]
B
So first thing is to make sure security is an enabler. So for example, how I talk to executives is to say, hey, by integrating security early and addressing vulnerabilities ahead of time, you save X numbers of developers time to go actually develop new features which will lead you to fastest to market, which will lead you to competitive advantage. Right? The framing of how you implement Shift left to execute. This is very important. Second, as security is a differentiated, for example, if you do security well, if you do security well ahead of time, a lot of these security standards, if you build it right, is actually a very, very essential differentiator for business. For example, going, getting FedRamp certification, getting IRAP certification. So a lot of these are all have overlap. So building as this part of design and finding and patching everything ahead of time is definitely a business enabler. Third, empowering developers, which is very, very important. As I said, doing shift left is not only security, it's actually giving the power back to the developers to actually address these security vulnerabilities ahead of time. So combining these strategies I think is the right way to go.
- [31:34]
C
Krithi, you've built security champions inside of dev teams to drive cultural change from within. Can you give an example of one thing that you found works really well?
- [31:47]
B
Identify the right people. There are always great people with passion for security in engineering who has a lot of influence. Identify them, reward them, give them visibility, empower them with tools and then train the trainer, make them your wise eyes and ears. That's the best way to scale and I I've seen it work fantastically in networks.
- [32:27]
C
Thank you both so much for this really fascinating conversation and a little bit of strength stress as I think about the challenges that you're both trying to solve. And I appreciate that you took some time out of your day to come on threatvector today and talk to me on this podcast.
- [32:43]
A
Thank you very much.
- [32:44]
B
Thank you, David. It was a pleasure.
- [32:47]
C
That's it for today. If you like what you heard, please subscribe wherever you listen and leave us a review out on Apple Podcast or Spotify. Those reviews and your feedback really do help us understand what you want to hear about. Reach out to me@threatvectorloaltonetworks.com I want to thank our executive producer Michael Heller, our content and production teams, which include Kenny Miller, Joe Benecourt and Virginia Tran. Original music and mix by Elliot Peltzman. We'll be back next week. Until then, stay secure, stay vigilant. Goodbye for.
- [33:24]
B
Sam Sa.