There are many good reasons healthcare organizations turn to open-source software: it provides much-needed customization, system interoperability, and fewer concerns around vendor lock-in than commercial, off-the-shelf software. Open-source software also possesses many potential security-related benefits, such as regular bug fixes from the vast open-source developer community. However, it's not all upside with the use of open source within healthcare delivery organizations, especially with regard to software security.
For starters, with open-source software, there's a lack of centralized quality control and the accountability of a commercial software vendor. There's also the challenge associated with identifying open-source software in use throughout an organization, such as within libraries and components used within commercial applications and medical devices, as well as within software developed internally.
"Just like every other industry, open source has proliferated and found its way into healthcare, whether that's within medical devices or general software within the healthcare industry," says Nick Mistry, SVP and CISO at software supply chain security company Lineaje.
Fortunately, there are steps organizations can take to secure their open-source software better, and there are also measures federal regulators have recently taken that show promise to improve open-source security more broadly.
The first is ensuring that healthcare organizations have visibility into their open-source software. This includes establishing governance oversight policies, implementing automated open-source dependency tracking, and integrating open-source management into their software development lifecycles. Healthcare organizations must maintain an accurate inventory of components and prioritize swift software updates.
"You want to know how well you are managing the security of your open-source software," says Mistry. "And you need to understand the open source software you're bringing into the organization based on policies that reflect your organization's risk thresholds critical," he adds.
For healthcare organizations that are contributing to open-source projects with their developers or using open-source components in the development of their custom software, they must ensure that they're testing software early in the development process and that they're using open-source components that they can trust and that are up to date.
You need to understand the open source software you're bringing into the organization based on policies that reflect your organization's risk thresholds critical.
—Nick Mistry
"However, development teams are overwhelmed and under water with the sheer volume of vulnerabilities they must manage. They need to find ways to address the most pertinent risks in the software they're using," says Mistry. Mistry advises organizations to use software security tools that will help them to identify the most critical vulnerabilities and work more smartly, not necessarily work harder at trying to mitigate everything.
Finally, Mistry points to several regulatory compliance efforts from the U.S. Food and Drug Administration (FDA). Most recently, the FDA has mandated that medical device makers, with the Consolidated Appropriations Act of 2023, which amended the Federal Food, Drug, and Cosmetic Act, maintain a software bill of materials, or SBOM, for their devices as well as submit a plan to monitor, identify, and address postmarket cybersecurity vulnerabilities, ensure their devices and related systems are secure, and when needed make postmarket security patches available.
In a presentation below, Jenn Gile, director of product marketing at Endor Labs, spoke about how the FDA's SBOM and secure development mandate will significantly impact open-source security in connected medical devices.
According to Gile, the FDA's SBOM mandate "changes the game for OSS security" and could significantly impact open-source security more than any previous government regulation.
Gile says the SBOM requirement will help healthcare organizations identify potential vulnerabilities faster. That improved visibility will enable better risk management of open-source components, such as providing developers with a comprehensive list of open-source components and their versions, thereby streamlining dependency management and better ensuring the use of the most secure versions.
Further, Gile says the FDA mandate shifts secure development and effective open-source management from a best practice to a requirement. In Gile's view, the FDA's mandate for code developed more securely and for SBOMs will help improve open-source software security over time.
"We're going to see a natural selection of open-source projects to have more reliable dependencies," Gile says. "Developers are going to become more selective about the projects and the libraries they choose, forcing open-source developers to make those projects more reliable and transparent," she says.
While experts see significant steps forward for open-source security in the years ahead, especially with medical devices, it won't happen overnight.
"We will see open-source software projects leveraging secure development practices. And they'll become more transparent and more accountable," says Gile.
But a deep, lasting change in security doesn't come easy, and to fully succeed, it will take effort from not only software and hardware developers but also healthcare companies themselves by putting in the resources they need to keep their environments well-managed and secure.
George V. Hulme is an award-winning journalist and internationally recognized information security and business technology writer. He has covered business, technology, and IT security topics for more than 20 years. His work has appeared in CSOOnline, ComputerWorld, InformationWeek, Security Boulevard, and dozens of other technology publications. He is also a founding editor at DevOps.com.
