The Future of Product Security: AI, Leadership, and Secure-by-Design with Oleg Yusim

David Leichner: Welcome to the latest episode of Hot in Tech. And today we have an incredible guest. His name is Oleg Yusin and he is vice president and chief product security officer at Illumina where he leads product security strategy for one of the world's most advanced genomics and healthcare technology platforms. His work focuses on embedding security deeply into product architecture development and life cycle processes, ensuring that security becomes an engineering discipline rather than an afterthought. Prior to Illumina, Oleg led product security at Edward Life Sciences. And I'll take a little break here and say that my son, my oldest son is a biomedical engineer at Edward Life Sciences. And I'm very proud of the work he's doing there. So actually there was a small connection from the previous life. And at Edwards, he built and scaled product cybersecurity governance, risk and vendor risk management initiatives across regulated medical technologies. Earlier in his career, he served as a cybersecurity architect at Baxter International, VMware and Motorola Solutions, helping pioneer secure architecture frameworks for connected medical devices. and large-scale critical infrastructure systems, often working in environments where no established security playbooks yet existed. Oleg holds a Master of Science in Engineering Management and a bachelor's degree in computer science, and he's a really smart guy. He graduated Magna Cum Laude, and he has built his career at the intersection of deep technical engineering, regulatory environments, and modern product security leadership. Oleg, welcome to the show.

Oleg Yusim: Thank you, thank you very much for inviting me David, great to be here.

David Leichner: It's a real pleasure. It's a real pleasure. So let's just jump right in. You your career started deeply hands-on designing secure architectures and even helping to find frameworks where no templates existed, particularly in medical devices. So how did those early engineering experiences shape the way you now lead product security at the executive level?

Oleg Yusim: Well, I would say very much so. ⁓ By background... I am software engineer, so before getting into medical devices or even before getting into security architecture, ⁓ I used to build the software myself. I used to be in R &D and I worked somehow the career shape itself this way that I was being around ⁓ making something which directly impacts human lives. So it was Airpoints first and then communication systems for Army second and then finally medical devices. So for me being kind of coming from that environment and knowing how things are working behind the scene, knowing very well what it takes to build a product and roll out the product and support the product, which has critical concerns on integrity and availability, product, people, lives would depend on. It's easy for me to align now with my development teams. I'm working with and kind of understand what they going through, get technical on the problems we're trying to solve. It generally helps a lot to be kind of. from the same city, if you will, ⁓ in that regard and understand the background deeply.

David Leichner: So I imagine that they have respect for you because they know you came from that background. And it's very different than someone who just comes, let's say, graduates from one of the universities with a cybersecurity degree, has never done development work, and comes into the development team and says, hey, you need to be doing this and this and this and this. And they say, wait a minute, it's going to delay our products. I'm sure that that's really helped you in order to. gain the trust and be able to work with them better.

Oleg Yusim: Definitely, definitely helped to gain the trust and optimize the work processes. I mean, in general, and it's no secret, in R &D, people seen as those who helped to roll the product out, Quicker, better, and everybody else. And so in general, and this has always been my guidance to my team, and this is how I was trying to position myself too, with technical expertise, with... ability to marry it with regulatory requirements, customer requirements, ⁓ knowledge of the security. I was trying to become one of the people who helped to roll product out, rather than the one who ⁓ delays that roll out and makes it difficult.

David Leichner: Excellent.

Oleg Yusim: And that is an interesting topic which we can discuss in length if you want.

David Leichner: So what brought you into cybersecurity from being on the R &D side? What was that moment when either you decided, hey, I want to be in cybersecurity, or it just happened in a way that you didn't expect?

Oleg Yusim: ⁓ Second, it just happened. And I think to the great extent that that's the story of almost everyone who ended up in product security coming from R &D background. It just happened at some point. For me, it happened in Motorola Solution. When I started to work for Motorola Solution, I was hired as a basically lead engineer slash architect. ⁓ but then all my projects were security project. The first project I had to build PKI for ⁓ Matorova over encompassing communication system. Remember I said that communication systems for army, navy, marines, those systems are really over encompassing. They have even their own set of towers, ⁓ their own cloud, everything. So naturally they had to have their own PKI, which is what our task was to build. And once we succeeded, there, ⁓ companies said, okay, well, since you guys know security a little better than everybody else, now how about you go and build a mobile VPN project? And so... Here we go. We went ahead and build mobile VPN for that system. And then once that was done ⁓ Everybody was like well, I think you kind of know security now. So how about you also look into ⁓ you know federal compliance things so Couple of years later, the position on actual security team opened and I applied and that's how my career started.

David Leichner: Very interesting. And I wonder what it's going to be like or what it is like for the people who come in without that background in R &D. It's probably different. And looking at your recent article that you wrote on the evolution of product security, you argue that security can no longer live outside the product lifecycle. It has to be part and inherent in the product lifecycle. So. What's changed over the years and why is deep integration now a business requirement and not just a security ideal? It's something that is inherent in the business and it's something that must be, it must happen in order for the company to succeed in bringing products to market on time.

Oleg Yusim: Well, this is, this is a very interesting topic, David. And, and before I will start speaking about that, I tell you quite honestly, uh, there are probably as many opinions on that topic as there are cybersecurity leaders in product security space. Um, so there's no one right opinion there. Um, so I personally believe that deep technical expertise and integration into SDLC is necessary components for product security team to be considered useful and actually add value in terms of bringing out secure product. quicker and with better quality. Now that's... By far not the only way to approach it. There are ways to do that through just governance where security team sits somewhere and issues, policies and procedures. There's a way in between where security team still sits somewhere, ⁓ not where R &D sits and issues, policies, procedures, but also high level controls and administers. say, tests and vulnerability scans. There are different ways, but the argument I'm making is, aside from me just being... a huge believer into that R &D integration board. For those reasons I already just mentioned, but ⁓ also that whole AI tool set rollout right now, it's a huge game changer, huge game changer. And honestly, I believe we didn't yet fully realized ⁓ even as an industry ⁓ how huge of a game changer it's gonna be. So we already... Today we're working with my team to automate security documentation generation. We're building skills for those of you guys who have been listening to the... AI podcasts and maybe getting your hands dirty a little bit to generate threat model or ⁓ risk assessment. ⁓ There are tools which built by another sub team within my team which can accomplish the same goal. And all that just within couple of months since ⁓ we rolled out Courser internally and made it available for teams to start playing with it. So it's really a huge game changer in many regards and looking just a little bit in the future, not many years, but just a little bit, you can clearly see the point where generating documentation for submission becomes a trivial, very trivial exercise, which does not require, you know. ton of product security engineers. ⁓ And you can also see a point where you can just tell AI in compliance with what standards you want to be, and it will generate you a set of general controls you have to follow. So the question... ⁓ comes in where the added value is. And so looking in the future, I truly believe that the value is in the deep integration, the value is in the hands-on. ⁓

David Leichner: So the integration between security in the product lifecycle with AI is a strong piece of, let's say, the overall, I don't even know how we put it these days, overall product lifecycle, I guess.

Oleg Yusim: Adieu. Well, yes, AI would be definitely a component to both product security and development teams. ⁓ I mean, in fact, it is already. ⁓ So, but ⁓ I'm talking more about integration between security engineers and development engineers, ⁓ about ability of security engineers to deliver very low level. ⁓ detailed designs which can be just taken and implemented which are built for costs optimized for costs for efficiency for performance which are already adapted to that specific technological stock. And so it's not something like, know, theoretical. It's very, very practical. I'm talking about building proof of concepts, especially for challenging concepts and areas. If it involves hardware, especially that that's often becomes a challenging piece or it might involve cloud. It can range across the entire stack of technologies. necessarily have to be hardware dependent. It might go as far as actual code generation, especially for things which are common across the infrastructure of products, things like voice hardening, the set of... ⁓ platform hardening, ⁓ stuff like that. ⁓ But even into ⁓ code which might become shareable ⁓ and utilized again across products, like something like a robust library for data input validation. shareable ⁓ you know IAM with mechanisms to authenticate ⁓ authorize and log for ⁓ you know IAM ⁓ piece of logging things like that ⁓ you know firewall rules and ways to set up them ⁓ There's so many things you can gradually start going in with once ⁓ documentation generation is problem is solved because let's be honest, documentation is a monster. We are in regulated industry, documentation is an absolute monster and a lot of time getting spent. all the time getting spent by generating and editing those endless spreadsheets and word docs and making them aligned with that exact requirements from the latest template. ⁓ my god, we already have one more template from quality management system and so forth and so forth. Now remove that from equation. And it's a brave new world, right? Where technically everything is possible and security engineers can be used as they always meant to be as people who make products secure.

David Leichner: Interesting. So I have a couple of questions about the AI side. What were your main concerns, if you had any? I expect you had at least one or two when you did the rollout of Curser throughout the organization.

Oleg Yusim: Well, I mean, this is why it took so long, Courser became available about a year ago, a year and a half, something like that. So there aren't was recent, the concerns of course about privacy, about protection. And those concerns are very real. But that have been said, AI companies also understand those concerns and they provide ⁓ corporate level subscriptions, right? ⁓ Which more expensive, sometimes significantly more expensive than the individual ones, but they provide additional assurance that your data will not go anywhere and nobody gonna use it. They provide quite a bit of assurance on individual subscriptions too, by the way, And in many ways they leave it up to you how secure you wanna be. Like for instance, in Courser there is ⁓ a privacy toggle which you can enable or not. And if you enable it, then your personal subscription is actually getting pretty close to your corporate one. ⁓ But there are certain things which corporate has ⁓ and personal doesn't. So it's been analyzed, it's been accounted for and ⁓ degree possible we put very good mitigation controls

David Leichner: So I was walking down the street with a colleague of mine who, he works for one of the big engineering companies. And he said to me, ⁓ have you ever thought about it that in 15, 20 years, we'll probably be flying in cars above the ground that were created, maybe it'll be less, maybe it'll be five, 10 years, but that they were created to a large degree using AI tools.

Oleg Yusim: ⁓ yeah.

David Leichner: And the quality control of them was also using AI tools. And he said to me, how are you going to feel about that? And I was thinking to myself, well, I'm talking to Oleg tomorrow. I'm going to ask him that question about medical devices. If you're in a life and death situation and you have a medical device that's been, let's say, partially or largely created by AI coding, with system engineers doing the design, and then you have product security doing product security on that, using AI tools also. How long do you think it'll take for people to get over the, even I don't know if it's fear or to get them in a comfort zone? And I'll just add one thing to that, which is I was talking to one of the surgical robotic companies. And actually a friend of mine, he's one of the executives there. And he said to me, you know, we could run these today without having a surgeon standing there, you know, or sitting there and helping the robot to do what it does. And we don't do it only because people aren't psychologically there yet.

Oleg Yusim: No, I am busy. I'm busy. So here's one thing which I would encourage everyone to remember in and don't forget. So AI is not a got out of the box. It is not, ⁓ it's not something which will magically think for you. ⁓ do things for you, replace you or whatever it is, whatever other common fears are there. ⁓ It is a tool, a very powerful tool, but just a tool with its own shortcomings and with its own limitations, with its own constraints. And this is not a magic. So if we think about it this way, then yeah, I'm absolutely comfortable with everything what you said. As long as the process within organization, which releases those all, I don't know, mini airplanes, medical devices, whatever it is, created properly. What does it mean, created properly? It means that human is there in the loop to verify. that whatever AI has generated actually fits the bill, actually what we need. And everything was appropriately tested. And again, with a human in the world, because ⁓ if I can use this analogy, let's say tomorrow you've been asked to write a book about something, 600 pages, big book. It's a hard task. It's a voluminous task. It is requiring many months of labor because you have to type the 600 pages. You have to structure them. Yes, you have to know what to type for 600 pages. Yes, but you also need to type.

David Leichner: do the research on what you want to type.

Oleg Yusim: Right, but you also need to type 600 pages of the text in, even if you're going to do it only once, which is unlikely because, you will go through rounds of corrections. Now, let's say... You have a general idea of what this book is going to be about. You were able to create a plan, a table, maybe a table of context, and maybe a little breakdown within each chapter of what it needs to be about. And then AI wrote this book for you. Now you have to go read through that book and correct it. introduce personal touch, maybe correct some of the things which you don't feel right, add some anecdotes, add some correct things. AI is mighty as it is still not 100 % accurate all the time. So, you're gonna spend less time. You're going to spend less time because somebody already typed these 600 pages for you according to the structure you have created. Uh, in this semi accurate, it is maybe 90, 95 % accurate. So, uh, I understand that it may be a poor analogy, but it's, it's a, it's a.

David Leichner: I think it's a great analogy. I think it's a great analogy.

Oleg Yusim: Thank you. But, it's very similar. It's very similar. So the question is, we going to let AI write the book and publish it? That probably going to be a poor idea. That probably would be a bad idea. But on the flip side, are we going to say, no, no, no, no, no, no, this is such a great, this is, this is an item of such a great importance, writing a book. I'm not gonna let AI anywhere in the neighborhood of it. That's probably also not a great idea. Just as long as we remember that this is tool, just a tool, we very well aware of its strong sides, weak sides, limitation, constraints, then we can use it definitely and we should use it. ⁓ But... Just don't overuse it and account for the constraints.

David Leichner: By the way, you know why I said it was a great analogy? Because last night I took a lot of information. I've been doing a genealogy project over the last 15 years, and I've started writing up a book about this journey. And I took everything I had. decided, you know what? I've written so many different pieces of the puzzle, and I've done like four different trips. I was in Eastern Europe three times. I was in archives. really did a lot of work, you know, and I just took everything, including the emails and including, you know, flights and hotel information, everything. And I just threw it in to one of the engines. And what I wanted was the structure. And I wanted also to have everything put in chronological order that made sense for this book. And at the end of about three hours of work last night, because I just kept going back and forth. I now have a manuscript of about 400 pages, which I can now go into and review for accuracy and I can make the changes and I can make the updates. I haven't been able to do this in three years. I've been, every time I sat down for some reason or another, I got pulled away or, and it was taking so long. So this analogy to me in my mind is, is amazingly right. And I think it becomes, you know, a situation where you're going to be doing a lot more of the important design work and the quality work and the compliance work versus having to do, and I won't call it menial work, but the work that takes a lot of time, the more tedious manual work that takes a lot of time. So I think you're 100 % right. I think you're 100 % right.

Oleg Yusim: Exactly. Exactly. cannot agree more. So in fact, my instructions to my engineers on the team where to use AI were exactly around this lines, David. I said, find something tedious, which takes a lot of your time. If it takes a lot of your time. And it's a tedious task. It's not an insightful task. It's a tedious task. This is a primary candidate. That is something where you can and should apply AI.

David Leichner: Interesting. And do you see this, you've been in many different industries, know, public safety, enterprise, software, regulated healthcare platforms. You know, when you look at the lessons that you've learned from highly regulated industries, do you think that, especially regarding software and AI, you know, do you think that the organizations, the companies have absorbed this yet? The engineering teams have absorbed this or they still have a long way to go?

Oleg Yusim: It highly depends on organization. ⁓ In many ways, startups lead the way there because they started to adapt AI first. In fact, they started to do that a couple of years ago when AI was not even that powerful as it is today. ⁓ Maybe they do it, by the way, not in the most careful manner. ⁓ Maybe there are some, you know, leaps and fades there more than that should be. ⁓ But they do it they do in it and the problem and I guess the benefit of it is That the more you practice the more you learn AI is the type of ⁓ Thing which you cannot learn without practicing it so Practice it more you will get better in it you will also understand the safety nets of it that the safety concerns of it that the the boundaries within which you can trust it and you can't. But on the flip side, I know a lot of big companies, especially in medical devices space, who want to play it super safe and who are not allowing their engineers to use any AI. Courser, ⁓ GitHub Copilot, sometimes even Copilot is on the blacklist, ⁓ albeit that one is often allowed. ⁓ I heard situations where even Llama, the ability to run local model ⁓ in restricted environment ⁓ was not allowed by ⁓ organization. for whatever reason. So that all being said and accounted for, I would say there are a fair amount of organizations where general governance still preventing them from even starting to use those tools.

David Leichner: think one of the things we'll find, and I think it's not just in the medical device industry, I think it's also in the defense industry in particular, because the defense manufacturers, the big integrators, also extremely, extremely limiting on what they allow their engineers to use. So I think we're going to find competition coming from the sides. These companies that don't have anything to lose because they're startups, and they're going to be coming full force at these bigger, more established companies, whether it's in the medical device arena or it's in the defense area. ⁓ Let's say more of the industries that are protective, more protective about using AI, and they're going to see themselves faced with incredible competition very quickly.

Oleg Yusim: Agreed, agreed. No, AI is, if you will find one word which to characterize it, it's accelerator. It's a great accelerator of everything people do. So it's everybody's choice to use it or not use it and what kind of controls and guard rails to put around it. But you're quite correct. You cannot simply ignore it. I mean, famous seer story I think is very much very much similar just put internet instead of AI and you have it

David Leichner: Mm-hmm. But yeah, what was the video store, the chain that didn't want to buy Netflix in the early days? I forget the name, now I say I forgot the name and it was the, it's where I used to go and get videos every week. And yeah, I think you're right. think, but I think AI is even like so much. Wow. Yeah. Blockbuster, blockbuster. That was it.

Oleg Yusim: Yeah, yeah, so... You mean blockbuster probably. ⁓

David Leichner: And AI is so exponentially more than what the internet brought. AI is just like, mean, internet's a facilitator and AI is just like taking everything to a completely different level. But on that note, we always ask our guests the same question, which is, from your perspective as Chief Product Security Officer working at the intersection of AI, healthcare, complex systems, systems that help

Oleg Yusim: Yeah, yeah.

David Leichner: save lives, you know, what do you see as truly hot in the tech market for 2026?

Oleg Yusim: Well, I mean, it's really AI. We've just been talking about it for a good 20 minutes, if not more. Yeah, yeah. It's absolutely it. I don't see anything in 2026 in the technical world which comes even close in the magnitude of impact. And even...

David Leichner: I knew you were gonna say that. ⁓

Oleg Yusim: not only magnitude of impact, but also the speed with which that impact is happening, the sheer momentum of that impact.

David Leichner: Right. So our final question of the day, and I think we could go on talking for a couple of hours, ⁓ but in fairness to our listeners who might be in the car or in the gym or wherever they are, ⁓ so product security leaders today must bridge engineering compliance and they have the executive teams and the boards looking at them very closely. So for security professionals hoping to follow a similar path as you have done, what skills or mindset shifts are most critical to moving from technical expertise to being an organizational leader?

Oleg Yusim: Yeah, yeah, it's a fair question. So I would preface it with a statement that it is, again, my opinion, Alex says, not a universal truth. ⁓ My opinion, it is very necessary to start from technical expertise. That is our bread and butter. That is our common language with developers. That is ultimately how we bring the value on the project. So if technical expertise is absent, nothing going to replace it and everything I will say after that is not a substitute for that. So it's a base and it's needed. Now once the technical expertise is obtained and established and matured and engineer or architect or what have you is moving towards ⁓ more of a management, director ⁓ or executive positions. And you need to start talking to executive boards. You need to start talking to maybe president of the company, maybe board of directors, depending on the layout of your company, whoever you will be talking to. then yes, that shift in mindset and in the skillset too is absolutely mandatory. and people skills are becoming super important. The biggest shock personally for me when I first took the... management position, I migrated from being a lead architect back in the time to becoming senior manager, was the fact that in that position, and I started to lead the program, technical accuracy of the solution, technical elegance of the solution, ⁓ even if that solution is most optimal or not, is not important. for the decision to be made to adopt that solution or not. What is important is people skills of the person who is quote unquote selling that solution to the organization. Yeah, and that person either knows how to do that, how to read the room, how to build the delivery towards that specific people in that room.

David Leichner: People buy from people.

Oleg Yusim: speak to organizational objectives to those people, audience objectives or not. And if the person comes in and says, you have to adapt that solution because it is just technically so elegant and efficient, well, chances that that solution would be adapted are not very high.

David Leichner: system

Oleg Yusim: So that was one of the biggest shocks for me during that transition. How? Why? Oh my God, because technical correctness and elegance and efficiency of the solution used to be the thing I'm striving for. I'm proud of and now nobody needs it. Really? It's not even important. ⁓ That was a huge shock. ⁓ I still remember that. But yes, people skills. People skills for a person who presents program and a team in front of leadership. ⁓ Super important. Paramount.

David Leichner: Wow, that's a really wonderful note to end this podcast episode with. Oleg, you seem you've had an incredible journey and I want to thank you very much for sharing that journey with our listeners.

Oleg Yusim: Well, thank you so much, David, for the conversation, for inviting me. It was fun.

David Leichner: Thanks and I wish you much success going forward in your career.

Oleg Yusim: Thank you, thank you, thank you, likewise.