Episode 44 · January 6, 2026 · 28m listen · 3,036 words · ~15 min read

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

Read the complete, searchable transcript of Episode 44 of The Med Device Cyber Podcast - expert conversations on medical device cybersecurity, FDA premarket and postmarket guidance, SBOM management, threat modeling, and penetration testing.

Prefer the listening experience? Open the episode page for the synopsis, key takeaways, topics, and Apple / YouTube listen links.

Episode summary

In this episode of the Med Device Cyber Podcast, hosts Trevor Slattery and Christian Espinosa provide a detailed breakdown of Software Composition Analysis (SCA) and its related concepts within the context of medical device cybersecurity. The discussion aims to clarify the often-confusing web of acronyms that dominate the field, including SCA, SBOM (Software Bill of Materials), SOUP (Software of Unknown Provenance), and SAST (Static Application Security Testing). The hosts begin by defining SCA as the overarching process of identifying and cataloging every single software component that makes up a product. This includes proprietary code, open-source libraries, and third-party dependencies, creating a complete inventory to understand the software's DNA fully. The central argument is that in today's complex development environments, it is no longer feasible for developers to intuitively know everything that is in their code. Large teams, the use of third-party libraries that have their own dependencies (transitive dependencies), and the recent rise of AI-assisted coding all contribute to a lack of complete visibility. This is where a formal SCA process becomes critical. The primary output of this process is the SBOM, which the hosts describe as a machine-readable "list of ingredients" for the software. They emphasize that the SBOM serves as a foundational tool for security, enabling transparency and allowing both manufacturers and healthcare delivery organizations to assess the risk associated with a device by cross-referencing its components against known vulnerability databases. The podcast further distinguishes between these concepts by introducing SOUP, defined as any software component whose origin or development history is unknown or undocumented. This could be code from a former employee that was not properly documented or snippets pulled from the internet. The hosts clarify that while SCA is the process and SBOM is the output, SOUP is a classification for high-risk components within that SBOM. They also draw a clear line between SCA and SAST, explaining that while both are security testing methods, SCA focuses on identifying *what* components are present, whereas SAST analyzes the source code itself to find vulnerabilities in *how* it was written. By understanding the composition of a device through SCA and an SBOM, teams can more effectively target their SAST and other security testing efforts, ensuring a more robust and secure final product.

Key takeaways from this episode

Software Composition Analysis (SCA) is the comprehensive process of identifying every software component within a product, including proprietary code, open-source libraries, and third-party dependencies.
A Software Bill of Materials (SBOM) is the main output of SCA, serving as a formal, machine-readable inventory of all software 'ingredients,' which is essential for security transparency and risk management.
SOUP (Software of Unknown Provenance) refers to software components with no traceable origin or documentation, which are considered high-risk because their security cannot be verified.
SCA is distinct from SAST (Static Application Security Testing); SCA identifies what components are in the software, while SAST analyzes the code's implementation to find security flaws like hard-coded credentials or memory leaks.
The complexity of modern software development, including large teams and dependencies that pull in other 'transitive' dependencies, makes it nearly impossible to track all components without a formal SCA process.
The use of AI in coding is a growing concern, as it can introduce code and dependencies of unknown origin, increasing the amount of SOUP in a product.
An SBOM must be in a machine-readable format (like CycloneDX or SPDX) for regulatory submissions, allowing for automated ingestion and analysis by entities like the FDA.
Having a complete inventory through an SBOM enables organizations to quickly identify if they are affected by newly discovered vulnerabilities in open-source components, such as Log4j.

Topics covered in this transcript

SBOM Management

Full episode transcript

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.

1 / 4