Encore: Reach for What You Preach: Bridging UX and Cybersecurity

Summary

---

Podcast Summary: Threat Vector by Palo Alto Networks

Episode: Reach for What You Preach: Bridging UX and Cybersecurity

Date: June 18, 2026
Guests:

• Host: David Moulton (Director of Thought Leadership, Unit 42, Palo Alto Networks)
• Guest: Dmitry Shvartzman (Co-founder & CPO, Prime Security)

---

Episode Overview

This episode tackles the persistent friction between user experience (UX) teams and cybersecurity, diving deep into how security teams can evolve from being “blockers” to becoming genuine business enablers. Dmitry Shvartzman outlines why integrating security at the earliest design stages is crucial, how automation and AI are revolutionizing security reviews, and the importance of compromise and proactive risk management. The conversation is packed with actionable insights on fostering better collaboration between product, engineering, and security stakeholders to minimize rework, reduce risk, and achieve smoother development cycles.

---

Key Discussion Points & Insights

1. Security as Business Enabler, Not Blocker

• Evolution of Security’s Role:
  Dmitry reflects on his journey from being the “Mr. No” in the room to championing business enablement via security (03:00):

  “I don't want to be Mr. No. I don't want to be the blocker to the business... How can I become that elusive business enabler that we've been talking in security about for the longest time?”

• The Challenge of Scalability:
  Manual security design reviews are unsustainable, especially with small teams and accelerating product cycles.
• Technological Advance as Turning Point:
  The advent of AI and Large Language Models (LLMs) enables scalable, context-aware security interventions at the design phase (04:41):

  “With the evolvement and advancement in technology... that kind of gave me the push to, okay, finally, I think the technology is there to get us to that spot where it all begins, which is the origin, which is the design stage.”

---

2. Mindset Shift: From “No” to “Yes, But…”

• Historical Barriers:
  Security has traditionally enforced checkpoints due to understaffing and velocity, often defaulting to “no” as a risk posture (06:31).
• Changing the Mentality:
  The ideal is shifting security’s answer to “yes, but,” where risk is transparently discussed and managed, not dumped on innovation (08:27):

  “What we want to get to is not, no, this is risky. No go. [It] is ‘yes, but’. And that's the mentality shift you can do if you introduce security to the earliest stages.”

• Meeting Teams Where They Are:
  Security must adapt to the workflow and context of design, product, and engineering teams, rather than forcing rigid processes.

---

3. The “Garlic Jar” Analogy & Risk Acceptance

• Learning Moments and Risk Appetite:
  Discussion of a viral video where a kid insists a jar of garlic is candy, learns firsthand, and the lesson is only internalized by experiencing (11:00–14:00).
  • Key point: Businesses sometimes need to take a calculated risk and even experience adverse outcomes before reinforcing the importance of security guidance.
  • Quote, David Moulton (13:51):

    “Sometimes you got to let the business take the risk... if they're okay with that risk appetite calculation, okay, you’ve let them know.”

---

4. Realities of Development: Expectation vs. Capacity

• Unrealistic Expectations Lead to Risk:
  Developers and product managers often bear the brunt of unrealistic expectations to handle core tasks, security, and more—something’s got to give (14:55):

  “That unrealistic expectation that we're going to take care of everything... Honestly, it's just impossible and really just unfair. So what happens? They prioritize. And...more than once, security slips.”

• Design Flaws Over Code Flaws:
  Security at the design phase is about deeper architectural risks, not just patching code or updating libraries.

---

5. Balancing Security with User Experience

• The Necessity of Compromise:
  Achieving optimal UX often means negotiating with security needs, and vice versa (18:36):

  “You will have to compromise on certain things unless you're willing to accept a higher dose of risk... Can we compromise in certain things in order to reduce risk? Yes.”

• Security as a Competitive Differentiator:
  As awareness grows, end-users and B2B clients increasingly consider security posture as part of their decision-making (20:40):

  “Security is now becoming... an important aspect of what the customers are looking for because the education is working and that security promise.”

---

6. The Hidden Cost of Late-Stage Security Fixes

• Design-Stage Security Prevents Expensive Recalls:
  Analogous to car recalls, late security fixes are costly and damage trust (22:39–25:30):

  “That rework is extremely expensive because we're losing business, we're losing development time... What if you could understand that during that design stage and reduce all of that friction?”

---

7. Security as the "Fourth Leg" of the Stool

• Integrated Role Across Product, Engineering, and Design:
  Security’s guidance should permeate every function, not just operate at the periphery (26:03):

  “We have to be involved in engineering, in design, in the business because the decisions that security takes on guidance when it comes to risk...can be as good as we are informed.”

• Necessity of Tooling & Automation:
  Manual oversight can’t scale—automation and contextual tooling are essential (28:53):

  “There's no way that it's not done in a manual way. Moving forward, that time has gone long past...It's shifting to a preemptive security by integrating through automation and meeting all the other functions...where they at with a forward looking approach.”

---

8. The Future: Symbiosis via Automation & Transparency

• Envisioned State:
  Dmitry hopes for frictionless integration of security into product workflows, enabled through automation, context-awareness, and proactive conversation—not by derailing innovation (28:53–30:30).
  • Security becomes an “enabling function,” guiding product and design with timely, relevant insights and risk communication.

---

Notable Quotes & Moments

• "[Security] should not be seen as...that, 'nope, you can't do this because it's too risky.' But rather how can we drive that innovation?" — Dmitry (07:55)
• "It’s not even...about having that conversation...it's the fact that that conversation doesn't happen because there's too many kids, too many jars, and usually one mom." — Dmitry, about organizational communication breakdown (12:52)
• "My code could be fantastic, but at the end of the day, I caused a security incident...That's why we're doing security design reviews." — Dmitry (16:35)
• "What if you could understand that during that design stage and reduce all of that friction, wouldn’t that be that much better in terms of pure time to market and cost reduction?" — Dmitry (25:19)
• "Moving forward it’s shifting to a preemptive security by integrating through automation and meeting all the other functions, be it design, be it development, be it anything else, where they at with a forward looking approach..." — Dmitry (29:09)

---

Timestamps for Key Segments

• 02:13: Dmitry’s proactive security journey – how “Mr. No” can become a business enabler
• 06:29: How development & security can meet each other where they are—and why that matters
• 11:00: “Garlic jar” analogy—accepting and communicating business risk
• 14:53: The pressure on developers and why security is often deprioritized
• 18:16: Striking the balance between security and a seamless user experience
• 22:39: Reducing costly “product recalls” via design-stage security
• 25:30: The “fourth leg of the stool”—security’s integrated role
• 28:53: The necessary evolution: automation as the only scalable future

---

Conclusion

This episode calls for a pragmatic, empathetic, and technologically-enabled evolution in product security—one that values early, automated, and collaborative engagement to balance innovation with risk. The key to future-proofing an organization is not in saying “no” to business progress, but in saying “yes, but” with insight, context, and partnership.

---

Transcript

[A]

You're listening to the Cyberwire Network, powered by N2K. So once those what I want to build, what I need to build hits the dock. Confluence, Jira, what have you, once that thought process begins and starts to form, that's when security needs to be involved. If that can be done, and it can be done as we continue to evolve with the capabilities, technological capabilities today, if that can be achieved, then I think the organization from a resiliency standpoint is going to be much stronger and the amount of rework and the amount of findings is going to reduce dramatically.

[B]

Welcome to Threat Vector, the Palo Alto Network's podcast where we discuss pressing cybersecurity threats and resilience and uncover insights into the latest industry trends. I'm your executive producer, Michael Heller, filling in for the intro for David Moulton, director of thought leadership for unit 42. Today, David is joined by Dmitry Shvartzman, the co founder and chief product officer of Prime Security. Dmitry is a security leader with extensive experiences in integrating security into the earliest stages of product development. In this episode, David and Dmitri will dive into the importance of meeting development teams where they are in their processes, how security teams can evolve from being roadblocks to innovation into being true business enablers, and how modern technology, including AI and large language models, is making it possible to automate security guidance at the design stage. They will also discuss striking the right balance between security and user experience and why security needs to be involved from the moment an idea hits the documentation.

[C]

Dmitry, your work focuses on integrating security into the design stage of development. And as a former designer, I'm actually really curious both what made you look at this as a critical area to focus on and then what inspired you to take this proactive approach and maybe tell me about how your perspective has evolved over the years that you've been doing this.

[A]

Well, you know that. Fantastic question. Thanks, David. And I'll start actually from the last part. I've been doing security for a very long time and it was very easy to be the Mr. No in the room, use the flag of risk and just say no and then explain that and then be like, oh, wait, but what did you really ask me to do and what did you ask me to approve? And I very quickly realized that I don't want to be that person in the room. I don't want to be Mr. No. I don't want to be the blocker to the business. I don't want to be the individual that blocks the business from moving forward and from accomplishing set, you know, activities and growing and all that great stuff. And it was very difficult because then the, the reality hit, which is we're always, as security people, we're always understaffed, we're always. There's way too much things for us to cover. So how do we do this? Obviously we all go to automation. Okay, but if I don't understand the business context at scale, then how am I supposed to help and be that function, that enabling function? And that was the main driver to get where we at today. We've been doing security design reviews since the beginning of, of essentially application development. Thing is, we've been doing this manually because we had no other choice. So the, the understanding of that business context and how to provide security was always done in let's get in a room or let's get on a call or endless calls or endless meetings, and let's manually review every single item that this group is about to develop or this product manager wants to do. And in today's day and age, let alone even back when I started, this is not scalable. You can't sustain this. So you are again, yet again, a bottleneck. And I just grew tired of it. And it was not sustainable in any way, shape or form. And that was one of the biggest drivers, one of the biggest passions. How can I become that elusive business enabler that we've been talking in security about for the longest time? How can I actually not only talk the talk, but do it? And that's when realization that with the evolvement and the advancement in technology that happened, especially the introductions of LLMs and ability to work with large quantities of data that are locked in unstructured sources, that kind of gave me the push to, okay, finally, I think the technology is there to get us to that spot where it all begins, which is the origin, which is the design stage.

[C]

So as I was preparing for the show and writing some of the questions, it took me back to, I'll say, a formulative experience that I had years ago on a design team. And each time we said, here's how we can make this application more delightful, get user engagement up, bring people in, actually hit those business goals that we were asked to, asked to drive. As the design team, we constantly ran into the security team saying, no, can't do that. That's a risk, that's a risk over and over. And it struck me that security is often seen as this barrier, barrier to innovation, especially for those design teams, those developers that are out there. I'm curious how those security teams can work more collaboratively with development teams and how the development and design teams can open themselves up to bringing design or security into their process.

[A]

You're spot on. Reason being is we've had historically to place these check holds, these checkpoints and again, it goes back to my previous point because we're, you know, understaffed and there's just so much in terms of velocity of development and what the business needs to do. And let's be honest, the business always wins, as it should be. Security had to create these checkhold points to make sure that we have a way to step in and say, nope, that's too much risk. We're not going to let this happen because of all the advancements and in speed of development and the how quickly the businesses need to move. Today we reached a point where we were also always chasing after that elusive remediation of risk versus going back to fundamentals and saying, where can I accept risk, where can I defer risk once things are already made? You know, to your point, you were coming with ideas, but they were already vetted. And in some cases I'm not saying that was your case, but often times not. It's already a build product that is just about to be launched. And as to check the box, somebody comes to security and says, oh look, this is going to do this much good to the business. We're ready to launch in a week. We just need you to, you know, double check that everything's okay. And securities, because we're the, the gatekeepers of risk, gets back on its, you know, pushes, feels like it's a little bit back to the wall and goes, hey, no, this is actually too risky. No go until we do a full review. We as an industry been trying to change that mindset for a very long time. I see more and more conversations with CISOs and heads of product security where they're saying I want to be the champion of advancement and the champion of business enablement in my organization. Because security should not be seen as exactly how you saw it, how you experienced it, of that, nope, you can't do this because it's too risky. But rather how can we drive that innovation? And I think the solution is if on one hand the developers, the product managers, feel that they can contact security and get a response and meet them where they at in their processes, in their environment. And security doesn't feel like they're being pushed to the wall and they don't have a choice and time to dig in and really weed out the risk because eventually what we want to get to is not, no, this is risky. No, Go is yes, but. And that's the mentality shift that you can do if you introduce security to the earliest stages. And security has the tool to understand or the tools to understand the context in which the business operates and where the business wants to go and why it needs to go there, and then introduce a much more robust risk approach that says, yes, but. And then under that umbrella, we can have a more robust conversation. But a couple things need to exist for that. One, the willingness to incorporate security. And I think the baseline for each organization is that everyone wants to do the right thing. I don't believe that there are bad people within organizations that just want to do risky things because that's what they're meant to do. No, everybody really believes in security. Have not yet met an organization where the development team's like, ah, no, we want to ruin security. That doesn't exist. Of course, I'm not talking about insider threats and all that. That's a real thing for sure. Right. But I also fully understand development says, look, I got my own Sprint, I got my own things, I got to run forward. I need security to meet me where I'm at, and it needs to make sense. And if they can do this before I start developing, that's amazing, because now I understand what I need to incorporate into my work and everyone's happy. That has been very elusive, I believe, until recently. But I'm biased because that's what we're building.

[C]

Yeah, of course. No, it's. As you were talking through this, I saw this meme not too long ago. It was a. It was a mom who was trying to explain to her two kids that the jar of chopped garlic was not candy. And she kept saying no and no and no and no. And then finally was like, okay, if you want a spoonful of chopped raw garlic, you can try it, but you're going to hate it. Right. And so, in a way, there was a moment where the mom told them the risk. No. Told them the risk. This is not what you think it is. You shouldn't do this. And eventually the kid's face, once he had a spoonful of raw garlic, it told you everything you needed to know about the lesson learned. And I feel like there are going to be moments where a business may go, no, but I want to have that risk. I want to take it, and they may regret it later. And then it becomes a. I need to listen more often when security says no, or maybe the kid's a freak and he loves raw garlic. And he just cleans mom out. I don't know. Didn't see that video, but maybe the risk is okay. You just never know. But it wasn't an absolute no. And I feel like it was a. At least with this mom and her little kid, a good lesson for the kid, right? Like, mom. Mom's not just keeping jars of candy for me, but. But, you know, you got a chase, a chance to learn, and it was. It was as safe of an environment to learn that as possible. Right? It was. It wasn't, you know, one of those areas where there was a huge downside to it. I mean, obviously your mouth tastes like garlic for, I don't know, days, and your mouth burns, but you're gonna. You're gonna live. So I don't know why that came in as you were talking about it, but I can just see, you know, a product leader and a design team going, but, but, but, but we want our garlic. And you're going, no, you really don't.

[A]

You should stop. Hold up. So. But the thing is, I actually really. That's. That is a great meme.

[C]

And.

[A]

And I'll. I'll take a little spin on it. Which is actually the case in. In, I would say I can easily say 90% of organizations I tried to, you know, I'll give 10% to. Maybe I'm, you know, the things that I don't know, not maybe for sure, things that I don't know. And I'm not aware. However, the 90%, it's not even. The issue is not about having that conversation. So much of the kid saying, but it's candy. And mom saying, nope, it's not. It's the fact that that conversation doesn't happen because there's too many kids, too many jars, and usually one mom. So if you think about, you know, that really weird analogy that we went to from a security standpoint, it's, oh, but I already had it. And I'm telling you after the fact, whether if I'm telling you that or some finding, whether if it's a good bug bounty finding or a very bad finding of breach or an incident, it's, oh, wait, I didn't even see you going for that jar. So I wasn't aware to tell you that that's a no. I didn't know that that jar even existed in that place because I didn't even know you put it there. It has garlic in it.

[C]

It's almost like the neighbor came over and said, hey, your kid's breath smells like garlic, and they're crying. Maybe you want to go look into it. Exactly, yeah. If we turned it into the security analogy. But no, it strikes me of sometimes you got to let the business take the risk and understand that they're taking an opportunity on the business side, but increasing the cyber risk. And if they're okay with that risk appetite calculation. Oh, okay, You've let them know and. Or you explain like, hey, did you know? And they're going, I had no idea. But to your point, you got to start with, did you have the conversation? And what you're talking about is moving left into that design and development phase. Actually, you know, one of the things I'm curious about, you've seen this over and over. What's one of the most common things that keeps arising in the development phase? You know, even with this growing awareness around cybersecurity risks that exist in application development?

[A]

Honestly, and I might say something controversial here, and I might get a lot of hate for it, but I'll try and go for it anyway. I will preface and say, like I said, I'm a true believer that everyone in development and product management and design really want to do the right thing when it comes to security, full stop. They have their day jobs, and what I see is often more than that is that there's this expectation that they'll take care of their day jobs and they'll take care of security, and then they'll take care of a bunch of other things that. And it's all somehow in their bucket. But they have deadlines and they have expectations from said business that put those deadlines for them and that unrealistic expectation that we're going to take care of everything and everything is going to be priority number one. Meeting the deadline for that feature that we're working on, incorporating security, thinking about security, understanding what I need to do, like all of that becomes priority number one. And honestly, it's just impossible and really just unfair. So what happens? They prioritize. And when you prioritize, then if things slip, and guess what? More than once, security slips, it doesn't come from a bad place. It comes From I got 10,000 things that I need to take care of as part of my day job. And yes, I know that I need to incorporate other things, but I'm on the deadline and I think that makes sense. It's kind of like this, really, between a rock and a hard place, because I really want to do the right thing. I'm not here to do bad code and vulnerable code and mess with the security logic. But it's also not my specialty. And that's what we're talking about. Like the design stage is not about whether if we introduced a vulnerable library or not. The design stage is understanding from a security architecture standpoint. Have we introduced security design flaws in our logic, in what we're doing? That's the real issue here. Because my code could be fantastic, but at the end of the day, I caused a security incident. Whether if it's related to regulation, privacy or flat out, there's. There's an issue with the logic and that is, that's why we're doing security design reviews. It's just that manually, as I mentioned, it's impossible to scale. And so what I've seen over and over is that lack of alignment between expectations and reality because things get more complicated and at the same time things, you know, the speed is insane with all the co pilots, the cursors of the world that are now helping write code even faster. So. But that makes security even more complicated. So that's a whole different conversation that we can get to if we have time.

[C]

Demetri, how do you strike the right balance between security and user experience without compromising either?

[A]

Wow, that's. You really went with like a big and heavy one, huh?

[C]

We're mid interview.

[A]

It's a very real challenge and it's gonna sound like probably a hundred other answers which are similar. And I do believe in that because my background is also in product management. It's compromise. It really is compromise. It's understanding. It's going back to that yes, but, or no but depending on what the risk is. But it requires both ends of the table, A, to be at the same table, but B, also to acknowledge that no one is more important than the other, meaning you will have to compromise on certain things unless you're willing to accept a higher dose of risk. That's the thing. Those are the weights, right? The weights are always how can we serve our customers? Best way possible, best experience, fastest, smoothest, the whole shebang. At the same time, how do we not introduce so much risk that we can just be put out a business and then it doesn't matter if we created this amazing experience, we don't have a business or, or the hit to our reputation is so massive that again, it doesn't matter. The business might have survived, but the customers moved on to our competitors. Because security is now becoming, which I think is also a very interesting pivot, is now becoming a, an important aspect of what the customers are looking for because the education is working and that security promise. So I have a lot of friends who are CISOs who are now attending a lot of, of customer meetings and sales kickoffs to talk about what security is doing and how they're doing and how they're protecting the business and the products. So there is that tightening of a relationship. It still boils down to can we compromise in certain things in order to reduce risk. And yes, we acknowledge it might not be exactly how we planned it, but we are, we are meeting security where it needs to be. And sometimes it's meeting them at the 30% mark and sometimes it could be at the 50. And sometimes security might just come out and say, listen, this whole approach is wrong. And here's 1, 2, 3. And it's on us on the security side to provide that detailed 1, 2, 3. Because we also have this issue of assuming everybody understands risk management when it comes to security and all the consequences, and it's not true. We really need to explain the why behind, hey, this is risky. And we need to keep on explaining it until people oh, okay, I get it. And because again, we cannot expect that everyone can do their job and then security, because it's just not fair.

[C]

So as you were talking through this, I think about the life cycle of product design and a lot of times the focus is on the core function and then the initial onboarding experience and then maybe some V2 where you're improving and looking at data to show where do you invest or not. But I think that maybe a missing layer in there is what is the reason for somebody to attrit to leave your product. And sometimes you outgrow it or you no longer can afford it. Those sorts of business functions change. But what you're talking about is that the risk, the risk to my data, the risk to my experience is so high that if I do experience some sort of breach, some sort of impact to availability, I no longer trust you as a customer. And I think that that's an interesting thing that we have to look at from the design standpoint and having that education, having that ability to bring somebody in and, and work with us, you know, that's, that's paramount to success.

[A]

120% in agreement with you. I think the, the benefits of integrating security and shifting from a very much reactive where we've been since security started, because that's where we kind of historically originated and that's post already existence of the product already exists. It runs and we need to monitor and secure it, but keep on shifting to its origin and being able to finally get to a place where we incorporate security into the designing building stages. Because if you think about even the code scanners, there's already code. You scan it, you produce the results, you provide those results back to development and you say, hey, you're going to go and fix this. It's absolutely crucial in the steps of designing a product. That being said, and we do need to scan for vulnerable libraries for issues in our code, for sure. That being said, if we could also conduct a more thorough analysis of the design as a whole and talk about the concerns from a much more holistic, broader perspective before we're shifting to code, then that alignment between, hey, here are the issues that we found in your code, but also your whole logic is much more solid. We're improving with very little rework downstream. I think one of the analogies that we've been testing and what's recommitted to us, which I think is a brilliant one of those conversations when somebody gives you a tip and you go, wow, that is so profound. I haven't thought about it, but it's all obvious. And the analogy is think about how many cars were recalled in past year in usml, right? We're talking about millions. Then we recall because there was a design flaw that was identified post production and now you're saying we got a rework, so let's pull all those back. Correct. You know, fix them and send them out again. Well that's the same thing we do with products in code. We've identified something whether if we identify it or there was an incident or there was a reporting and now we have to go back and fix it. That we work is extremely expensive because we're losing business, we're losing development time, we're not developing the next things. What if you could understand that during that design stage and reduce all of that friction, wouldn't that be that much better in terms of just even pure time to market and cost reduction? I think the answer is quite obvious.

[C]

You know, when we've talked Dmitri about this, this idea of the fourth leg of the stool you've got, you know, engineering, design and business maybe is the three that I've always thought of. But, but security has to be the, the fourth leg. What role does security need to play in that decision making progress process to ensure that smooth development workflow? And so that we're not getting into a recall situation like you were just explaining with autos.

[A]

I think the difference is we have to be in all of them. So is it a fourth leg of the stool? Maybe I will go with this analogy. I think the difference is or the change is that we have to be involved in engineering, in design, in the business because the decisions that security takes on guidance when it comes to risk, that is that can be as good as we are informed. And because we can't be in every single room, we need to establish those relationships and we need to make sure that we are proactively being updated and pulled into conversations so that we can help make the right decisions by bringing that lens of security, whether if it's through the existing controls or what we don't and how we need to avoid that. What comes from a design perspective where hey, I know you want to try this brand new thing, but actually here is a ton of reports about vulnerabilities that exist in that brand new thing you're trying to use and incorporate in our new design framework from an engineering perspective. So there's much fewer resources. So I think it's a very slim leg if you think about it with it comes to like the other, the other ones. But the change is we don't have a choice but to be informed and involved in everything. Otherwise we can't be successful at doing our job because we're just missing things. And it's very obvious because when I was just a small example before Prime Security, I was at PayPal and I had eight extremely talented architects, insanely talented architects, security architects, but it's PayPal and eight security architects. So just to give that perspective, I mean the security team was fairly sized, I would say, but eight security architects, you can't really miss that on tens of thousands of employees. And so that just gives a perspective where if the security architects don't have the right tools to know what's going on proactively or and substitute security architects with project engineers with whatever other function, the AppSec engineers, it's not a fair balance between those other three, I guess legs.

[C]

So looking ahead, what evolution of the relationship between security and design team you see evolving and or would you hope for.

[A]

I would just hope that there's a much smoother integration between the two with the caveat that no process is disturbed. I think the biggest challenge that we have is how do we develop the right tools. And by the way, it all goes through automation. There's no way that it's not done in a manual way. Moving forward, that time has gone long past. Anyone who's trying to do that manually either can do it because the ratios are right and it's a much smaller organization or they're going to switch to automation. They're in the process of switching. So it's all and I'm skipping the part of like building relationships and all that good stuff, that's important. But moving forward it's shifting to a preemptive security by integrating through automation and meeting all the other functions, be it design, be it development, be it anything else. Where they at with a forward looking approach to how can I enable you? Oh, and here's everything that I know from context perspective and here are the areas where I can accept risk, here's where we're going to defer it, but I'll need you to come up with a solution and here's how I'm going to help you resolve it. And here's the why once that happens, then we become this symbiotic organization, right? And we're actually reaching what we've been preaching for and security for the longest time ever, where we're there to guide and help but we're not there to block. And we're essentially transitioning into that enabling function.

[C]

Beautiful Dmitry, awesome to have you on Threat Vector today. I really enjoyed this conversation about preemptive security and the evolving relationship between security teams and design teams.

[A]

Thank you very much for having me, David. Real pleasure.

[C]

That's it for today. If you like what you've heard, please subscribe wherever you listen and leave us a review on Apple Podcast or Spotify. Those reviews and your feedback really do help us understand what you want to hear about. And if you want to reach out to me directly about the show, email me at Threat Vector Palo Alto networks.com I want to thank our executive producer, Michael Heller, our content and production teams, which include Kenny Miller, Joe Court and Virginia Tran. La Peltzman edits the show and mixes the audio. We'll be back next week. Until then, stay secure, stay vigilant. Goodbye for.