The medical device sector is under pressure to improve software supply chain security, and software bills of materials (SBOMs) are front and center. ReversingLabs talks with Professor Kevin Fu of the Archimedes Center at University of Michigan about what to expect.
Since it was released a year ago, the White House's Executive Order on Improving the Nation’s Cybersecurity (EO 14028) has generated discussion about its impact on software development organizations, federal agencies — and even enterprises, which now must embrace concepts like software bills of materials (SBOMs) if they sell to Uncle Sam.
But in the medical devices industry, discussions of supply chain security aren’t new. And, while other industries are still wrapping their head around concepts like SBOMs, officials at the Food and Drug Administration (FDA) and its peer agencies in other countries are moving quickly to embrace them as they face growing threats and attacks on vulnerable medical devices and clinical environments.
In just the last year, the FDA published draft guidelines for medical device cybersecurity, while the International Medical Device Regulators Forum published a draft of Principles and Practices Guidelines governing SBOMs for medical devices.
Where does that leave medical device manufacturers (MDMs in industry parlance) and healthcare providers? I sat down with Professor Kevin Fu, the Director of the Archimedes Center for Healthcare and Device Security at the University of Michigan and a former Acting Director of Medical Device Cybersecurity at the FDA’s Center for Devices and Radiological Health (CDRH).
In this conversation, Kevin and I talked about the current state of play with regard to medical device cybersecurity and what to expect as medical device SBOMs move from a “good idea” to a “gotta have” for medical device makers — a change that he says is already underway.
[ Get a free SBOM and supply chain risk report ]
Paul Roberts: You’ve been researching and working on medical device cybersecurity for a long time. Are things changing? Are we getting better?
Kevin Fu: So I care a lot about the second derivative - the "change in change," and it seems to be positive for medical device security, but it's lumpy. There are places that I think are doing exceptionally well. There are other places where they could use some serious guidance on the SBOM front.
So the IMDRF (International Medical Device Regulators Forum) that you referred to? I was a participant in that group. I figured, right, that was co-led by FDA and then the Canadian counterpart to FDA here in the United States. Dr. Aftin Ross was the lead representative from FDA. And I want to say there were a dozen or two international FDAs, different countries actively involved in the editing and writing of that document (The Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity), as well as industry representatives from trade groups.
If you don't have an ingredient list of the third party software, how can you even begin to answer the question, what risks are we taking? What's the residual risk? What is our plan when software starts to get out of date?
—Professor Kevin Fu, University of Michigan
Okay, good, because we wanted to make sure we had all perspectives. But it's just so important to have SBOM in medical device design for the whole reason the SBOM exists in the first place. If you don't have an ingredient list of the third party software, how can you even begin to answer the question, what risks are we taking? What's the residual risk? What is our plan when software starts to get out of date?
You can't even begin until you know what you have there. So it's just so important. And the questions right now are more like, “Well, how detailed should the SBOM be?” There's the regulatory lens. There's the industry lens - just 'good manufacturing.' So I'm seeing things just bubbling up from the practice itself.
SBOM is sort of a no-brainer. Like, ‘of course you should do that. Why wouldn't you want to know about your third party software?’ And 'yes,' you can have, ‘I don't know’, in your SBOM. The classic, it's a known unknown, right? So you can say, ‘I don't know what is the provenance of the software.’ And that's okay. If you say that for every piece of software, it gets less okay. But it's important to know your risk so that when a post market issue comes out, you're better able to identify it, contain it, and mitigate it.
Pictured: Professor Kevin Fu.
Paul Roberts: The use case for why you need this in the non-medical device space was something like Log4j, right? It's an incredibly common open source library with a horrible, remotely exploitable vulnerability that, lo and behold, is used pretty much everywhere. Was there a big impact from Log4j in medicine, too? Was that something that popped up in medical devices?
Kevin Fu: Log4j is ubiquitous. It would be easier to write a list of those who didn't use it. So actually, Log4j might be an anomaly. I would say SBOMs are most useful for non-trivial cases. Something being listed in an SBOM is less important if no one is using it or if everybody's using it because then you just check. Log4j is so ubiquitous, I'm not sure if SBOMs would have been a great utility because you should just assume you're using Log4J.
On the other hand, when you have really esoteric software that maybe 20 companies in the world might be using, or maybe they had a former employee download it and install it and then quit, that's where I think SBOM is going to be exceptionally important. Because today you run around like a chicken with its head cut off when you hear about a new vulnerability in a third party piece of software and somebody asks, ‘Hey, do we run that?’ Well, that's what SBOM is here for. And so I would say the classic case where SBOM is going to save your butt is when it's a nontrivial usage case, right?
Paul Roberts: So, you mentioned the situation where some vulnerability comes up in a common, or maybe not even a common component. And there's this kind of conversation: "Are we using this?" Is that happening in medical environments right now? Or is it a head in the sand approach where 'we don't ask questions about what we use and therefore we never need to be worried about new vulnerabilities and exploits'?
Kevin Fu: So it depends how you're asking whether companies do it versus whether the FDA expects it or recommends it.
I no longer speak for the FDA. So this is Kevin Fu's opinion. The FDA has published its draft guidance (PDF). The public comment period has ended. It discusses the role of SBOM. It's pretty clear what FDA has proposed for its thinking.
Moving forward on SBOM, we'll see how it changes as it heads toward finalization. I'm not expecting a huge amount of change to the SBOM portion, but then again, I'm not on the inside, so I can't predict for sure. But we're definitely going to see SBOM. It's just so important to protect medical devices. Now, let's say your company submitting a 510 (K) (pre-market notification) or a PMA (pre-market approval), the two most common pathways to get a device legally cleared or approved. At the moment, FDA does not technically recommend an SBOM because that's what the whole guidance public feedback portion is about. However, nothing is stopping a company from submitting one, and the best companies are submitting them. So if you want to have smoother sailing, you don't have to wait. So the guidance is not for implementation until finalized.
But it's just so obvious it's going to make your life easier when you can discuss the risk not only in broad strokes, but down to the individual software packages. So I view SBOM actually helping with efficiency for getting things through. It's going to be easier to just say, "Look, we got this covered." Now, of course, if you've got 500,000 packages that haven't been patched for 10 years, I'm sorry for your pain, but you made that choice.
Paul Roberts: So you're already seeing it being used by MDMs [medical device manufacturers] in their submissions to the FDA for device approval. Is an SBOM part of that application process to the FDA?
Kevin Fu: I can't speak for FDA and I can't talk about FDA reviewing, but I can say from a manufacturer's standpoint, I know manufacturers that are submitting documents with (an) SBOM inside of it. It's definitely far from universal. But I'll tell you, the companies doing that are probably going to be testing out their workflows. And I think everybody is pretty reasonable in realizing there's not just a flag day where you go from zero to everything. And so I think the smarter companies are going to the FDA and working with them. They're sort of the first steps on SBOM to work the kinks out. And FDA has been publicly in the past quite clear about SBOM, that they intend to work with the constituents and they also see it as a moving target, just like the guidance evolves over time. Right now, FDA has stated publicly that it's more flexible about the machine readable format. It's not too prescriptive.
In the future what's that going to look like? I don't know. But if best practices start to move toward one particular format or another, I wouldn't be surprised if that becomes a new expectation. But at the moment, it's still sort of stage one.
Paul Roberts: The guidance on SBOM that came out of IMDRF talks about the variety of standardized machine readable formats for SBOM. There are a bunch of them. They kind of highlight a couple as possibly the most applicable to the medical device space. Do you get a sense that there's any standardization on which format to use for the SBOM or anything like that? Or is it really every MDM, every manufacturer kind of doing their own thing?
Kevin Fu: There's two ways to think of it. There's the recommended formats, and then formats that we say, 'Don't use.' I would say at this point in time, you're likely to see more standards that are saying, 'here are some good ones,' and probably not a whole lot of ‘'please don't use that.' I would expect, in the coming years after the marketplace learns a little bit more about the different kinds of SBOM approaches, maybe there will be a list of 'Please don't use that kind of SBOM in the future.' But at this stage, I think it's going to be more accepting. We're going to see which formats lead to the best safety and efficacy, among other desirable features.
If you think of it from an operation standpoint, the more mature ... healthcare organizations will see the value of SBOM and see how it's going to improve their ability to keep software up to date and better know sort of patch status. They're going to be able to do better at procurement time, avoid buying something that is going to be a target.
—Professor Kevin Fu
Paul Roberts: So one of the big questions is "how are the healthcare companies that are customers using the medical devices going to be able to incorporate this into their existing internal security practices?" Right? I mean, as you know, it's been hard enough to get them to just apply standard operating system and firmware updates. This is like a whole other level, and it's going to require them to adopt and embrace new methodologies and new processes. Is there much guidance on that, on ho healthcare delivery companies are going to operationalize SBOM?
Kevin Fu: Yeah, well, first of all, I think you'll see a lot of variation and there's no requirement. FDA doesn't even regulate healthcare delivery. They have zero say over that. Yeah, I view SBOMs at hospitals as sort of like a consumer going to McDonald's. Yeah, you can read the ingredient list, and you probably should. And you might want to avoid that one with so much salt (as I eat this potato chip). But that's your choice. You can eat salt, right? But if you think of it from an operation standpoint, the more mature organizations, healthcare organizations, will see the value of SBOM and see how it's going to improve their ability to keep software up to date and better know sort of patch status. They're going to be able to do better at procurement time, avoid buying something that is going to be a target.
Paul Roberts: Right. That seems to be one of the big advantages potentially for the healthcare delivery organizations: Being able to look at that SBOM prior to making a purchase decision and presumably say, "This thing's running Windows CE. Maybe we should be looking at something that isn't running Windows CE, which is no longer supported." Right? So, presumably that could have a buoying effect on device security, just generally, I think.
Kevin Fu: But it's all about transparency and choice, so the healthcare system doesn't have to use it. I can imagine a small healthcare system that does not need to use it. They might choose not to use it. I would say the more sophisticated organizations that have departments responsible for keeping software up to date are probably going to benefit the most. But the good news is it doesn't cause any harm. So just like putting up ingredient lists at fast food doesn't cause harm. There's only good that can come a bit.
Paul Roberts: What is the security utility, though? Is there less security utility if we can mandate that the device manufacturers produce SBOMs, but we can't necessarily mandate that their customers incorporate those SBOMs into their patching and device management practices? Are we going to get less of a bang from the SBOM than we thought if we can't make sure that it's actually utilized throughout the whole value chain?
Kevin Fu: Yeah, well, there's direct and indirect. And so I think what you're speaking to is sort of the direct way: more compliance. That's one pathway. You can also have business value. It just makes sense to use SBOMs. It's going to drive more value. But then don't forget there are the sort of pseudo regulators like The Joint Commission, although they traditionally have not been too active on cybersecurity.
But there's a new sheriff in town and they've recently changed their tune. They recognize, "you know what, yeah, we were kind of asleep at the wheel for 20 years and we've just woken up and we need to figure out this cybersecurity thing because it's affecting all of our hospitals." And, yeah, infection control is always going to be a top priority, but cybersecurity is on the list. So I would not be surprised if in the future, sort of certification of ability to operate, authorization to authorization to operate will begin to include more cybersecurity related information.
Imagine having robotic surgery and having no idea what's on the inside and whether it's been patched. So it's probably going to be measured in years, but I predict in years we will see either through regulation if the marketplace fails, but hopefully the marketplace is smart enough and self-regulates either through really good software or through things like the Joint Commission expecting to see it in the procurement process.
Paul Roberts: But of course, in the implementation it gets really tricky because you have many different types of medical devices, maybe actually different versions of the same hardware. Right? You have patches that are going out constantly and that may make SBOMs obsolete, but not all devices. Some devices get the updates, some don't. How do you anticipate hospitals --you think about the networks of small doctor's offices, primary care offices and stuff --how are they going to manage that type of challenge?
Kevin Fu: Well, I think a lot of it depends on the evolution of the tooling… It's kind of like you can buy tax software for the professional and tax software for the average consumer. Indeed, I predict we're going to see the SBOM companies producing a couple of different sorts of views to interpret the data. Awareness is better than no awareness, but actually carrying out the patching is obviously better. But being aware of just what percent of your devices are not up to date is going to be very helpful. So, for instance, when you go to the board of directors saying, hey, I got to up my cybersecurity budget this year, they'd say, why? Well, we're at the bottom 1% of the country in terms of being up-to-date for medical devices and it says here that we are the most susceptible to ransomware and oh, by the way, our cybersecurity insurance is about to skyrocket because we don't have SBOM right. That's what I'm talking about with incentives as well as just good practice.
Paul Roberts: Yeah, you've been working on medical device security for so long and like you said, I feel also like most of that time you were kind of screaming into the wind, just sort of like there are problems here. To the extent that there's now more awareness and urgency around it, why do you think that is? Is it the ransomware epidemic and just seeing hospitals actually impacted by malware? Or is it more technological evolution, just the introduction of remotely managed and medical devices that are connected to services and that whole thing.
Kevin Fu: All of the above. It's the perfect storm to make a nice Boston reference. It's a wicked storm. Highly, highly connected, like nothing we've ever seen before. We’re seeding decision making to the computer which used to involve a human in the loop. So we saw in April of 2021 the global outage of an entire radiation therapy oncology device across multiple health systems because of a cloud problem involving ransomware. And then you put on top of that things like some of the early malware that broke into just so many devices — WANNACRY as a key example. That was a wake up call, I think, when people began to discover just how much they really depend on technology for the purpose of delivery. I think I'm not the only one who's been raising alarms. There's quite a few organizations and really thoughtful individuals who've been coming from different perspectives. Sometimes the physician perspective, sometimes the patient perspective, sometimes the research perspective, sometimes the law enforcement perspective and they're all sounding the alarm on that from different vantage points. And it's just the confluence of all these events.
But I have to say the cybersecurity group, the tiny, tiny cybersecurity group at FDA, I've never seen a better managed group in my entire career in the private sector or universities. So we are just so lucky to have really good management there who understand how to get things done and have a long term vision and persistence measured in decades. So you can't say this universally against other marketplaces. So I think that's one of the key reasons as well.
Paul Roberts: I know that there was just that FBI alert that came out about the risk posed by unpatched medical devices. Sometimes the SBOM thing seems a little bit like a “crawl-walk-run” problem. SBOM is sort of running and a lot of these organizations are still really crawling from the asset management standpoint, right? They’re struggling with that. Struggling, staffing wise. Do we need to solve that problem before we can even talk about implementing SBOM or operationalizing SBOM within actual health care environments?
Kevin Fu: Well, I think it's not an either or. It's not sort of a black and white. I think you can begin, but I think the utility of SBOM will increase as we become more sophisticated in all these fronts. So I do think we need to set expectations. Don't expect things to be perfect on day one. And I don't think regulators are expecting perfection, they're expecting things to be better. So better risk management, better transparency. But, yeah, there's going to be a lot of known unknowns out there. Of course there’s going to be — again — some random software package was installed on this device. Oops. Is it the end of the world? Probably not. Should we hide it? Definitely not. That would be dumb. It's just a risk, so you’ve got to manage it.
Paul Roberts: Is there going to be a sort of 'look inside the sausage factory' effect with SBOMs, where people go: ‘Wow, they're using that software? Are they using that library?’ Are there going to be some, like, head slapping moments when medical device manufacturers start releasing SBOMs for their products?
Kevin Fu: It's made of people!
Paul Roberts: (Laughs.) You're the one who's eating lunch right now.
Kevin Fu: I'm sure there are going to be a couple of surprises in there where I can't believe we're all depending upon the FORTRAN code from so many decades ago. I would not be surprised, oh, look, they're using MUMPS inside of this old healthcare related yeah, that stuff is still there.
I mean, I will not be surprised. But the FDA is very level headed on this. It's not whether you use something or not, it's whether you mitigate the residual risk or whether the acceptable residual risk is within reason. So there are ways, if you have a limited set of really old, out of date software, to keep the risks in check. It has more to do with administrative controls and monitoring, but there are ways to be, in my view, reasonably secure. Not perfect, but we're never going to get to perfect, but keep it reasonably secure. So, anyway, I'm optimistic about it, but I also think it's the gradients. SBOMs will improve over time, we will be better about using them more effectively. And I just think we need to set expectations that, look, in the beginning, it's going to be more about knowledge and as we get further along in maturity, it's going to be about reducing risk.
Paul Roberts: Yeah, good distinction. Okay, final question. So if you're a medical device manufacturer, where should you go to kind of bone up on what you need to know now about SBOMs and steps that you can take to start getting in line with the guidance that clearly is coming down from on high from the FDA and elsewhere?
Kevin Fu: Yeah, well, I would say it's definitely a jungle out there. You've got a lot of different SBOM vendors. You need good advice. So if you're going to have a bake off between five or 10 different SBOM vendors, look for outside advice.
There are a number of consulting agencies in this space. I'm one of them, but there are plenty of others from my colleagues as well who specialize in different fields. But get some outside advice on that. That would be my key suggestion. Also, anyone who has taken an Introduction to Programming course knows that built into most modern programming development software, it's sort of a whole notion of cataloging. You can't have easily testable software if you're not already cataloging and doing all the automated regression testing. I mean, we did this 20-30 years ago with automated regression testing in PERFORCE. So these technologies are already out there. And I'll tell you, my Red Hat Linux box, I just type a single UNIX command and it tells me every single package on there. It's not rocket science. Okay, so it's doable.
Paul Roberts: But get some advice from somebody who's knowledgeable.
Kevin Fu: Yeah. And if you're coming from the medical device world, look for people who know about medical devices in particular who have been involved with a submission of a 510K or a PMA. If you're in automobiles, you're going to want to work with a group who has been involved with automobiles before, so you're going to find different kinds. So you could try to go to a generalist, I think, as well, but then your mileage may vary. So safety is defined differently for medical devices and cars.
Paul Roberts: So what are the differing concerns there? And you mentioned two verticals: automotive and medical devices. Is it just about the compliance piece of it and managing or being aware of that, or are there other concerns that make it advisable to have somebody who really knows the space?
Kevin Fu: Well, there are many differentiators. Number one is regulatory and compliance, but number two is supply chain. So the automotive industry has a very unique supply chain, and you're going to want somebody in that space who understands the role of the supply chain. So you might be getting firmware and software popping up from three or four levels deep. In medical devices, depending upon the risk category, you might actually see a fairly vertical device manufacturer. In fact, there are some medical device manufacturers who manufacture their own capacitors. I'm not saying all of them, but some will manufacture their own nice because they don't trust the chip manufacturing companies to do it right. So in automobiles, I don't think you're going to find a whole lot of automobiles getting fabs, I mean, maybe today since they're having trouble getting chips from China.
Paul Roberts: De-globalization. Yes.
Kevin Fu: Yeah. De-globalization. So I would say regulatory compliance as well as supply chain are going to be really important for whoever's doing that SBOM to just have a sense of how it all fits together, because these are the moving pieces that are to come together. You can also talk about aerospace, of course, nuclear weapons.
Paul Roberts: Kevin, thanks so much for coming in and speaking to us.
Kevin Fu: You’re welcome.
