Untangling Software Composition Analysis for MedTech Teams | Ep. 53 - Full Transcript | The Med Device Cyber Podcast

Hello and welcome back to another episode of the Med Device Cyber Podcast. Today we're going to be unpacking software composition analysis, talking about where the boundary of software composition analysis is, talking a little bit about SBOMs, SOUP, exactly where the line is between the two of those, and understanding a bit more of what makes up medical devices. I'm your co-host, Trevor Slattery, joined here by our co-host, Christian Espinosa. How are you doing today, Christian? "Yeah, I'm doing pretty good. Leaving tomorrow for St. Louis for some of the holidays. And I'm excited about this topic though. It's interesting because we have a lot of acronyms. We have SCA, SOUP, and SBOM. You know, it's like, let's make things much more complicated. And we have SAST. You know, some people loop in SAST under SCA and even DAST, you know. So, it's like a bunch of acronyms, acronym soup." I think there's a plague across the MedTech industry where we try to make everything into an acronym, oftentimes when existing acronyms already are in place for some other different terminology. But yeah, it's easy to get lost in the sea of letters and numbers all strung together. But I think it would be great if we can start by talking about what each of these items are and then we'll dive a little bit more into the details on each one and where it comes into play. But our main focus is that we'll go with the top down starting with the SCA or Software Composition Analysis and then we'll talk about how everything feeds into that. "Let's start with SCA. That's the high level, right?" Software Composition Analysis, as the name implies, is what makes up the software. It's a little bit different than some of the other types of testing or other types of analysis that we'll do, which are more focused on what's wrong with the software, not just what goes into it. Now, part of this process is the downstream effect. You can often times identify what's wrong with your software once you know what's in it. That's generally why we have to do these exercises. But at the highest level, Software Composition Analysis is figuring out a register of what goes into your product, the different source code that you have involved, whether or not you have control over it, and then we dive into some more granularity from there. How does this even occur, though? I would think if I'm a software developer, I wouldn't know exactly where all the software came from that I put into my code and my product. Well, oftentimes, it'll be that you have a big team working on a product. So, if you think for a larger medical device company, there might be hundreds of engineers working on a single project. They aren't going to be able to keep track of every single contribution that anyone else has made and across the entire company. So having a way to collect this all into a single place can be really, really helpful. Oftentimes, we may even see that certain dependencies you're including in a program will include other dependencies automatically that you may not have been aware of. So this is a great way to round that up as well. I think a newer problem that has come up in the past couple of years as well is people utilizing AI for their coding that don't actually know exactly what the AI is doing. I've seen just trying around with some of the different AI coding tools, the vibe coding platforms, and then I take a look at my SBOM that I generate at the end of it and I realize that I added 500 components in two hours and I have no idea what any of them do. Part of my concerns around AI development, and I know that there are guardrails in place to prevent that from happening, but it's definitely a situation I'm sure comes up from time to time. "You know, that's a good point. I forgot to think about AI, but I know someone that developed this like app, a mobile app using AI. They knew nothing about programming. They just kept telling AI what to do and it came up with this app where you could pick the closest coffee shop and then rate it or something. See, I mean AI is getting a lot better at coding and it is kind of crazy. Now anyone can just start making something." I have some concerns when people are using too much AI for developing medical software, for a laundry list of reasons, but as a general use case, I think that it's great for making something quick, like track down the closest coffee shop. Perfect fit for it, not too risky with that. You might get a bad cup of coffee, but that's about as bad as it goes. With medical devices, it's definitely more risky.