Skip to main content
    All Episodes
    Episode 054 · January 6, 2026 · 28m listen

    Untangling Software Composition Analysis for MedTech Teams | Ep. 53

    Episode Summary

    This episode of The Med Device Cyber Podcast untangles the complexities of Software Composition Analysis (SCA) for MedTech teams. Hosts Trevor Slattery and Christian Espinosa demystify SCA, differentiating it from related concepts like SBOMs (Software Bill of Materials) and SOUP (Software of Unknown Provenance). They emphasize that SCA is the foundational process of identifying all software components within a medical device, including third-party libraries, internally developed code, and even AI-generated code. The discussion highlights the critical role of SBOMs as the output of SCA, providing a comprehensive registry of these components, crucial for transparency and risk management, especially in light of FDA requirements. The hosts delve into the nuances of machine-readable SBOM formats like CycloneDX and SPDX, explaining their importance for regulatory submissions and industry standardization. Furthermore, the episode addresses the evolving landscape of software licensing, particularly

    Key Takeaways

    • 01Software Composition Analysis (SCA) is the process of identifying all software components within a medical device, serving as the foundation for understanding its composition.
    • 02A Software Bill of Materials (SBOM) is the output of SCA, providing a comprehensive registry of all software components, critical for transparency and regulatory compliance with the FDA.
    • 03SOUP (Software of Unknown Provenance) refers to software whose origin, build process, or purpose is unclear, posing significant risks that should be addressed during development and analysis.
    • 04The FDA requires machine-readable SBOM formats like CycloneDX and SPDX for submissions, enabling efficient data exchange and analysis by automated tools.
    • 05While Static Application Security Testing (SAST) and SCA both identify software-related issues, SAST focuses on vulnerabilities within the code itself, whereas SCA identifies the components present in the software.
    • 06Understanding all components in a medical device product, including their origins and licenses, is crucial for effective risk management, compliance, and addressing potential supply chain vulnerabilities.

    Frequently Asked Questions

    Quick answers drawn from this episode.

    • This episode of The Med Device Cyber Podcast untangles the complexities of Software Composition Analysis (SCA) for MedTech teams. Hosts Trevor Slattery and Christian Espinosa demystify SCA, differentiating it from related concepts like SBOMs (Software Bill of Materials) and SOUP (Software of Unknown Provenance).

    • Software Composition Analysis (SCA) is the process of identifying all software components within a medical device, serving as the foundation for understanding its composition. A Software Bill of Materials (SBOM) is the output of SCA, providing a comprehensive registry of all software components, critical for transparency and regulatory compliance with the...

    • This episode covers SBOM Management and FDA Premarket Cybersecurity. It's part of The Med Device Cyber Podcast, hosted by Blue Goat Cyber, focused on practical medical device cybersecurity guidance for MedTech teams.

    • They emphasize that SCA is the foundational process of identifying all software components within a medical device, including third-party libraries, internally developed code, and even AI-generated code. It's most useful for medical device manufacturers, cybersecurity engineers, regulatory affairs professionals, and MedTech founders...

    • Software Composition Analysis (SCA) is the process of identifying all software components within a medical device, serving as the foundation for understanding its composition.

    Listeners also asked

    Quick answers pulled from related episodes.

    Share this episode

    Pre-fills with: "Software Composition Analysis (SCA) is the process of identifying all software components within a medical device, serving as the foundation for understanding its composition."

    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. "So, we talked about the Software Composition Analysis. So, what are all the parts that go into the software? You've got third-party libraries, you

    Hosted by

    Explore every episode in the topics covered here.

    More from your hosts

    Other episodes diving into Christian and Trevor's areas of focus.

    Episodes covering similar ground - including SBOM, FDA Premarket.

    Why this matches shares the SBOM topic and covers similar themes around machine-readable, formats, cyclonedx.

    Why this matches shares the SBOM topic and covers similar themes around components, sboms, differentiating.

    Why this matches shares the SBOM topic and covers similar themes around sboms, transparency, serving.

    Why this matches shares the FDA Premarket topic and covers similar themes around submissions, emphasize, during.

    Listen to this episode