The FDA’s SBOM Mandate: Revolutionizing OSS Security Practices

The FDA‘s New Rules on Medical Device Software and the Impact on OSS Security

The Growing Concerns in Healthcare Security

The US Food and Drug Administration (FDA) is introducing new rules that could have far-reaching effects on the security of open source software (OSS) used in medical devices. The FDA will require all medical devices running software to create and maintain a software bill of materials (SBOM) starting from October 1, 2023. This policy change addresses the mounting concerns over the inadequate security of critical software-powered components in healthcare devices. Medical institutions have increasingly become targets of ransomware attacks, and in the future, medical devices could fall victim to hackers. Additionally, many medical devices currently operate on outdated or end-of-life operating systems, including Linux and other open source software. Manufacturers often encounter difficulties in updating firmware or the device’s software. Furthermore, medical device companies and professionals who use these devices may not possess sufficient cybersecurity knowledge to incorporate proper security measures.

The Significance of the SBOM Requirement

While SBOMs have been promised for several years, the new FDA rule provides a substantial push towards their implementation. Supply chain attacks, such as the notable SolarWinds hack, prompted a more aggressive US government stance on cybersecurity. An executive order was issued, mandating the inclusion of an SBOM in software used by the government. As a result, numerous startups emerged to facilitate supply chain security and SBOM management. Leading version-control service providers, GitHub and GitLab, now offer automated SBOM generation. Surveys have indicated a rise in the adoption and acceptance of SBOMs, with 78% of organizations planning to produce or consume them by the end of 2022, according to the Linux Foundation.

What sets the FDA‘s rule apart is its enforcement power. Mere production or consumption of SBOMs does not automatically translate into robust security, as it is possible to generate superficial and less useful SBOMs. In contrast, the FDA mandates that medical device manufacturers submit “a plan to monitor, identify, and address, as appropriate, in a reasonable time, postmarket cybersecurity vulnerabilities and exploits.” They are also required to “design, develop, and maintain processes and procedures to provide reasonable assurance that the device and related systems are cybersecure.” Manufacturers must establish a patching schedule, including immediate application of patches for serious vulnerabilities discovered outside of the regular patch cycle. Failure to meet these standards will result in the FDA refusing to accept proposed devices, effectively preventing their market release. The rules for devices already on the market remain uncertain, but manufacturers are actively working to comply with the new SBOM standards.

The Broader Implications for OSS

This FDA rule offers a glimpse into a future where SBOMs become more than just an optional activity in the open source ecosystem. OSS is already widely used in medical devices, with Linux being a popular choice for medical device systems. As OSS gains reputation and acceptance, the pressure will grow for medical device companies and service providers to favor OSS components that demonstrate strong security behaviors. These organizations will need to develop robust and up-to-date SBOMs that can be easily aggregated into compound SBOMs for specific medical devices and their software stacks.

This mandate from the FDA will likely lead to a refining process, with a decrease in the use of OSS subcomponents that do not adhere to the SBOM requirements, especially in enterprise use cases. Trusted package repositories and mandated package provenance will also contribute to this trend. The FDA‘s initiative will be highly beneficial for the open source community, as it sets enforceable SBOM requirements for critical infrastructure and components. It promotes transparency and accountability within applications built on OSS, making them more secure and reliable.

Securing Critical Infrastructure with OSS

The FDA‘s mandate is not the only indicator of a shift towards prioritizing security in critical infrastructure. Other regions, such as the European Union, are also pursuing policies to mandate the hardening of medical devices. While OSS has traditionally been more transparent and accountable than proprietary systems, this evolving landscape necessitates even greater transparency and accountability in OSS. This level of transparency will make OSS more consumable and programmatically secure, enabling it to address the increasingly complex software supply chains and intricate webs of dependencies.

In the end, the FDA‘s new rules may lead to greater security in medical devices, potentially saving lives. For instance, these rules could prevent advanced persistent threats from hacking into insulin pumps and holding patients hostage for ransom. As pressures to prioritize security continue to grow worldwide, the approaches outlined in the FDA‘s mandate will play a crucial role in shaping the future of OSS security practices. With each advancement, the global reliance on open source software will become more secure, ensuring the integrity of critical systems in an increasingly open-source-driven world.