Episode 9 · April 15, 2025 · 28m listen · 5,606 words · ~28 min read

Collaboration is Key: Bridging the Gap Between Developers and Cybersecurity Experts | Ep. 16 - Full Transcript | The Med Device Cyber Podcast

Read the complete, searchable transcript of Episode 9 of The Med Device Cyber Podcast - expert conversations on medical device cybersecurity, FDA premarket and postmarket guidance, SBOM management, threat modeling, and penetration testing.

Prefer the listening experience? Open the episode page for the synopsis, key takeaways, topics, and Apple / YouTube listen links.

Episode summary

In this episode of The Med Device Cyber Podcast, hosts Trevor Slattery and Christian Espinosa from Blue Goat Cyber delve into the often-contentious relationship between software developers and cybersecurity professionals. They frame the discussion around the fundamental problem of bridging the communication and priority gap that exists between these two critical teams, a challenge that Christian Espinosa addresses in his book, "The Smartest Person in the Room." He argues that the high-IQ and ego-driven nature of both fields can lead to friction, as each group's identity is tied to being the expert in either building or breaking a system. This dynamic frequently results in poor collaboration and communication, hindering the ultimate goal of creating a secure product. The hosts explore a common and problematic scenario where medical device manufacturers delay cybersecurity testing until just weeks before their FDA submission deadline. When penetration testers inevitably discover a multitude of vulnerabilities, the development team's reaction is often defensive. Developers, proud of the product they've built, may deny the feasibility of the exploits or feel personally attacked by the long list of identified flaws. The hosts acknowledge the validity of this emotional response but stress that it creates a significant obstacle. They argue that the primary responsibility of a cybersecurity professional extends beyond simply finding vulnerabilities; it includes delivering a clear, actionable report that helps developers understand the risks and empowers them to fix the issues. If the report is confusing or overly technical without providing context, the pen tester has failed in their core duty. Throughout the conversation, Slattery and Espinosa discuss the systemic reasons why security is often an afterthought. Business pressures, such as unrealistic timelines and budget constraints, frequently lead management to rush products to market, making cybersecurity a "necessary evil" that is the first to be cut. This is compounded by an educational gap, where secure coding practices are not a foundational part of software development training, leading developers to unknowingly introduce vulnerabilities, sometimes by copying insecure code directly from online sources like Stack Overflow. The hosts conclude that while it's unrealistic for every developer to be a cybersecurity expert, fostering a basic understanding of core security principles—such as input validation and proper credential management—is essential. By integrating a security-first mindset and automated tools early into the software development life cycle (DevSecOps), organizations can prevent the vast majority of common vulnerabilities, making the process more efficient, collaborative, and ultimately safer for the end-user.

Key takeaways from this episode

A significant and often adversarial gap exists between software developers and cybersecurity professionals, frequently stemming from differing priorities, communication styles, and professional egos.
Developers can become defensive when presented with a long list of vulnerabilities, as they may perceive it as a personal critique of their work rather than a collaborative effort to improve product security.
The core responsibility of a penetration tester is not just to find vulnerabilities, but to deliver a clear and actionable report that helps developers understand the risks and how to remediate them.
Business pressures, including tight deadlines and budget constraints, often lead to cybersecurity being treated as a low-priority "necessary evil" that gets cut or rushed.
Integrating cybersecurity early and throughout the software development lifecycle (a 'DevSecOps' approach) is far more effective and less costly than performing last-minute testing.
A major source of vulnerabilities is a lack of secure coding education, leading developers to unknowingly introduce flaws, sometimes by copying insecure code from public forums.
While developers don't need to be cybersecurity experts, understanding fundamental security concepts can prevent the vast majority of common, low-hanging-fruit vulnerabilities.

Full episode transcript

Trevor: Welcome back to the Med Device Cyber podcast. I'm Trevor Slattery here with the co-host Christian Espinosa. And today we're talking about a little bit of a controversial topic, bridging the gap between developers and cyber security. How are you doing today, Christian? Christian: I'm not doing that great. I have a cold and it's been... It's like one hour I'll feel really good, next hour I'm like coughing and my nose is running, so... you know, it depends. But I'm glad to be here today talking about this controversial topic. I think it's a fundamental problem that we are not making much progress on. Trevor: Yeah, you know, someone should write a book on that. Seems like a good topic to cover. Christian: Yeah, I did write a book on that. Are you talking about my book? Trevor: I am. The Smartest Person in the Room. Christian: Yeah, I have a little plug into it. Yeah, it's about the egos with high IQ individuals and they want to protect their identity at all costs, so they want to be smarter than everybody because that's their identity, which doesn't make for good collaboration or communication typically. Trevor: No, and that can be a problem with developers and cybersecurity experts. If someone's really good at making something or really good at breaking something, they're going to be pretty proud of that fact and can lead to clashes here and there. Christian: Yeah, and since we're talking about developers, I think it's interesting, because we've had this scenario come up quite a bit, where the... a manufacturer waits to... a medical device manufacturer waits to like 60 days before their FDA submission, as an example, and they... we, they come to us and we test everything, we find like a thousand vulnerabilities. And then we tell them the vulnerabilities, and their software developers are like, "There's no way you could do this," right? They they like get defensive and argue that there's no way we could have done what we've done. Uh and how, you know, we have to have some emotional intelligence, which my book is about, to navigate that scenario. But do you think that's more the norm, or just kind of a rare scenario where the developers get defensive and like, "There's no way you could do this." What do you think based on our interactions? Trevor: It's pretty much a coin flip every time you do this interaction, whether or not it's gonna... they're gonna go, "Oh, yeah, that's really good to know. Cool, let's fix it." Or if they'll be a little bit defensive. And it makes sense. That's their product, they built it, they're proud of it. And you're saying, "Here are a thousand things you did wrong." And that can be a little bit upsetting for some people. Christian: I guess that's true. I mean, I was talking to Melissa the other day and and I I'd pointed out a couple things that she needed to improve on and she's like, "All you're doing is complaining about all this stuff I did wrong, not the stuff I did right." And I I imagine a developer feels the same way. Trevor: Well, that was your first mistake, ever pointing out anything wrong. Christian: Yeah, I uh... I'm I'm I'm constantly trying to make improvements. Sometimes I don't learn from my mistakes until like the hammer hits me over the head. Unfortunately, you know, it's like, I got to make the same mistake a few times. I try not to, but I'm not as smart as I think I am sometimes. Trevor: Yeah, and I think that with like developers making a product, those two different responses do require navigating the situation a little bit differently. Um, and this isn't to say that every time we talk to developers, they immediately like come to attack us because they think we're attacking them, which we aren't. We're just trying to make them, you know, help them build a secure product. We're trying to secure their devices and we're there to help. Uh, a lot of the times, people recognize that from the get-go. We're there to help, we're not trying to cause problems, we're not trying to, you know, make them feel bad or attack them. We're just saying, "Hey, this is what you can work on to design a safer product." And they're excited, they're enthusiastic. They like to see this come out and they can't wait to get the fixes done. That's the interaction that we always love to see. And I think that those are obviously really easy interactions, but even when someone, you know, saying, "Well, how are you finding all these problems? I don't think this is, you know, fair. Like, I can't believe you find all this." There there's a right way to navigate it and we can point out, "Hey, this isn't us trying to poke apart your product. This is the standard that we have to follow. This is what you guys have to follow. We're just helping you follow that. That's all we're doing here."

1 / 7