Untangling Software Composition Analysis for MedTech Teams

Trevor: 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? 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 loop in SAST under SCA and even DAST. You know, so it's like, it's like a bunch of acronyms, acronym soup. Trevor: I think there's a plague across the MedTech industry where we try to make everything into an acronym. Um, often times when existing acronyms are already in place for some other different terminology, but yeah, it's, it's easy to get lost in the sea of letter- 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... Christian: We'll start with SCA, that's the high level, right? Trevor: Yeah, our main focus is that we'll, we'll go with the top down. Starting with the SCA or software composition analysis, and we'll talk about how everything feeds into that. So, software composition analysis, um, 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. Christian: How does this even occur, though? I would think if I'm a software developer, I would know exactly where all the software came from that I put into my code in my product. Trevor: Well, often times 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. Often times, 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. Um, 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, you know, guardrails in place to prevent that from happening, but it's definitely a situation I'm sure comes up from time to time. Christian: 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 know nothing about programming. They just kept telling the AI what to do and it came up with this app where you could pick a, the closest coffee shop and then rate it or something. Trevor: 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. Christian: 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. So we talked about the software composition analysis. So what are all the parts that go into the software? Uh, we got third party libraries. Uh, you've got maybe AI written code that it could borrow a third party library, but it could generate the code itself as example. And we got the code that our software developers or engineers create themselves or, as we've noticed quite a bit, borrow from various websites, verbatim. So we're trying to like figure out where all this stuff came from. All the the pieces that make up the code. So we have traceability for everything. Trevor: Definitely. Yeah, and I think that you mentioned um, software engineers taking code straight off the internet. Unfortunately, it is something that we even see within medical use cases. Copying hard-coded credentials straight off the internet that then were able to try to replay against the device successfully. So, there is a lot that can go wrong with the makeup of a product. But there are luckily a couple of great tools that we can use to A, understand what we're building into the product a little bit better, and B, get some insights on what to do about it from there. I think the first and the main one is a software bill of materials, or an SBOM which is... Christian: So to be clear, this is a subset of software composition analysis, part of under that umbrella is the software bill of materials. Trevor: Exactly. You can think of it sort of as the output from the process of the composition analysis. So, with software composition analysis, you're identifying, trying to understand everything that makes up your code, be that something that you pull off the internet, a third-party dependency that you're using, code that you're writing yourself, or code that an AI is writing for you. All of that should get registered as who wrote the code, what version is it, what is the name of the package that you're using, you have a unique identifier to trace back to it, when did you generate this SBOM, who generated this SBOM. There are a bunch of different factors that you can feed into an SBOM, and then they're very granular meant to be tailored for whatever specific use case you have. Of course, under the context of a medical device, the FDA lays out some specifications for what they want to see with an SBOM, but as a general use case, it's a great way to think of pretty much the outcome of that software composition analysis. It's a registry of everything that you're building into the product, all of the materials that make up your software. Christian: So this is like if I purchased a Ferrari, I have the right to know like who made the spark plugs, where they came from, who made the the brakes, where they came from, the wheels, the tires, everything, right? It's like the components that make up the Ferrari. Trevor: Exactly. So, a good way to think about it with that example is when you're opening up the hood, think of that as the software composition analysis process. You're looking inside of the device, or in this case, inside of the car, to see exactly what is there, how are these different components connected. This can be another big important thing and that is an important part of SBOMs is how are you using specific components. You might directly just take a component and put it into the machine. You could think about the engine that the car is using. The engine is made up of a ton of different parts that are part of the engine, but you wouldn't say directly interact with the rest of the car. These can be thought of as dependencies of a dependency. And that's the way that we need to structure these bills of materials. Unfortunately, SBOMs are usually a lot less cool than opening up the hood of a Ferrari, but the same general concept can apply. Christian: Oh, the last Ferrari I looked at the, 488 Evo Challenge, uh the engine was in the back for balance. So it wasn't under the hood, per se. Trevor: Oh, well, there you go. Under the... Christian: Same concept though. You could still, you could see the engine through the the plastic, um, covering of it, yeah. Trevor: Oh, one of those like you can see through the back, that's cool. Christian: Yeah, yeah. I didn't drive that car because the track was too wet, it was too dangerous to drive on the car so I did the Pista instead when I was in Vegas. Um, but yeah, it from a risk perspective, we want to have transparency. So if a healthcare delivery organization or a user of a medical device is going to make a decision about purchasing this device and putting it in their environment, they have the right to know what components make up that device. What, if there's a, you know, like if there's a vulnerable third-party library that's vulnerable to Log4j, as an example, they may not want to put it on their environment. Trevor: Exactly. And this can even apply outside of, well, of course, it is an FDA requirement, so it's not something that you should try to omit when submitting with your cyber devices. But one question that comes up from time to time is I'm not subject to FDA or, you know, I'm not even in the medical space. Do I still need to think about SBOMs? And while you may not have to, they're just a great way to understand what goes into your code. It's overall, I think a recommendation for anyone building software to understand what components are in their system and how they're using them. Especially on larger, complicated projects, like I was saying when you have multiple engineers working on a single project, things can get out of hand very quickly where people start losing track of what exactly has been used where. And so having a good, clean registry of that so that you know exactly where everything is being referenced to is a perfect way to bridge some of those problems. Christian: Yeah, and like you said, it's it's more of a best practice. I know Slack, uh, we use Slack in our organization. They have their SBOM publicly accessible. So if if I wanted to like really do some scrutiny, I could look at all the third-party libraries and make a decision like maybe we don't, we shouldn't use Slack, we should use something else. Trevor: You might identify, oh, well, this vulnerability has a known exploited CVE in it and we don't want to be subject to that risk. So we're not willing to take on that risk. We're going to use Teams instead, even though we would never use Teams. We're still die-hard Slack. Christian: Just like we never use iPhones. Trevor: Exactly. Christian: It was funny when I was in Vegas, Melissa had a couple nursing friends with her, and one of them had an iPhone, and whoever has an iPhone, you they make it known that they have iPhones. So every picture had to be with her iPhone because it took so much better pictures than everyone else's phone apparently. Trevor: Well, I will give them credit on iPhones having pretty good pictures, but I just got my new Samsung and they figured out how to bend glass on these new ones. And so, I think Android just wins by default with that. Christian: You can't do that with an iPhone? Trevor: No. I I'm sure it's something they're working on, but, yeah, they don't have any available iPhones where you can bend the screen. Christian: Interesting. Trevor: And there are a lot of Androids that can do that now. Like tons of them. They're all these Chinese phones they're making that can bend in every direction. It's really cool. Christian: Another reason to stick with Android. Trevor: Exactly. Christian: All right, so we talked about SBOM, SOUP, copyright, copyleft, machine-readable formats for SBOM, the types of formats that are acceptable. The common thing I hear a lot of people talk about is they think SAST, Static Application Security Testing, is part of SCA, or Software Composition Analysis. Is that a fact or fiction? Trevor: Well, they are similar processes from a technical perspective, which is where this can often come up as a point of confusion, but from a purpose for the outcome of these activities, they are very different. So, SAST, or...The binary answer is no, they are not the same. It is false to say they go into the same area. But they do look very similar. Even when we're working through the process, we tend to run both checks at the same time under a nearly identical workflow. So it's easy to make the, you know, distinction that they're the same, but they are accomplishing different goals. We talked about some of the goals of software composition analysis, and at its source, it is trying to understand what goes into a product, having a registry of it. Static application security testing, or SAST, uh, this can be similar with dynamic application security testing, or DAST, are when we're taking a look at a source code, or it can be a pre-compiled binary, but something in a static use case, and trying to understand what vulnerabilities may be present in that source code. This can be through, if you're running SAST against any third-party components that you're bringing in as well, any open-source components, you may identify vulnerabilities there introduced by the original engineer working on those components. It may be your engineers that are building code to exis- integrate into your product, and you're running SAST against those to make sure that they aren't leaving hard-coded credentials, introducing the potential for memory leaks into the system, not properly sanitizing data where they can introduce the risk of an injection attack. But pretty much this is a focused look into the way that code is written to see if that is introducing risk into the system. Not so much concerned about what the code is, where it is, what it's doing, just saying, are there vulnerabilities in it? Christian: So, it can't be used, uh, to help identify vulnerabilities, but it's technically not part of the software composition analysis. Trevor: Correct, yep. And oftentimes, and we would recommend you can have them in a single workflow. You can run through your SAST as you're generating and analyzing your SBOM. Since they are largely independent processes, but they work really similarly. The tools oftentimes are performing, obviously very different checks, but they're doing it in a similar fashion, on similar infrastructure, and you can see the results in similar dashboards and output. So, running both as a single process in your continuous integration and continuous deployment systems is a great way to handle it. Christian: I think we've covered everything pretty well here, so we're coming up on time. So what's some last-minute words of wisdom, Trevor? You've always got... you've always got... you gotta deviate from the ones you normally say though, a little bit here. Trevor: I've been trying to mix it up recently. I'm coming up with a couple of new ones. I think a great one is know what is in your product. It is crazy how often this comes up where we're identifying, we're generating an SBOM and we hear, "Oh, we didn't even know that was in here." So, understand what you're building into your source code. There are a lot of different ways to do this, even if it's someone, you know, editing an Excel sheet to say, "Hey, I added this new library." Obviously, that's not the ideal way to do it. We talked about SBOMs as a better approach, but understand what you're building into your code, understand when it changes, and then understand that downstream effect. So, know what you're making. Christian: It's important to know all the ingredients that make up your product. And it's surprising how many people don't know where things came from. But there is a big push for that transparency and that traceability. And I think we're making progress. Trevor: Yep, I think it's getting, it's getting better day by day that goes on, but it's still all these requirements are still fairly new, so there's still ways to go for sure. Christian: All right, awesome. Well, thanks so much for tuning in to the Med Device Cyber Podcast. I hope you found this episode on SCA, software composition analysis, and SOUP, and SBOM, and SAST, and a little bit of a different type of soup in terms of, uh, word and insane origins, useful. So, hopefully, we'll see you on the next episode, and have a great, uh, day.