Interview with Yisehak Lemma

[00:00:00]

Pratik Roychowdhury: Welcome to another episode of ProdSec Decoded. If you’re building modern software products, especially in high velocity environments, this is the show where we break down how product security and AI are evolving, not just in theory, but on the ground with real security practitioners. I’m Pratik Roychowdhury.

Chiradeep Vittal: And I’m Chiradeep.

Pratik Roychowdhury: Today’s guest is someone who’s lived and breathed product security across multiple industries, FinTech, ed, tech, media, and , others. We are thrilled to welcome Yisehak Lemma. He’s the former Chief Information Security and Privacy Officer at Instructure. He’s also led security programs at Get Upside Vox Media, MicroStrategy, and more. he has been tackling challenges from infrastructure to red teaming to privacy at scale.

Chiradeep Vittal: In today’s episode, we talk about the real world challenges of embedding threat [00:01:00] modeling into agile teams and how red teaming can change the way product teams think about risk, what it means to test for exposure instead of just vulnerabilities. I. Yisehak also shares his thoughts on securing AI driven products, aligning product and security teams, and what a modern security program should look like if you had to build one from scratch.

If you’re a product leader, security architect, or just trying to stay ahead of evolving threats, this is an episode you don’t wanna miss.

Pratik Roychowdhury: Yisehak, welcome to the show.

Yisehak Lemma: Thank you. Pleasure to be here,

Pratik Roychowdhury: how are you doing today? Happy Friday the 13th.

Yisehak Lemma: Happy Friday. Hopefully it doesn’t turn out that the, like the traditional Friday the 13th, but so far so good.

Pratik Roychowdhury: Right, So , , let’s get started. So maybe before we get started, I’d like to start with your journey. You’ve been in, you know, cybersecurity leadership roles across different industries Ed tech, FinTech media and so on. So maybe take us back to the beginning. What. Pulled you into [00:02:00] cybersecurity.

I mean, you have been in cybersecurity for a very long time and also would like to hear your perspectives on, you know, how have, how has product security evolved over the years while you were, leading cybersecurity in different companies?

Yisehak Lemma: That’s a great question. Well, my cybersecurity path is I would say, non-linear per se. But I took the infrastructure path as a system engineer, system administrator, really getting into how do you manage an infrastructure? And that is where I realized that turning point of my career and, and interest in cybersecurity because of the impact a single configuration can have on a larger scale in an organization and ability to execute an application’s performance could be impacted by one little error. And that, that is where everything changed [00:03:00] for me. And I realized in the security space, you really have the opportunity to work at the intersection of business and technology. At, at a core. I, I’m a big fan of technology, the impact, the efficiency it brings to organizations and that curiosity molded by how do we deliver high quality products increase efficiency in organizations, be impactful, and that’s where security ca became that pillar for me. , I quickly realized that no matter how much effort we put into something, if we don’t have a holistic view of the product that we’re supporting, the infrastructure that enables it. And of course the business stakeholders and the clients all kind of intersect at that midpoint of security. And that’s where things started turning for me. And I started getting into, I. Really the infrastructure side of security [00:04:00] firewalls and that evolution of web application firewalls and, and started expanding into the realm of application security, product security, and I would say the evol from the evolutionary standpoint of product security. In the past, it was more of a very reactionary thinking. We have a product, we have to support this compliance effort. Let’s make sure we scan, let’s make sure we have the ability to remediate these CVEs. And didn’t really think about the concept of product, per se, the lifecycle of building something. That is holistic or a system of things that actually make it, into a real life applicable solution. So the challenges in the different industries I worked at are slightly different, right? When you’re in the, the media space, it’s all about resiliency, scale, and visibility. ‘cause consumers are consuming [00:05:00] the content, real life and the speed to market for having ed tech environments tied to the revenue was very impactful and eventually. All of these turned into high traffic APIs. How do we manage these resources? How do we have, how do we build resiliency into our properties or assets? And that quickly evolved into other challenges in, in like the FinTech space and the EdTech space, which are different from a regulatory standpoint, from a compliance standpoint, data sensitivity changes and eventually realized that we can’t just respond to having a highly available infrastructure or checking the box from a compliance perspective. It has to be more holistic thinking, and how do we bring the right stakeholders to understand risk as it relates to product we’re delivering, and how do we make sure that we have [00:06:00] good decision making ability. That will help us identify issues earlier in the lifecycle versus significantly later. So I, that, that shaped my thinking in terms of how I look at product security, how I look at security in general, where it is more of a, a mindset approach where you think about it from. The whole versus the the minute and that that has significantly evolved over time.

Chiradeep Vittal: I think the mindset is a critical aspect of this and. Being a product leader, not necessarily a security leader myself, I’ve seen that security is quite often an afterthought or yeah, let’s invite the security team after, you know, the design’s done, right? Yeah. And so, so, and not only that, I mean.

It’s, it, it gets even worse, right? A lot of organizations [00:07:00] still approach security in reactive ways, you know, oh, I gotta do scanning, patching CVEs but I think, like you said, if you look at the whole life cycle, a lot of teams are moving into that proactive or preemptive security approach. What is your take on proactive product security?

And could you highlight how can organizations implement this kind of proactive security?

Yisehak Lemma: Absolutely. I like to kind of take, health analogy when I look at this, like we do a lot of proactive things in our day-to-day lives to avoid ending up in, in the emergency room, for example, right? Like eating habits resting and all of that. So I see security or product security proactive measures that you can take. Similar to that, where the idea is for us to be able to identify some of the risks earlier in the life cycle. And there are things that we could do in the requirements phase, the design phase to [00:08:00] start building the muscle memory of how should our product behave. And you know, it’s it starts with things like having security champions that would be embedded in teams that would ask accelerate these thoughts. There’s of course the application security pieces that we do that are now being introduced from a shifting left perspective, introducing DAST SAST into your CI pipeline. However, there’s that feedback loop that’s missing where how can we proactively identify threats? Are we doing threat modeling? And one of those things where it’s the most undervalued process that actually has strong impact into an organization’s product lifecycle from a security standpoint that is often left out due to the speed of market that is required and imposed on security [00:09:00] and I mean software engineering teams and product teams. So there’s a lot of cultural shift that needs to happen to bring about the proactive, like how do we nourish our product so that it is actually a good, healthy state and we understand the impact of how that could change. So measures as simple as we threat model something we understand at a high level the hypo a hypothetical risks, and then how do we take that hypothetical risk and get into, let’s really measure these hypotheses and see if our controls are effective. And how do we do that?

Like do we, we can bring in the traditional tools that give us point in time and the integration, or we can start red teaming to really take it from a, a hypothetical scenario and bring it into real life examples of how does an adversary then interact with our applications? Is this going to open up a whole new view [00:10:00] of how we see the product, how we see the vulnerabilities that are identified or the abuse cases in some in some cases that we didn’t necessarily identify. So it helps us stay nimble in that aspect and really get into baking in security as a first class. Part of the product ecosystem, product lifecycle instead of an afterthought or something we plug in at the end because we either are required to do it for compliance purposes or we are required to do it because having a pen test report might reduce our cyber insurance rates.

Like there are so many other factors that turn into. Noise versus the true value that these proactive measures can bring to the product.

Pratik Roychowdhury: Actually, there’s a, lot to unpack in , what you just said. There are, a bunch of things I, we would like to go over them, but I definitely love [00:11:00] the healthcare analogy that you gave because we should think of our, , health more in a proactive manner, figuring out what can go wrong and then doing stuff beforehand rather than going to a doctor afterwards.

Right. So I think that that’s a perfect analogy that, that you gave,

Yisehak Lemma: Correct. And I, it’s do, let’s reduce our odds of ending up in a, in a ER and being triaged, right? Like, and that’s typically what we see in, in the security where find ourselves, I. In front of an incident where we don’t know how to respond, even our incident response plans may go out the window because we never really had good measures to proactively test these things.

Pratik Roychowdhury: Right. And, and talking about proactive security. You also touched upon, , threat modeling and red teaming and we want to expand on that, double click on that a little bit more.

Yisehak Lemma: Mm-hmm.

Pratik Roychowdhury: Starting off with threat modeling, one of the things that we have heard is that threat [00:12:00] modeling is more of a continuous discipline.

It’s not just a point in time. Do it at the design phase and forget about it. That’s not the, goal of threat modeling. It’s doing it through the entire life cycle of the product. So , maybe would like to double click a little bit on that aspect of. Making threat modeling continuous, making it as a continuous discipline.

And also maybe while you’re at it, would love to hear about any, you know, challenges that you have seen. I mean, some of the challenges that we have heard is, hey, you create a threat model. Developers never incorporate that within their you know, product. And so it just lives in an island. So maybe would love to hear about, you know, the aspect of continuous threat modeling and any challenges that you have seen in your experience.

Yisehak Lemma: Absolutely. I think I, I alluded to threat modeling being undervalued earlier. The big thing is that I feel like it’s the most misunderstood concept, where products evolve all the time, new features are added all the time. [00:13:00] And so threat modeling cannot be a one-time exercise. It has to be baked into the culture of the organization, the product engineering and security organizations where they kind of work hand in hand. The challenges that I see is a lot of teams are busy. There’s they need to maintain high velocity. They are under pressure of releasing features and capabilities within the product, reducing bugs. So the biggest challenge in my opinion is how do we make sure that teams are finding the cycles to actually think about the product holistically and really getting into the question of why are we building this? What could go wrong and let’s understand our infrastructure and the components that we’re building holistically and, and spend a lightweight exercise on a continuous basis. Like, ideally, it’ll be integrated [00:14:00] into a sprint life cycle where you spend a, a small amount of time just having the right stakeholders chime in, right? Because. If you look at it from a security expert’s perspective, that’s going to be intimidating to other components, and it might turn into more of a hypothetical conversation where engineering teams may not necessarily be able to translate the value. But the more engaged teams are in terms of how do we incorporate this into an architecture review?

Like when you have your architecture design documents, how do we incorporate pieces of, of security thinking? Again, going back to the idea of shifting the mindset in terms of not trying to say no to feature sets or we are not trying to slow you down. But we’re actually trying to add value so that you can see that these abuse cases exist and let’s come up with them.

[00:15:00] And some of the, the, abuse cases that you see, or threats that are identified don’t necessarily come from the security team. It could be a product leader in their organization that says, oh user, could they do this, this capability. So getting out of the mindset that this is a security responsibility and making. threat modeling exercise, understanding the landscape that we’ll be operating in common use cases that we’re intending to build becomes the ownership of everybody. I think that’s, that there’s a big lack of ownership where security is the only one trying to maintain something that is continuously evolving.

In some cases you have multiple features being shipped in very short amount. Short amounts of time, there’s no way we that’s gonna keep up. So if you have a, a threat model that is few months old, it’s already stale considering the fact [00:16:00] that we are in a very high performing environment and we’re shipping code every day, new features are being added. And I think there are ways to augment these things where you know we’re in the age of AI, there are many other capabilities that would actually act as force multipliers in making this a culture shift in terms of how do we incorporate threat models? How do we feed it into our red teaming exercise? How do we make sure that our policies, procedures, controls, are all aligned and measurable? And I think that’s the missing piece where the value is not really seen, becomes is, is perceived as a bottleneck.

Pratik Roychowdhury: Makes sense. And I mean, typically what, in, in, in your, in your experiences, what are some of the signals or events that you have seen that typically prompted a revision of the, of the threat model? Is it, you know, new features, new dependencies, incidents, or, or something else?

Yisehak Lemma: I would say [00:17:00] my, my, my my favorite starter point is changes in regulation. I think privacy has enabled us to re-look at our threat models and has also added a, a sprinkle of accelerant essentially to help re revisit that model, right? Like, how did we miss that? We needed to have these requirements in place and going back and saying, we never even looked at it from, model perspective. This thing has been stale. We did one exercise and there are other factors that would lead into us revisiting threat models or sometimes it’s regulatory and sometimes it’s mostly large features that are introduced. That would force us to say, oh, security doesn’t understand how to respond to this. The intent typically in my experience, has been if you, if you have undergone an incident or you’ve [00:18:00] experienced a challenge where the security team was blindsided as part of a red teaming exercise or a pen test, then that goes back to the security team usually asking, we don’t understand your product.

We don’t know what it does. We don’t know where it lives. And these kind of go back to enable us to go back to the discussions of saying, how does this thing really work? Let’s, let’s talk about how do we fit all of these pieces together? Because do we even have the right proactive controls. Do we have the, even the detection capabilities and the response capabilities eventually. So there’s other drivers similar to that, that would accelerate that conversation. But typically it’s, it’s a very reactive thing where either responding to some external stimulus that says, don’t know this. We’ve never experienced this. How could we do this better? And as part of that life cycle of really going into lessons learned from incidents[00:19:00] lessons learned from other failures in, in our processes would yield into us revisiting that’s been. And it’s, it’s, it’s always a zero blame game, right? It’s, it’s has to be more supportive and welcoming. And that’s where the value add of security teams is realized. And the value add of threat models is also recognized.

Chiradeep Vittal: Yeah, and I think, I still think the current attitude that these are nice to haves and we’ll get to it when we have time, you know, that kind of attitude. And one more such feature I’ve seen is in red teaming, right? So the red team, we would love to invest in it, but hard to justify the budget. But it’s important, right?

They surface some blind spot which even the threat board may not have caught. How do you view red teaming as a function? Is it, are there any experiences you can share where your red team found issues before production or did it change how the teams [00:20:00] view the product risks?

Yisehak Lemma: well, I think the biggest value. Driver is really, do we have the ability, ‘cause we, on as part of our lifecycle to say our product is vulnerability free. We’ve patched that all the things that we’ve recognized and I think where the red teaming exercises provide significant value is they take all of the things that we’ve set. And put ‘em to a test. And there are times where all the controls that we thought were working and we’re able to respond to were nullified as part of an exercise and. In some cases, we always ask ourselves, were we lucky in finding this red team exercise or did we have a good process, a good capability? And there are times where we even found [00:21:00] problems where we, we never thought about that scenario existing. They, so there’s a lot of value that a good red teaming team provides in terms of their approaches in terms of really helping security teams, product teams and, and identifying scenarios we’ve never imagined because they look at it from a purely adversarial mindset and the security team brings some of that value.

But there are many involved in the product development lifecycle where we don’t look at it from a truly adversarial mindset. We don’t really have an opportunity to test all the things we, we think would work hypothetically. We’ll say, oh yeah, we have this rule that would fire off or. We’ll have these capabilities we’ve invested in that will help us proactively identify all of these issues. But once it’s in production, once it’s [00:22:00] delivered, that’s where the real test of resiliency comes in. That’s when the test of our incident response capabilities come in, and it really helps improve capabilities from both security implementations and also the mindset of product leaders engineering leaders to be able to say, how did this come about? What did we learn from this? And how do we reduce the impact even from a loss of productivity standpoint? Sometimes it will take, you know, multiple sprints worth of work to address some issues and that is, is significantly impactful to the teams because now they’re under double time pressure.

These proactive measures, really the value is realized once we find issues earlier versus [00:23:00] like once the product has been in production for several months and now we have to undo these bugs.

Pratik Roychowdhury: I I, I’d like to talk about something that you touched upon a little earlier about security being not just the responsibility for the security team. It has to be more like a shared responsibility be between the product and the security team. So, in that context, I mean, you have obviously worked in, you know, fast paced environments in SaaS orgs different FinTech orgs and so on where things ship quite frequently. Right. So, and one of the challenges that we have heard in such fast-paced environments is how do you embed security across the product lifecycle without slowing the dev teams down? Right. And when dev teams get slowed down, that is when they. You know, they will bypass security. So this whole devs sec friction or collaboration, whatever people like to call it, comes about. So maybe I’d like to hear your thoughts a little bit more around that aspect of security being a [00:24:00] shared responsibility. How can you bring in devs sec collaboration and maybe, what has worked with you in the past of how can you bring in the product, engineering and the security teams together without slowing things down and without making the environment less secure?

Yisehak Lemma: That’s a, a great question. And one of the biggest challenges I think any, product, and security team would face in, in, especially in the age we’re in now. But ultimately, I think it boils down to trust and being able to build fundamental trust between security and product and engineering teams. And in order to do that there has to be a method of that collaboration. I think engineering teams and product teams really want the best outcome for their product, right? Like they, they don’t want to have to deal with issues that come up later on in the lifecycle and slow them down. Security Championship really helps in that aspect. Having [00:25:00] that partnership, engineering leaders eng contributors product teams are actually seeing this as a partnership. And this, that’s where the security champions really come into play to enable, the cross-functional teams in terms of how we view risk ? How do we view introducing these tools ? So then the focus changes where if we introduce a new policy like infrastructure as code security policy, or something along the lines of like security policy as code that’s introduced in their development lifecycle, they’re contributors to that. Right? And just the same way that we are celebrating feature launches and capabilities, I think security enhancements and security guardrails that are implemented in pipelines should equally be celebrated as part of the security championship effort. That would accelerate the [00:26:00] partnership. That will increase the trust of how the teams are building. It’s almost like if you’re building a house and you have your plumber and your electrician and your roofer not talking to each other at all, and your drywall guy comes and puts drywall in, in, in your house without the, the plumbing being done first, it creates a lot of conflict and confusion and so in order to do these things right, there has to be a lot of communication and collaboration where things are laid out and teams are actually partnering to say, okay, let’s avoid this, policy because it’s not gonna add a lot of value, but let’s enhance it or tweak it so that we can now deliver software in a higher quality stake, a standard because we both contributed to that policy. We understand the impact. Security team is not coming with a hammer and saying, you have to have this static analysis test done because the certification requires it, or [00:27:00] compliance requires it. That becomes very friction heavy. Then people don’t really understand the value of why they’re doing what they’re doing and they’re not willing to collaborate at that point. It becomes a checkbox exercise, and a lot of the, the false positives will create a lot of the fatigue, the alert fatigue, the, the, the noise that comes out of the tools to require that partnership, to tune them to an acceptable level. All of that gets ignored. So real issues would start leaking into the production pipeline, creating further problems. So I, I, I strongly believe that establishing that, that trust, that security championship and that ownership where security team is not there to actually say, “stop or reduce your velocity”. It’s actually, “let’s make sure that we, we strategize a way that you can still inc, have high velocity [00:28:00] without by introducing these policies, these guardrails that make sense”. There’s, there’s a little bit of trade off negotiation that needs to happen. And of course the more engaged your security champions are, the higher the value where even engineering teams would start contributing more towards the enhancement of security ‘cause they realize the value later on.

And of course all of this, there has to be a way to close the loop all the time, right? Like you had, you did your threat model, you did your red teaming, you’re improving your pipeline tools. And all of these phases, security is not working in a silo, or engineering is not working in a silo. That partnership really makes a difference in my opinion.

Chiradeep Vittal: Yeah, great point. The, especially the point about celebrating security or more secure pipelines along with [00:29:00] celebrating feature launches. I mean, that’s a great idea. Having been on both sides as this product leader and a, you know, part-time security leader, have seen challenges from both sides and unfortunately, security has brought in a lot too late. And now the dev team, product team’s like, “ah, we gotta explain everything all over again to these guys”. And and then the, the trust and then the, yeah, everything drops at that point. So upfront is much better. At this point, you know, we can’t escape discussing AI. So let’s shift gears to that as more products integrate LLMs and Gen ai, what’s your take on AI in the context of cybersecurity?

What are some of the benefits and risks that you see?

Yisehak Lemma: Well, I, I, I see it in, in two. There’s of course, the increase in productivity or a force multiplier in terms of [00:30:00] leveraging AI to improve threat detection or automate responses or even add context a lot quicker. But there’s also the flip side where I think about it from how do you govern the ai, right?

Like a a, whether it’s AI agents you’re deploying in your environment or you are developing net new models, there’s a big data governance question that needs to be put in place. So are we leveraging AI to add efficiency to our environments? If so, do we have the appropriate guardrails and data governance strategies, data security strategies as we’re, feeding these, these models a ton of data, right? And there’s that AI security on its own, like security for AI versus security driven by ai. So I think there, there’s those two contexts that we have to consider. Then there’s also [00:31:00] the additional pressure that ai, advancement is bringing to the security team because the adversary, the adversaries also those capabilities that they can now accelerate the development of exploits making our jobs even more challenging. so there’s that speed that we need to innovate in terms of how can we use AI to accelerate the findings, the capabilities, the integrations that we’re using and how do we do so safely without overexposing ourselves? And that brings us to even, I think a concept that, like what does the shared responsibility model look like for AI and the AI providers and the consumers? That adds another layer of complexity that we have to address. [00:32:00] And thankfully there are many that are thinking about this across, across all of these vectors, but there’s also caution that we need to exercise as we think about establishing trust with our builders of the AI tools, the as consumers, how do we make sure that we have the right strategies in place to ensure our, the data is safe? The level of authorization that are, that is given to AI agents is also, adequate and well managed. And I think at the end of the day, it boils down to do we have a good governance strategy? Do we understand the problems that we’re trying to solve with ai? And how can we pinpoint it to measurable use cases that we can manage?

‘Cause if we adopt too early, then we’re opening up a whole new level of risk that’s not understood by the [00:33:00] organization, that would then increase risk significantly. So there’s that balance that needs to happen. But I do believe that there’s a lot of value being brought by what we’re seeing in the development of, aI agents LLMs that actually add a ton of value and context to how a security practitioner can use AI to, multiply their, their capabilities.

Chiradeep Vittal: Yeah, personally, I’m excited and scared .

Excited by, like you said, the efficiencies and the ability to be around and be a security champion all the time. And scared because there’s just new injection attacks, new kinds of attacks, which we haven’t even thought about. So overall exciting times. And and you’ve build security programs on the ground up.

I imagine it’s always hard to prioritize [00:34:00] security environment investments when everything seems critical. I would love to hear about how you go about designing your product security program. If you were to start from scratch what are the first two, three things you would invest in, especially given ai?

Would you lean forward in ai?

Yisehak Lemma: I, I think that’s that really depends on the context of the organization. and, current capabilities in other parts of, the domain, like how mature is the IT practice, how mature is the software development lifecycle? I’d ask these questions but in the end I’ll go back to pinpoint the idea of having security champions and embedded into the product teams and really accelerating the adoption of things like threat modeling and good standards where people can actually partner and scale. That’s where I would, make it almost a prerequisite where we start [00:35:00] embedding these things having good partnerships. Of course there’s always going to be the, the automation, the tools, the, the traditional and the new generation tools that need to be embedded into the developers’ workflows.

But also where AI I think would come in very handy is in terms of really identifying and automating like asset management context of applications and really taking that into generating playbook for threat models. How do we do continuous threat modeling in the environment? Like those would be high value add where I would focus on, so that way it enables the conversations; it enables the commitments to actually build a more secure product. So it’s, it’s more of like assuming there there’s a lot of maturity in other aspects. There are things that we, that can be done from an AI agent driven perspective, but, even if, [00:36:00] if that is not the case, there’s a lot of value in bringing in AI tools to be able to have a good context around the application. Good context around the health of the source code, the repos, the workflows the CICD pipelines. All of those can be identified. That would enable having healthier security controls and guardrails in place. So I think there’s, there’s a lot of value in, in the automation and the capabilities of AI to digest large amounts of information and, and contextualizing it to allow for engineering teams, product teams to start having partnerships with, with security.

Pratik Roychowdhury: That’s actually, you know, great set of advice. But as we wrap up Yisehak would love to hear any parting thoughts you have for product and engineering and security teams - things that product and engineering teams might incorporate. You talked about , incorporating security champions.

[00:37:00] You talked about some of the aspects of collaboration and so on. So any other parting thoughts that you have, which would make the life of security leaders as well as, you know, product and engineering teams, their lives much simpler and the product’s more secure.

Yisehak Lemma: I would say, I think we need to change our mindset. As, as security leaders, we need to evangelize that, you know, security is an accelerator, not really, it’s not going to reduce velocity. That, like, that shift in mindset. How do we integrate it in, in the right places with the right the right processes, is ideal. If we’re chasing vulnerabilities, if we’re chasing CVEs, then we’re doing constant band-aiding like constant patching, right? And that will in the long run, slow the teams down. So, in the short term, it might seem great, like, oh yeah, we burned down [00:38:00] so many vulnerabilities over the last few sprints, but that’s not scalable unless we start putting in proactive measures.

So I’d say bring security in early, like it’s security doesn’t mean it’s a show-stopper or naysayer. And from a security practitioner perspective, I think our role is to identify ways to enable the business. Instead of saying, no, we should be able to say, how do we do this? How do I enable you to ship this feature faster, better, more secure, let’s collectively come up with, with a methodology.

I think that that shift in mindset would really help accelerate, in incorporating concepts like secure by design, right? Like, ‘cause we are really saying from the get go, bringing security in early, having those security conversations, the threat models and the red teaming exercises really help take everything full circle and we’re not [00:39:00] working in silos and trying to find ways to comply versus, saying the product is secure by design. And we are able to demonstrate that and establish trust with all of our consumers. So that’s, that’s where I would say the, the big thing should the big investments and time should be.

Pratik Roychowdhury: shifting in mindset is, is the key and bring security early on.

Yisehak Lemma: Correct.

Pratik Roychowdhury: Well that was an amazing conversation, Yisehak. Thank you for bringing such clarity and depth to what modern product security really looks like. It, it was, it was great conversation and lots of good nuggets to take away from from this conversation for our listeners.

Yisehak Lemma: Thank you. Thank you for having me, and this has been a great session.

Pratik Roychowdhury: For our listeners, we’ll be back with another episode on securing fast moving AI powered product environments. If you enjoyed this one, don’t forget to subscribe, leave a review and [00:40:00] share it with your team. Thanks again for tuning in to ProdSec Decoded. Until next time, build fast and stay secure.