Interview with Ilan Dar

Pratik Roychowdhury: Hello and welcome back to another episode of ProdSec Decoded, the podcast where we explore how product security and AI are reshaping fast moving enterprises. I’m Pratik Roychowdhury…

Chiradeep Vittal: and I’m Chiradeep Vittal. Today we are excited to talk with Ilan Dar, a cybersecurity executive who brings a unique dual perspective to the table. Ilan currently serves as CISO and Sr. Vice President of Technology Services, where he oversees not just security, but also product delivery and operations.

With over 20 years of experience spanning engineering, product management, and information security, he’s built technology teams at scale across companies like Avaya, Sphera, and Sybase, and has worn multiple hats throughout his career.

Pratik Roychowdhury: What makes today’s conversation particularly interesting is Ilan’s background in FinTech and his unique perspective of having led both R&D teams and security teams. We’ll explore how that dual vantage point shapes his approach to product security. We’ll dive into his journey from engineering leadership to security, explore the challenges of tool noise and alert fatigue, discuss proactive versus reactive security approaches, and talk about building scalable product security programs in budget constraint environments.

Let’s jump in.

Chiradeep Vittal: Ilan, welcome to ProdSec Decoded. Great to have you on the show today. You and I have, a common background is somewhat common background. I used to be in FinTech recently, and you are also in FinTech. I have quite a bit of experience in cybersecurity mainly on the tools and vendor side.

But you also have a ton of experience leading cybersecurity and engineering in the last couple of decades. So, great to catch up with you.

Ilan Dar: Yep. Happy to be here, guys. Looking forward to this conversation.

Chiradeep Vittal: So let’s start with your story. You’ve had this really interesting career arc from software engineering to you’ve done cybersecurity product management, engineering leadership. So what drew you into cybersecurity? And with all that engineering background on their belt, how has that shaped the way that you think and approach security?

Ilan Dar: Yeah, no, great question. I was always a curious kid. I think that’s something that’s a common thread for many of us engineers or folks that are in cybersecurity. So I was always interested to understand how things work and can I make them. Work slightly differently.

Or more optimal. And so that shaped my initial view into engineering and eventually led me into software engineering. When I was going through my bachelor’s studies in software engineering, I wanted to set myself apart from other students that were going to graduate because, at the end of the day you’re trying to find a job.

And so I ended up partnering up with a student that was going for his PhD and was working on his PhD thesis. And it was in the area of internet security. He was taking an existing internet protocol that was out there and trying to think about how he could secure that. And so what I ended up doing is he would do the research and I would do the practical aspect of that.

I would actually turn his ideas into code and try to prove out that yes, you could secure the internet. And from that point on that challenge thinking about that experience and a different view on how software can be created vulnerable, but yet you can also think about that security aspect, that started my career in software engineering with a focus on security. And so when you look at my career, yes, it’s interesting in that I’ve done everything from development to product management to IT and operations to pre-sales and now information security. It’s always been with the mindset of security, whether it’s operating in a security space as a product manager or whether it’s thinking about how I can secure software as I’m building it. And that’s really been my whole career. It’s been that passion of writing secure software, of thinking about software as an enabler, but something that can also be exploited.

Chiradeep Vittal: that’s pretty cool. I think you also do a lot of hack the box or capture the flag things in your spare time as well, so you really keep yourselves on your on the sharpest edge there. And what makes your perspective unique is that you’ve been on both sides of the equation. You have led R&D teams, that are supposed to ship products fast.

You’ve led security teams where you’re trying to make sure those products are secure. And when you’re sitting in those two different chairs, how do you view product security from those two vantage points? So the “let’s ship it” side versus the “Let’s secure it” side.

Ilan Dar: And it is an interesting dichotomy, right? Because I have one side of me that wants to move faster and I have another side of me that says, hold on, we gotta ship secure software. And I think a lot of times people think about those as having to choose between the two and I really believe that if you create the right culture and systems, those two concepts actually reinforce one another rather than combating. And so rather than thinking about do I choose speed or security, I really think about how do I enforce a security delivery at speed mindset. And so it’s really how do I bake that into the SDLC? How do I build a culture that thinks of security as a product feature, rather than a bolt-on. And if you create that mindset, if you create the systems and processes in place that really allows security to flow at scale as part of the process, then you are much better off. And you are enabling at the end of the day the business needs, which are ‘move faster’.

What executive is going to tell you, “Hey, I need you to move slower when it comes to product development”. No one. So I think that’s, again it’s this concept of they reinforce each other when they’re done. And that’s by building security from the ground up into the mindset of software development or product development.

Chiradeep Vittal: Yeah, and I think we have heard of this quite a bit from other guests that it’s quite often the human element, like getting the culture right, is probably priority number one, but I’m curious practically, how does that look in your organization? So you are both SVP of technology services and ciso, so how are you practically navigating those competing priorities?

Let’s give some concrete examples.

Ilan Dar: Yeah. We always talk about numbers, right? There are more developers than QA testers. There are more QA testers than there are security engineers. That’s just the reality. And you certainly, as you start looking at those abilities to move faster on the left side, on the ideation and value creation, you also have to think about how you prevent from your security team being a bottleneck. And so it starts with people. It starts with shifting that security mindset left. You have to have training. You have to create this culture of security champions - folks that are within the product development engineer organization that will try to uphold and adhere to those ideas and principles and standards that you’re establishing on the security side. You use a lot of automation. To me always, that mindset is automate as much as you can.

If you can’t automate, you delegate. And if you can’t delegate, then you hire. It really goes from that concept, if I can automate the process, I can make it scalable. If I can’t scale through automation, then I’m gonna scale through sheer workforce, again, enabling and training people.

And if I can’t do that, then I gotta hire those folks that I’m gonna eventually train and delegate to. But that’s, at its core it’s, again, as you said, it starts with people and then you basically try to get that mix of automation and delegation. Getting as many people bought into the idea and reinforcing your needs on the security side. Without that, security organization is just going to be just that - a bottleneck and or speed bump for value creation. When I look at how I view product security and how I look at providing value to the organization I think risk starts that conversation. You cannot have a flat view on ‘everything is a risk and we have to address everything’. And if I, even when I automate and when I delegate, I still have to prioritize. And so it starts from that risk side of things. if you establish the right guidelines around risk and risk tiering and what is acceptable and not acceptable, then you can prioritize, automate, delegate,. and then, achieve success that way.

Pratik Roychowdhury: So Ilan let’s talk a bit about the FinTech world, which is where you are right now.

T he FinTech world is probably, slightly different from the rest of the industries because there’s a lot of financial transactions you’re handling. There is regulatory compliance. They’re working with banks, lenders, and so on. So, from your experience, what makes product security, especially in the FinTech world, fundamentally different from other industries that you’ve worked with? What, what unique challenges do you see in the space?

Ilan Dar: Yeah. And so as you said, I’m in the FinTech space, but I’m even in a crazier subspace of that, and that is the automotive FinTech space. So in automotive, you have three entities kind of battling to own the customer experience. You have the dealers that want flexibility.

They want to be able to do things their way. You’ve got tens of thousands of dealers in North America, and each one of them when you talk to, are probably gonna do something slightly different. You have OEMs - the car manufacturers who want standardization. And then you have lenders who, demand an extremely high level of security standards and controls. You add to that, the automotive space is highly fragmented. For any transaction to occur, we need to integrate into at least 20 or more technology partners to provide those services, and then on top of that, you add regulatory pressures and requirements, state level privacy laws.

What you end up with is a very complex ecosystem to get anything done. And a bunch of rules that at times or needs that are at times at odds with each other when it comes to trying to secure the information, and the services, that you’re providing to your customers.

Pratik Roychowdhury: Got it. And talking about those integrations, which is a key part of the Automotive FinTech that you are part of. So you’re not just securing your own platform, but you’re dealing with all these partner integrations. There’s tons of third party APIs. There is risk coming from there, there’s compliance requirements. So how do you approach product security when essentially you are securing across this whole web of relationships and integrations and not just focused on your product alone?

Ilan Dar: yeah. great question. So, I think that conquering that complexity probably boils down to five key steps- again, we start from that left side of the equation. You have to have a secure by design code. So you have to have that right mindset around understanding, your threats, understanding what it means to be secure from the get go. You gotta have that mindset. API hardening, is the second block that I would put in there. Because again, every point of integration, every interface that you are creating is a new point of risk, whether it’s ingress or egress for those attackers, and so it’s really important that you think about that API, and harden it whether it’s identity management, whether it’s thinking about structuring APIs the right way and what kind of data is flowing through them, All things that you really need to think about hardening that, point of integration. But I think you have to think beyond the third party integration. You have to think in fourth party terms too. So again, we’re supply chains, and third party risks. When you start looking at that, you might consider your relationship with your immediate partner secure, but what about on their side?

What about the data that I’m sending them? How are they gonna take care of it? How are their third parties going to take care of it? And so on. And so, , really thinking about that software supply chain,, and, that vendor risk is important. And so that’s, to me kind of the proactive aspects.

So those three steps are the proactive and then there’s the reactive. You gotta have runtime protection and observability, you gotta be able to detect when something goes wrong, and of course, continuous validation of your configurations, of your controls, of your capabilities.

When you’re in a world where, again, we go back to CEOs demanding, move faster, but yet keep me secure, we’re no longer in that world of we’re shipping every quarter, we’re shipping every month. We are shipping weekly, daily, hourly. And so your software’s only as secure as your last bit of code that was pushed out into production.

So you have to think in terms of minutes and hours rather than days, weeks, or months, in terms of what you’re able to do and how you’re thinking about exposure or attacks that are happening against your infrastructure and your applications.

Chiradeep Vittal: I certainly never thought about fourth and fifth and sixth parties before, that’s certainly novel to me, but let’s dive into something that’s, I know has been on your mind and that frankly keeps up a lot of security teams up at night. You spoke to us before about this whole app sec tool, signal-to-noise problem and alert fatigue that it brings. For our listeners who might not be familiar with this challenge, can you elaborate on this issue a little bit?

Ilan Dar: Sure. So again, when you’re operating in our space, and I’m gonna step away from FinTech. Let’s just assume you are in a SaaS world, where many of us have moved into, we want to, from a security perspective, have as much of a 360 degree view of what’s going on in our systems as possible.

So you’re bringing in a lot of information. Again, our ecosystems are getting more and more complex, which means you have more information that you have to bring in. That leads to a lot of noise in the system. The more data you have, the more noise is going to be created. And so what happens is you get all this noise that is bombarding your SOC team or your response team, your operational team. You’re relying on a lot of third party services. And so now your SCA tools are generating a lot of third party vulnerabilities that you’re pushing out to your engineers. So that creates a lot of noise. A lot of that is not something that you need to address. I always talk about there are signals that are informational, and then there are signals that are transactional, and I wanna be able to separate the two in that if I can have my folks know what’s going on, that’s the informational stuff, but them understanding that they don’t need to react to it. They may reinforce their learnings or observations, but it’s not something that’s an alarm, they can only focus on the transactional piece. Now, if you have too many things that are coming at you that are firing off as transactional, you’re missing, the forest from the trees.

You’re not able to react to the things that are really important. You are creating fatigue within your, employees, whether it’s on the security side or on the engineering side. And so that’s a real big challenge. And again, as our systems become more complex, as our ecosystems continue to grow, which I think is where the industry is going to in general anyway, then more noise is going to be created, and we have to be able to cut through that noise and get into the real signals. I use an analogy, , for people that are not in information security. Let’s assume you have a fire alarm in your kitchen. And your toaster is right next to where your fire alarm is.

And every time you’re, cooking toast, you burn that toast, ‘cause your toaster is just malfunctioning. And every time you’re making toast that fire alarm goes off. Pretty soon. Everybody that’s gonna hear that fire alarm is gonna stop reacting to it.

But what happens when your kitchen’s really on fire? And so, if you can create a situation, replace that toaster, make sure that your environment is set up so that when that fire alarm goes off, it’s truly something is happening that needs to be responded to. Now, you’ve built that trust. Now you’ve built that mindset in your team that when they hear that alarm going, they have to react, rather than that mindset of, oh, not again. It’s another burnt toast. If you have the right mindset, then you’re gonna react the right way. And that’s really how I talk about setting that signal to noise ratio, about really talking about getting rid of the noise and really focusing on the signal.

Chiradeep Vittal: Yeah, and I think what makes the situation worse is that the developers see that the alert is imposed upon them from an external team and that external team doesn’t have the context that they’re operating in, so, just makes the situation a little worse from their perspective. And so let’s talk solutions.

If you were designing the ideal approach to address this kind of tool, noise and alert fatigue, maybe you’re starting fresh, what would that look like? What would be your blueprint for solving the problem?

Ilan Dar: So I think you have to start with triaging before you alert. You’ve talked about this - understanding the context. Not everything is an alarm, not everything is bad. When it comes to third party vulnerabilities, we have all these tools that are generating all this noise about vulnerabilities in libraries you’re loading into your software, but how many of those are actually being used ? How many of those are you using the functionality that has the vulnerability. So you really need to be able to triage and then whether you do that through people or tools that’s really based on your capabilities, what’s available out there in the market, your budget, et cetera. But you have to start with triaging. You need to be able to separate that signal from noise before you start pushing that to others. And then you have to prioritize real risk.

Not everything is ‘the house is on fire’. And so, you have to look at all those things that you’ve triaged that are true alerts and decide what’s more important. What do you focus on first? Then you really need to integrate this into your day-to-day workflows. So how do you create a culture that is security and engineering working together and collaborating, rather than being disruptive. And so you really have to think about how do you integrate this into your SDLC? How do you integrate this into your automation workflows, your CI/CDs, and really make that become part of the everyday routine, so people really are working together and understand that security is an aspect of the product that they’re working on, rather than you’re trying to bolt that on as a, ‘oh, now I have to go and fix this issue’. As you create that environment to where you’re focusing on the important things based on prioritization and triaging, you’re building this culture of collaboration and working together, you have to share the wins together. It’s not a security success.

It’s a company success. And that reinforces that mindset of a shared responsibility of that camaraderie, and that culture that we are working together to deliver value to the business, secure products at the same time. That’s how I would say I would approach it. Now, there are other aspects beyond that, that requires investment in people, and the right tools that can automate, certain aspects of those things, whether it’s through the triaging aspects or the prioritization of risk.

Pratik Roychowdhury: So Ilan, I want to go back something that you just talked about earlier, and that is proactive or pre-emptive security versus reactive security. Obviously you need to have a healthy mix of both proactive and reactive . And you talked about, secure by design, API hardening, fourth parties as the proactive side, but, when you look at things such as red teaming and threat modeling and some of the other proactive things, how do overall define proactive security? Because, depending on who you talk to, the definition keeps changing.. And, I would also bring, something that you have talked in the past. You mentioned the closing of the vulnerability discovery gap, which means the time, between the vulnerability being introduced into the code and the time the vulnerability is actually discovered by the security team. So from perspective would like to hear your call it definition or way you would talk about proactive security.

Ilan Dar: Yeah. So, , my definition of proactive security is really a shift left mindset. How do you, anticipate, identify and mitigate security risks before they manifest as an incident. key there is that you need to anticipate. Where reactive is an event occurred and now you have to react to set event.

And so you didn’t anticipate that that event would occur. You didn’t put the necessary controls and so anticipating, identifying and mitigating it. And, that mitigation might be that you decide I’m not gonna put a protective control in place.

But I’m gonna put a detective control in place and I know what my action would be to resolve this before it becomes a true incident. So to me, proactive is that anticipation that you are prepared for it. You’ve thought through the risks and you’ve picked a mitigating set of actions or controls , that would allow you to either prevent that from happening or detect it very quickly and resolve.

Now you talked about closing , that discovery gap between , the vulnerability introduction and the detection. And so where I see the proactive mindset going hand in hand, our ability to anticipate allows us to be prepared, and if we’re prepared, we’re able to think about what is our playbook? How are we going to address these things so again, it might not be that I’m able to stop it or I might not want to invest in preventing that event from occurring, but I’m more prepared when that event occurs to mitigate as quickly as possible.

And so that starts with, if you can anticipate, you can identify, you know how to now see that event happening. And if you can see that event happening now you’re able to react to it a lot quicker before it becomes a complete fire. And, as our systems become more complex, as our ecosystems become more complex, there are more events that are happening, there’s more risks, and therefore we need to be able to anticipate and be prepared to react and mitigate.

Pratik Roychowdhury: Got it. And, talking about playbooks, if let’s say. a newly minted CISO or security leader is thinking about taking some of the proactive approaches, what would you say are some of the must haves that they should on focus on, the proactive side ? You spoke about shift left, but maybe some of the things that they should absolutely have when they are thinking about Proactive or preemptive security.

Ilan Dar: Yeah. Everything starts with risk, and so you have to establish, first of all, your risk tolerance, and then follow that with risk-based modeling, threat modeling, for your applications, your services, et cetera.

Because that creates that anticipation. You’re thinking about what could happen, You’re trying to anticipate. That also helps you with create better software. it makes your activities downstream much better. No matter what technology we introduce into our security workflows, human beings are always going to be the weakest link. And so I’d say invest heavily into employee awareness and education. That’s important. The more you can rely on people, the better. So you’ve got those tools, but, a mantra that we repeat to our employees in general, not just our developers, if you see something, say something.

And so they need to be able to recognize those situations where something just doesn’t seem right. I’d say the next thing is a supply chain management. There’s a heavy reliance on the supply chain and your third party risk that you really need to be aware of and manage continuously. , I forget what the latest stats are, but if you look even at small startups, the number of third parties that they are dealing with, or the supply chain members is gonna be in the hundreds. You go into large organizations, they’re gonna be in the thousands. Each one of those introduces a point of risk. So you need to think about your supply chain, your third party risk . The next would be continuous vulnerability management. If you’re looking to move fast, which is now an important competitive advantage, for organizations, then your vulnerability management, program has to match.

You cannot ship daily and scan monthly. It just doesn’t work. And then the last part I’d say is your incident response readiness. You’ve done your job in anticipating you’ve done your job at thinking through and preparing. Now, when something does happen, how quickly are you able to react and resolve? Those, to me, are the foundational, proactive controls that you have to, think about as a security leader.

Chiradeep Vittal: Yeah, I think, third party risk or employee risk, people risk is quite underestimated. At my last job, we thought we had secured everything and then we found that a CS rep was trying to steal data and sell it , on the black market.

And we never knew because we didn’t put DLP on contractors. And I think the FBI came to us and says, Hey, this person’s trying to sell your data. So it was quite an unpleasant surprise. But let’s, switch gears to AI and everybody’s talking about AI agents for everything these days. And certainly as a CISO I’m sure you get tons of pitches for cybersecurity agents in your to help, in your day-to-day tasks.

What’s your take on using AI agents with cybersecurity? Cut through the hype, what you actually see AI agents making a meaningful difference, in product security today.

Ilan Dar: I have to tell you, I’m as excited about the use of AI, as an operational aspect, whether it’s, for product development or for, security as I think I’ve been about anything else in my career. I’m kind of going back to that excitement that I had when I first learned how to hack. , And that’s that excitement that I have now for AI. I spend all my free time playing around with the new tools that are out there and thinking about not just how can they help, our organization move faster, and be more resilient, but I’m also looking at it from, okay, if I was to bring this in, where would the risks be? What are the cons of AI. But when you think about looking at AI and AI agent, and, , how I look at it from a cybersecurity perspective. And so again, my perspective is one of someone that’s balancing that delivery of value in terms of product development, software development and then security. When I look at AI, the first thing I think about from a shift left perspective is, okay, if my developers are moving fast, how can I have AI help them write more secure software. How can I have AI, act as that pair programmer, to help you define good patterns, to make , your product more secure - maybe even help with testing. And then when I look at AI, further down the chain, how can I do vulnerability management using AI agents, whether it’s, more targeted software composition analysis, or third party scans, making sure that I’m identifying just those items that are really vulnerable versus creating that noise. How do I use AI for DAST and SAST scanning really help identify true risks and then isolate the noise from there. And then when I think about when I deploy, how can I use AI for threat detection and response. And so, a lot of what’s going on in the industry now is really thinking about, rather than having policy or pattern-based threat detection, how can you create systems that detect threats based on normal use versus abnormal, or anomaly detection. And how do you create systems that now can detect that and potentially even respond automatically, and address those.

And so it’s a force multiplier to me. I’m able to augment my staff with this AI technology that can really help me secure my applications, my products, my assets from, ideation, creation all the way through deployment, and maintenance. It’s, a pretty exciting time for us, to be in this technology space and see, the beginnings of, AI, but also get to see the potential that AI has to really make things much better for us.

Chiradeep Vittal: Wow. That’s actually refreshing to hear that excitement. We’ve been hearing a lot of skepticism and, , “oh, this is too much hype”. So this has been a refreshing take on it. But flipping this around, we are also seeing AI create new security challenges. Everybody’s using AI for code generation, for vibe coding, and they’re also using, LLMs to add fancy features to their apps.

So what new security risks and challenges does this, code generation and using of LLM APIs create for security teams?

Ilan Dar: Yeah. So yes, you heard that excitement in my voice, but obviously there’s also that dread and worrying of the new potential challenges, or risks that AI present to us. One aspect of it is companies are sometimes in a rush to leverage AI, without thinking about what that means.

So again, I’ll start from the left side on the over-reliance of AI tooling to write code for you. Many of the AI models today that are designed for code generation, I would equate them to junior engineers. Junior engineers generally don’t write great patterns of code. That’s why you have the senior engineers sitting behind, training them, helping them, working with them. And so, the over reliance on AI to create software leads to vulnerable code patterns. There’s one challenge. Also when you’re looking at the models, depending on how you’ve set up your code generation and how they are reading your existing codes to modify it, are they uploading your code to the cloud?

Where’s your code sitting and who has access to that code once it’s been read and used to evaluate the code generation. So you’ve got this concept of we no longer have this problem around, secrets leaks in terms of credentials or keys, but now you’ve got your code being leaked out there potentially. And so you start with that, you think about prompt injections, which is something that people, haven’t really thought about until all of a sudden now everybody’s starting to roll out Google, Gemini. And first thing you hear right, is, hey, someone’s figured out how to inject, bad code or malicious prompt injection that could compromise you. So, you have these things that you need to worry about. Another aspect is user fatigue. So AI is used to complement and help you speed up. But unless you are thinking about speeding up across your full workflow, what you’re creating is now new speed bumps and constraints.

So, hey, your developers can, generate code at 10 x speed, but what about your code review? You’ve got more insecure code, which means you need more thorough code review. Can you rely on AI to really do that code review for you? Or are you gonna put more strain and pressure on your developers or your security engineers?

And then the last thing that I constantly think about is not all models are created equal. So you have vulnerabilities in models. You might even have poisoning of models that is occurring because again, you don’t know about your third party, fourth party threats. So all these things introduce new risks into the organizations that we need to think about, and we need to balance those risks with the rewards that we’re willing to get in moving faster, being able to, augment our staff, with these technologies that are gonna potentially make us more secure, with the risks that they’re bringing to the table.

Pratik Roychowdhury: So that actually brings an interesting question, and that is about budgets because typically new budgets really don’t get created. You have some sort of budget allocation, but in this new world where there is a lot of use of AI for security as well as, as you said applications are being built using AI and so there’ll be prompt injection, data exposure and so new risks are coming up. How are security leaders such as yourself, thinking about, budgets for product security in this new world of AI ? There are, of course, existing budgets, call it vulnerability management, technical testing, AppSec. Are those getting now somewhat reallocated to this space?

Or are security leaders thinking of, Hey, we need net new budgets because there are new kinds of risks that are coming up with the use of AI, LLMs, as well as different kinds of applications that are coming out.

Ilan Dar: Yeah, I think the allocation of the budget really depends on the company size, the stage of their maturity, the way the security organization or the technology organization is created, the reporting structures, the space. There are a lot of different things that could impact how we look at allocation of budgets. I’ve seen over the last 10 years, thinking of security budgets as just that. Is hey, it’s a security issue and you’re gonna need to figure it out. And I’ve also seen a mix of a product, it’s coming from your technology organization or your product organization. When we look at budget, we need to understand, again, it’s all risk-based and it’s all going towards supporting the business. And so you have to have the right leadership in place that’s supportive of security - so having that security mindset - and understanding that security is not a checkbox or bolt-on. It’s something that we think about that’s just as important as our marketing, our sales, our product development, etc.. And so you have to figure out if something is important, if you need budget because you’re investing in something you’re gonna have to figure out.

So you might say, Hey, I need this budget for these new tools that are coming from the introduction of AI tools for our development. That’s fine. And so, your calculus would be, well, I, from a product perspective, am now leveraging AI, and as part of that, I have to bring the tools that are going to allow me to use AI the right way.

So it includes both the tools, whether it’s things like open AI, cursor, et cetera and the other tools that are gonna allow me to have governance and controls over those new tools. It’s the full set of complimentary tools that I need to allocate and use. And so I might say, if I’m getting, a 2 x increase in productivity, I may reallocate that from headcount I had elsewhere that I was planning on budgeting to hire, or I might ask for a bigger budget increase in order to to be able to support that.

Every organization is different. Every organization needs to have the conversation of, if we’re going to do x, if we’re gonna introduce AI what does that mean to us in terms of productivity improvements? And what does that mean to us in terms of risk? And where should that budget come from? If it’s decentralized tooling, it might come from those organizations. So if marketing’s deploying an AI specific tool, we might go to marketing and say, you need budget for this tool to make sure that you do it correctly. But if it’s something that’s deployed across from an IT perspective, then you might just have that as a holistic view of your IT budget.

Pratik Roychowdhury: That makes sense. And are you, in general, seeing with the advent of AI and especially AI for security uses, are you seeing more prioritization on tools when it comes to budgeting? Or are you seeing that - Yeah, you know what you cannot not have headcounts. You absolutely need headcounts because agents are good but they need some direction, guidance and so on. Are you seeing that the focus on tools is somewhat increasing or it’s the or as same as before?

Ilan Dar: No, I definitely see organizations, leaning more towards, budgeting of tools versus headcount, and, look, the reality is we’ve heard plenty of announcements from big companies that are saying, we’re gonna cut headcount and we’re gonna leverage AI to increase speed, of delivery.

And so we know that’s real.

We can’t argue with the data that’s coming out. I think again, every organization has to think about their own needs. There’s always going to be a subset of headcount that you need. You need people. AI isn’t going to replace people despite what people think. What AI does is it’s a force multiplier. It’s a complimentary technology that allows your people to be able to produce more. And so, higher velocity. Everybody has a junior engineer at their fingertips whether it’s my CMO or my sales organization.

My salespeople have someone at their fingertips to do something. It enables us to invest into building tooling, internal tooling that we never would’ve invested otherwise, because the cost of doing it through our people is too high. at the end of the day, you still need engineers, you still need developers, you still need architects, you still need designers.

AI cannot do that just yet, so you cannot completely replace your people. There are those that would say you can ideate with AI without people. Yes. But whoever’s prompting the AI is acting as an engineer. They’re providing them with that aspect. So you still have an engineer, whether it’s virtual or otherwise, so you can’t get rid of your people. You could do more with less. And so the benefits you get from that are less lines of communication necessary. You are creating the ability for your backend developers to be able to work on the front end using tooling and vice versa. So you’re enabled them to move faster. so when you see that at the end of the day, executives are always going to lean towards investment in tools because if you can say, I’m investing half a million in tools and unlocking two and a half million dollars in product, creation value, what executive is not going to want to do that? And so you are gonna have a focus more towards tools, but , I hope, and again, I’m an engineer at heart. I don’t see us going away anytime soon. I just see us evolving into a different role, a higher level role. We started back in the seventies with, punch cards. We moved into assembly language where we needed to think about, registers, et cetera. We moved into C programming where we had to think about memory allocation and location and memory leaks. We moved into things like Java, and JavaScript, and Go, and all these newer languages that are, allowing us to no longer, think about memory.

We’re thinking about, structures and services. And now we’re moving towards what I would call prompt engineering, or intent development. It’s the idea that you thinking in terms of concepts and intent rather than in terms of lines of code and functions. And it’s great, but you still need to have the right architecture, the right design.

The understanding of systems, complex systems and integration points. those things are not gonna go away. AI is gonna help you delve some of the fundamental things, that you no longer need to worry about.

Chiradeep Vittal: Yeah, Ilan, this has been an incredibly insightful conversation. Your dual perspective is both a technology leader and the security executive, which by the way I also happen to have in my past life, really brings a unique angle to these challenges. Thanks so much for sharing ex expertise and experiences with our listeners.

Ilan Dar: It was my pleasure guys. Thank you.

Pratik Roychowdhury: It was a great discussion.

Ilan Dar: Thank you.. Thank you. Had a great time.

Pratik Roychowdhury: And to our listeners, if you enjoyed this episode, don’t forget to subscribe, share it with your team, and check out more conversations at prodsec.tv. We’ll be back soon with more real world insights at the intersection of product security and AI. Until then, keep building fast and stay secure.