Key Takeaways
- AI-assisted development is accelerating the creation of medical device software while introducing new code security risks.
- Open source and third-party components increase software supply chain complexity and vulnerability exposure.
- Medical device teams need current, actionable SBOMs to support security, compliance, and buyer trust.
- Patching alone cannot address every risk, especially in legacy or regulated medical device environments.
- RunSafe helps reduce exploitability with SBOM generation, vulnerability analysis, binary hardening, runtime protection, and continuous monitoring.
Medical device software security is changing fast. AI-assisted development tools can now help teams generate, replicate, and modify code in minutes. Open source components remain essential to modern software development. Third-party libraries continue to accelerate product timelines. But for medical device manufacturers, every shortcut in development can also introduce new questions about security, compliance, and patient safety.
That is the focus of RunSafe Security’s webinar, “Build, Borrow, or Risk It? AI, Open Source, and Software Security for Medical Devices.” In this discussion with MassDevice, RunSafe Security Founder and CEO Joseph M. Saunders and Brad Tenenholtz, Senior Partner at Splyce.ai and former Product Security Officer at BD, examine how AI-generated code, open source software, and increasingly complex software supply chains are reshaping medical device cybersecurity.
Watch the webinar here: Download the webinar
Medical Device Software Is Facing a New Development Reality
The traditional software development question was often simple: should a team build a capability in-house or import an existing solution?
Today, that decision is more complicated. Developers may use AI-assisted tools to generate code, import open source packages, or rely on commercial libraries. Each option can improve speed, but each also introduces a different kind of risk.
Building in-house no longer guarantees full control if AI is involved. AI-generated code can introduce insecure patterns, subtle logic flaws, or reused functionality that teams may not fully understand. Borrowing from open source or third-party libraries can create exposure to known vulnerabilities, abandoned components, malicious packages, or unclear dependency chains.
For medical device manufacturers, the problem is not whether code works, but whether teams can explain what is in the software, where it came from, how it is maintained, and how risk is being reduced over time.
AI-Generated Code Expands the Attack Surface
AI-assisted development has increased significantly. 80.5% of development teams are already using tools that can generate or modify code quickly, and that pace will only accelerate.
For product security teams, this creates a scale problem. More code can be produced faster than traditional review and remediation processes can handle. If security programs rely only on manual code review, delayed patching, or late-stage vulnerability scans, they may struggle to keep up with the volume of software being created.
This changes the economics of defense. Security teams need approaches that can scale with AI-assisted development without slowing innovation. That means improving visibility, strengthening development guardrails, and using protections that reduce exploitability even when vulnerabilities remain present in deployed software.
Open Source Dependencies Are Powerful, But Often Opaque
Open source software is not new to medical device development. What has changed is the scale and depth of dependency chains. A single application may include hundreds of direct and transitive dependencies, many of which are not obvious to engineering, security, or procurement teams.
This lack of visibility creates risk in several ways. Teams may not know which components are present. Software Bills of Materials (SBOMs) may be incomplete or outdated. Vulnerabilities may exist in deeply nested dependencies. And when a vulnerability appears in a component a manufacturer did not write, ownership and remediation can become unclear.
“Medical device manufacturers cannot manage software risk if they do not have visibility into what is actually in their products,” said Joseph M. Saunders, Founder and CEO of RunSafe Security. “As AI-assisted development and open source use expand, teams need current SBOMs and a clear understanding of their third-party components so they can prioritize risk, communicate with buyers, and demonstrate progress to regulators.”
SBOMs Must Be Living Documents
Software Bills of Materials have become central to medical device cybersecurity conversations, but an SBOM is only useful if it is current, complete, and actionable.
A one-time SBOM created for a compliance checkpoint will not help much when dependencies change, vulnerabilities are disclosed, or software updates are released. Medical device manufacturers need SBOM generation and maintenance built into the development pipeline, not treated as a standalone documentation exercise.
A living SBOM helps teams identify vulnerable components, respond faster to new threats, and provide healthcare buyers with greater transparency. It also supports stronger conversations with regulators by showing that software supply chain risk is being managed continuously.
Patching Alone Is Not Enough for Medical Device Security
Medical device manufacturers often face a difficult reality: they cannot patch their way out of every vulnerability.
Some devices include legacy components that are difficult to update. Some software is tied to certification or validation requirements. Some products are already deployed in clinical environments where patching can be slow, costly, or operationally disruptive.
That does not mean teams should accept the risk. It means they need a more practical strategy.
“Most medical device teams cannot patch their way out of every vulnerability,” Joe said. “Teams need to prioritize based on exploitability, exposure, and patient safety impact, then use compensating controls such as binary hardening, memory protection, and runtime defense when patching is not immediately feasible.”
The goal is to find vulnerabilities, reduce the attack surface, limit exploitability, and demonstrate that risk is being managed systematically.
What Medical Device Manufacturers Should Prioritize Next
Medical device security teams do not need to solve every challenge at once. But they do need a clear plan for reducing risk as AI-assisted development and open source usage continue to expand.
A practical starting point includes:
- Inventory software components continuously: Build and maintain SBOMs as part of the development pipeline.
- Create guardrails for AI-assisted development: Define where AI-generated code is allowed, how it is reviewed, and how it is documented.
- Prioritize vulnerabilities by real-world risk: Consider exploitability, exposure, device function, and patient safety impact.
- Use compensating controls where patching is difficult: Apply protections such as binary hardening and runtime defense to reduce exploitability.
- Connect security with business and regulatory outcomes: Make software security visible to product, engineering, compliance, and executive stakeholders.
As AI-assisted development becomes more common and software supply chains grow more complex, medical device manufacturers need to rethink how they make build, borrow, and import decisions.
To learn more, watch RunSafe Security’s webinar, “Build, Borrow, or Risk It? AI, Open Source, and Software Security for Medical Devices.”
