In this episode of Threat Vector, David Moulton talks with Dimitry Shvartsman, Co-Founder and Chief Product Officer of Prime Security, about transforming security into a proactive business enabler. Drawing on decades of experience, Dimitry explains why integrating security at the design stage—not after deployment—is key to reducing risk and improving outcomes. The conversation highlights the challenges of scaling secure development and the role of automation in modern application security. If you're interested in aligning product, design, and security teams to build more resilient software, this episode delivers clear insight and practical advice.
Protect yourself from the evolving threat landscape – more episodes of Threat Vector are a click away
Transcript
[ Music ]
Dmitri Shvartsman: So, once those what I want to build, what I need to build, hits the dock, confluence, gyro, 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 real work, and the amount of findings is going to reduce dramatically. [ Music ]
Michael Heller: Welcome to "Threat Vector," 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 41. [ Music ] Today, David is joined by Dmitri Shvartsman, the co-founder and Chief Product Officer of Prime Security. Dmitri 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. [ Music ]
David Moulton: Dmitri, 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?
Dmitri Shvartsman: Well you know, that's a 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. You know, use the flag of risk, and just say no. And then explain-and that would be like, oh wait, but what did you really ask me to do? And what are you asking me to improve? 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, you know, set activities and growing in all that great stuff. And it was very difficult, because then the reality hit, which is we're always-as security people-we're always understaffed, we're always, there is 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 are today. We have been doing security design reviews since the beginning of essentially application development. Yes, we've been doing this manually, because we have no other choice. So the understanding of that business context, and how to provide security was always done with let's get in the room, or let's get on the 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 in back when they started, this is not scalable. You can't sustain this. So you're 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 they become that, you know, 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 the realization with the evolvement and the advancement in technology that happened, especially the introductions of [inaudible 00:05:01] and ability to work with large quantities of data that are locked in unstructured sources that kind of gave you 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.
David Moulton: So, as I was preparing for the show and writings from 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 is how we can make this application more delightful, get user engagement up, bring people in, actually hit those business goals that we were, you know, asked to drive as the design team, but we constantly ran into the security team saying no, we can't do that. That's a risk, that's a risk over and over. And it struck me that, you know, security is often seen as this barrier that, you know, barrier to innovation, especially for those design teams, those developers that are out there. You know, and 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?
Dmitri Shvartsman: You are spot on. Reason being is we've had historically to place these check holds, these check points, and again it goes back to my previous point, because we were, 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 check hold points to make sure that we have a way to step in and say no, that's too much risk, we're not going to let this happen. Because of all the advancements and instead of development and how quickly the businesses need to move today, we reached a point where we are also 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 in some cases, I'm not saying that was your case, but often times not. It's already a built product that is just about to be launched and has to check the box. Somebody comes to security and says oh look! This is going to be this much good to the business, we're ready to launch in the week. We just need you to, you know, double-check that everything is okay. And security is-because we're the gatekeepers of risk-gets back on its, you know, which just feels like it's a little bit back to a while ago, saying uh, no, this is actually too risky, no go until we do a full review. And we as an industry have 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 exactly how you saw it. How you experienced it, of that, no, 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 are 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 a yes, but. And that's the mentality shift that you can do if you introduce security through the earliest stages. And security has 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. But under that but umbrella, we can have a more robust conversation. But a couple of things into it-just 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, you know, bad people within organizations that just want to do, you know, risky things because that's what they're meant to do-no. Everybody really believes in security. I've not yet met an organization where the development team is like ah, no, we are-you know, 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.
David Moulton: For sure.
Dmitri Shvartsman: Right. But, I also fully understand development. Because look, I've got my own things, I've 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 is happy. That has been very elusive, I believe until recently, but I'm biased, because that's what we're building.
David Moulton: Yeah, of course. No, it's as you were talking through this, I saw this meme not too long ago, 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.
Dmitri Shvartsman: Right.
David Moulton: 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 then they regret it later, and then it becomes a "Ah! 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 is not just keeping jars of candy from you, but--
Dmitri Shvartsman: Right.
David Moulton: But, you know, you've got a chance to learn. And that was as safe an environment to learn that as possible, right? 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 [laughter] I don't know, days your mouth burns? But you're going to live. So, I don't know why that came in as you were talking about it. But I can just see you know, product leader and a design team going, but-but, but, we want our garlic! And you're going, no, you really don't. You should stop! Hold up. So...
Dmitri Shvartsman: So the thing is, I actually, really, that is a great meme, and I'll take a little spin on it, which is actually the case in I would say, I can easily say 90 percent of organizations. I try to give 10 percent to you know, the things that I don't know, not maybe, for sure. Things that I don't know, and I'm not aware of. However, the 90 percent, 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 no 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 [laughs], so if you think about you know, that really weird analogy that we went to from a security standpoint [laughter], it's oh, but I already had it, and I'm telling you after the fact, whether if I'm telling you that, or you know, some finding where it's a good bug bounty finding, or a very bad finding, of you know, reach, 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. Like, I didn't even know that jar even existed in that place, because I didn't even know you put it there.
David Moulton: Yeah.
Dmitri Shvartsman: You know, and it has garlic in it.
David Moulton: 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?
Dmitri Shvartsman: [Laughs] Exactly right.
David Moulton: Yeah, if we turn it into security analogy, but no, it just strikes me of like, sometimes you've 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, 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've 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 it rising in the development phase is, you know, even with this growing awareness around cybersecurity risks that exist in application development?
Dmitri Shvartsman: Honestly, and I might say something controversial here, and I might get a little hate for it, but I'll try and [laughs] go for it anyway. I will preface it by saying 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 there is this expectation that they will 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 anything is going to be priority number one. Meaning 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 yes, things smut, and guess what, more than once, security slips. It doesn't come from a bad place. It comes from I've got 10,000 things that I have 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 a deadline. And I think-
David Moulton: That makes sense.
Dmitri Shvartsman: And I think it's-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 you know, 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 introduce 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 it's related to regulation privacy or flat out, there's an issue with the logic. And that is, that's why we're doing security design reviews, is 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, all pilots, the cursors of the world, that are now helping write code even faster. So, but that makes securities even more complicated. But that's a whole different conversation that we could get to if we have time. [ Music ]
David Moulton: Dmitri, how do you strike the right balance between security and user experience without compromising either?
Dmitri Shvartsman: Wow, that's a-you really went with like a bit and heavy one, huh?
David Moulton: You know, we're mid-interview [laughing].
Dmitri Shvartsman: It's a very real challenge. And it's going to 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 the best way possible? Best experience, you know, fastest, smoothest, the whole shebang. And at the same time, how do we not introduce so much risk that we can just be put out of business and then it doesn't matter if we created this amazing experience, we don't have a business. 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 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 customer meetings, and sales kickoffs, to talk about what security is doing, how they're doing it, and how they're protecting the business and the product. So there is that tightening of a relationship. It still boils down to can we compromise on certain things in order to reduce risk? And yes, we acknowledge it might not be exactly how we planned it, but we are meeting security where it needs to be. And sometimes it's meeting them at the 38 percent mark, and sometimes it can be at the 50, and sometimes security might just come out and say listen, this whole approach is wrong. And here is 1, 2, 3. And it's no 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 are oh, okay, I get it. And because again, we cannot expect that everybody can do their job, and then security. Because it's just not fair.
David Moulton: 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 like 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 leave your product, and sometimes you outgrow it, or no longer can afford it, those sorts of business functions change. But what you're talking about is the risk. The risk to my data, the risk to my experience is so high that if I do experience some sort of reach, some sort of impact to availability, I no longer trust you as a customer. And I think 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 work with us, you know, that's paramount to success.
Dmitri Shvartsman: One hundred twenty percent in agreement with you. I think the benefits of integrating security and shifting from a very much reactive, where we've been, since security started. Because that's where we sort of historically originated, and that's post-already existence or the product already exists that runs, and we need to monitor and secure it, but keep on shifting to its origin, and be able to finally get to a place where we incorporate security into the designing building stages. Because when you think about even the code scanners. There's already code, you produce the results, you provide those results back to developing, and you say hey, you're going to go ahead and fix this. It's absolutely crucial in the steps of designing a product. That being said, and you know, we do need to scan for vulnerable, you know, 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 realistic, broader perspective, before we're shifting to code, then that alignment between hey, here are the issues 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 was recommitted to us, which I think is brilliant, you know 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 so obvious. And the analogy is, think about how many cars were recalled in the past year, in the U.S. alone. Right? We're talking about millions. They were recalled because there was a design flaw that was identified post-production, and now you're saying we've got to rework. So let's pull all those back, 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 re-identified, or there was an incident, or there was a reporting. And now we have to go back and fix it. That rework is extremely expensive. Because we're losing business, we're losing development time, we are not developing the next things. Well what if you could understand that during the 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.
David Moulton: 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 as the three that I've always thought of, but security has to be the fourth leg. You know, what role does security need to play in that decision making 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?
Dmitri Shvartsman: I think that the difference is we have to be in all of it. So is it a fourth leg of the stool? Maybe.
David Moulton: Okay.
Dmitri Shvartsman: I will go with this analogy. I think that 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 thing, 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, you know, I know you want to try this brand-new thing, but I 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 engineering perspective. So there's much fewer resources. So I think it's a very slim leg if you think about it, when it comes to leg-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, you know, Prime Security, I was in PayPal, and I had 8 extremely talented architects, insanely talented architects, security architects. But it's PayPal.
David Moulton: Mm-hm.
Dmitri Shvartsman: And security architects, so just, to give that perspective, I mean, the security team was fairly sized, I would say. But 8 security architects. They really missed out on tens of thousands of employees. And so that just give a perspective where if the security architects don't have the right tools to know what's going on proactively, or-and you know, substitute security architects with project engineers with, you know, whatever other function, the app engineers-it's not a fair balance between those other three ideas, legs.
David Moulton: So looking ahead, what evolution of the relationship between security and design do you see evolving, and/or would you hope for?
Dmitri Shvartsman: I would just hope that there was 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 is no way that it's not done in a manual way moving forward. That time has gone. Long past. Anyone who is 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 relationship 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 of the other functions, be it design, be it development, be it anything else, where are they at with a forward looking approach to how can I enable you? Oh, and here is everything that I know from a context perspective, and here are the areas where I can accept risk, and here is where we're going to defer it, but I'll need you to come up with a solution, and here is how I'm going to help you resolve it, and here is the what. Once that happens, then we become this symbiotic organization, right? And we are actually reaching what we've been preaching for, in security for the longest time ever. We're there to guide and help, but we're not there to block.
David Moulton: Yeah.
Dmitri Shvartsman: And we're essentially transitioning into that enablement function.
David Moulton: Beautiful. Dmitri, 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.
Dmitri Shvartsman: Thank you very much for having me David. Real pleasure. [ Music ]
David Moulton: That's it for today. If you like what you've heard, please subscribe wherever you listen, and leave us a review on Apple Podcasts 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, at paloaltonetworks.com. I want to thank our Executive Producer, Michael Heller, our Content and Production Teams, which include Kenny Miller, Jovetta Court, and Virginia Tran. Eliot Pelsman edits the show and mixes the audio. We'll be back next week. Until then, stay secure, stay vigilant. Goodbye for now. [ Music Ends ]
