Why the FDA’s SBOM Mandate Changes the Game for OSS Security – Source: www.darkreading.com

The US Food and Drug Administration (FDA) is not exactly top of mind for the average open source software (OSS) project maintainer nor the developers building applications that leverage OSS. But new rules from the FDA could impact OSS security more than any government rule to date. The big change? The FDA is mandating that all medical devices running software must create and maintain a software bill of materials (SBOM) and will start enforcing that rule on Oct. 1, 2023.

The new policy addresses growing concerns that critical software-powered components of healthcare devices are not properly secured. Medical institutions are frequent targets of ransomware attacks and, in the future, medical devices could be in the crosshairs of hackers. In addition, medical devices often run on outdated or end-of-life (EOL) operating systems. A significant percentage of these systems use Linux or other open source software.

Often, manufacturers have no easy way to update firmware or device software. Further, medical device companies — and the medical professionals who install and use the devices — may not be well versed in cybersecurity and might not build in proper mechanisms for ongoing security measures. Of course, we’ve had warnings on this topic for years. What’s different about this new rule? And how will it impact the broader OSS ecosystem? The real difference is in the details of the SBOM requirement.

The Cascading Impact of Mandated SBOMs

To date, SBOMs have been akin to nuclear fusion — promising, but always a few years away from being a meaningful reality. A host of supply chain attacks, such as the SolarWinds hack, kicked off a more aggressive US government policy towards cybersecurity, including an executive order mandating that software used by the US government include an SBOM. Since then, a host of startups have emerged to facilitate supply chain security and SBOM management. The largest version-control service providers, GitHub and GitLab, now offer automated SBOM generation. Adoption and acceptance of SBOMs are on the rise according to multiple surveys. For example, the Linux Foundation found that 78% of organizations planned to produce or consume SBOMs by the end of 2022.

What the FDA brings to the party is real “teeth.” Mere consumption or production of SBOMs doesn’t necessarily result in more robust security; it’s easy to generate a superficial and somewhat useless SBOM. 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” and to “design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure.” This includes patching “on a reasonably justified regular cycle” and as-soon-as-possible patches for serious vulnerabilities found outside of the normal patch cycle.

If a medical device maker fails to hit this mark, then the FDA will refuse to accept (RTA) a proposed device. This designation means a maker cannot put the device on the market. For devices already in the market, the rules are murkier. That said, those device makers are scrambling to meet the new SBOM standards.

One Catalyst for a Broader Shift to Trusted, Transparent OSS

For the broader OSS ecosystem, this new FDA rule offers a glimpse of a future where SBOMs are finally more than a nice-to-have or checkbox activity. OSS is already widely used in medical devices. Linux is one of the more popular choices for medical device systems, growing even more popular as OSS gathers reputation and acceptance. If you are building on Linux, the design likely incorporates other open source components such as middleware, message queues, front-end frameworks for user experience components, and more.

For medical device companies and service providers building software for the industry, the mandate exerts pressure to bias toward OSS components (and supporting projects) that demonstrate strong security behaviors. This includes developing robust SBOMs that are kept up to date and can be programmatically consumed to aggregate into compound SBOMs for a specific medical device and its software stack. By extension, this means we will likely see a winnowing effect as OSS subcomponents that don’t abide by the SBOM mandate subsequently fall out of favor with enterprise use cases. This trend will be reinforced by the emergence of trusted package repositories and mandated package provenance.

For open source, this catalyst from the FDA will prove extremely beneficial. It offers a model of enforceable SBOM requirements for critical infrastructure and components. It provides healthy pressure to make applications built on OSS more transparent and accountable. Most importantly, the FDA mandates could save lives one day. For (one terrifying) example, imagine if an advanced persistent threat were to attempt to hack insulin pumps to extract a ransom. Pressures are also building in other geographies, such as the European Union, which is pursuing policies to mandate medical device hardening.

None of this is to say that OSS has not already been more transparent or accountable than proprietary systems. It has. But even within this context, a higher degree of transparency and accountability — making OSS far more consumable and programmatic — is necessary to secure increasingly convoluted software supply chains and webs of dependencies. The upshot? Your pacemaker or insulin pump will be more secure, and so will everything else in a world increasingly powered by open source.