SBOMs Unpacked: Myths, Risks, & Benefits with Cortez Frazier Jr. | Ep. 13

In this episode of The Med Device Cyber Podcast, hosts Trevor Slattery and Christian Espinosa are joined by Cortez Frazier Jr., a Principal Product Manager at Fossa, to discuss the critical role of the Software Bill of Materials (SBOM) in modern medical device cybersecurity. Cortez brings a unique dual perspective, having worked as a Cyber Security Architect at GE Power, where he managed security for hundreds of applications, before moving into product management to help build better security tools. His company, Fossa, specializes in Software Composition Analysis (SCA), which evolved from managing open-source license compliance to comprehensive security and SBOM generation. The conversation centers on the transition of SBOMs from a niche concept to a regulatory necessity, driven by major supply chain incidents like SolarWinds and subsequent government mandates, including the White House Executive Order and new FDA requirements. The core of the discussion unpacks the practical challenges and misconceptions surrounding SBOMs. A major argument addressed is the resistance from some manufacturers who fear that publishing an SBOM is akin to providing a 'playbook for attackers' or exposing valuable intellectual property. The hosts and guest collectively debunk this idea, arguing that true IP lies in the proprietary code and its unique implementation, not in the commodity open-source components it utilizes. They emphasize that security through obscurity is an outdated and ineffective strategy; if an SBOM reveals a long list of unpatched, critical vulnerabilities, the problem isn't the disclosure but the underlying poor security posture. The podcast frames SBOM transparency as a powerful forcing function for better security hygiene throughout the development lifecycle. Beyond just creating an SBOM, the episode delves into the more complex problem of what to do with it. With SBOMs often revealing a 'sea of vulnerabilities,' the conversation shifts to effective prioritization strategies. Cortez outlines a multi-tiered approach to move beyond simply chasing high CVSS scores. A more mature strategy involves leveraging data like the CISA Known Exploited Vulnerabilities (KEV) list and the Exploit Prediction Scoring System (EPSS) to focus on threats that are actively being exploited in the wild. The 'holy grail' of analysis, as Cortez describes it, is reachability—determining whether the application's code actually calls the specific vulnerable function within a third-party library. This context-aware approach dramatically reduces noise and allows teams to focus on risks that are genuinely exploitable. The discussion concludes by highlighting the unique difficulties in the medical device space, such as the high cost of post-market remediation for deployed devices and the challenge of identifying 'SOUP' (Software of Unknown Provenance), making proactive SBOM management and vulnerability triage essential from the earliest stages of development.

Trevor: Welcome back to the Med Device Cyber podcast. I'm joined here by our co-host Christian and then our guest Cortez from Fosa. How's your day going Cortez? Cortez: My day is going fantastic. I really appreciate you Trevor and Christian for having me on. Um, you know, obviously Trevor you came and did a a fantastic webinar for us and so I'm super excited to be able to kind of return the favor a little bit. Um, FYI apparently there's a whole bunch of winter storms um coming up here very very quickly and so that I'll as someone who lives in the south I typically don't get to see snow that often so I'm excited to maybe get an opportunity to build a snowman. We'll see. Christian: Where where are you based out of? Cortez: Um I'm based out of Atlanta, Georgia. Um and so yeah, very very rarely do we get snow. But we got it a couple of weeks ago, which was pretty exciting. Christian: Yeah, I'm in Phoenix area. I don't think we get uh in the valley. I don't think it's ever snowed here in the valley. Trevor: I think it's snowed in like 1921 once. Christian: Probably yeah. Christian: Awesome. Well, thanks for being a a guest uh Cortez. And um maybe tell us a little bit about what what you do and what Fosa does. Cortez: Yeah, I would love to to kind of give a a bit of a background and you know happy to go in as much detail as you like. So um obviously my name's Cortez, thank you for the introduction. I'm a principal product manager um on at Fossa. Um Fossa is um got its roots as a uh traditional I'd say SCA company, software composition analysis. Um we started um in the license compliance space and then because we were already doing such high quality component analysis, it was a very natural leap um to then get into uh the security side of that. Cortez: Um also very similarly, having already generated an accurate list of components and um component relationships and license information vulnerabilities, that then is also uh a very nice transition and natural step um into software bill materials which um I I love when the regulation um calls things like an inventory of bespoke assets um that we have to to try to uh to understand. And so, um that that's Fossa at a high level. Cortez: Um for my personal background, prior to working at Fossa, um I worked as a product manager in a few other companies. Um I'm I'm mostly puppet. Um if you're familiar with that, they were kind of a Devops and automation I'm a suite of tooling. Um and then prior to then is actually where I got my start in the cyber security space working for what was GE Power at the time, now GE Vernova. Um I was a cyber security architect there. Cortez: So responsible for about um 1800 developers, about 600 applications. It's where I really started to get very intimate with some of the problems that are my customers now deal with. Um and after doing that as a practitioner for a few years, I decided I will for lack of a better term go to the dark side and see if I can help make some of these products a bit better um rather than just complaining about them. So, um that's a bit of my background but but yeah I I look forward to diving much deeper um into kind of what Fossa does and you know how, um I I think this uh the the SBOM and medical device security space in general starting to grow. Christian: Cool, I think I think we'll zoom out for a second uh cuz this term S bomb not everybody probably understands S bomb. Uh but it's interesting because I've been involved with Medtech cyber security since like 2014 and and even back then there was the S bomb and people were doing S bomb but it seems like now it's just becoming more of a I guess mandate that people do it. So could we can we just unpack like what exactly is an S bomb and and, you know, what are some of the concerns with S bombs? Cause I know a lot of our clients and prospects don't want to make the S bomb public, you know, they have some concerns about it. So what can we just uh you know, I guess dissect that a little bit, unpack it. Cortez: Yeah, let me uh take an initial pass then, you know, Trevor, feel free to add any additional comments that you have from your end. So from from my perspective, you're 100% right, Christian that a S bomb stands for software bill materials. Bill materials have been a thing for a long time, right? You know, you got um different companies have used this and and various assets. I've actually I feel like Cyber security 101 is you cannot defend or protect something that you don't know exists. And so getting an accurate and up-to-date inventory is always priority number one. And so, um my read on how the industry has reacted is for a long time a lot of people were maintaining these lists of um both open source and commercial components that they were using in very, you know, archaic ways, right? Typically Excel sheets, which I love Excel, it runs the world, no problems with that. Um but it is really difficult um for people to digest Excel sheets at scale and then be able to do any type of ongoing analytics um about that. Cortez: In particular, as we know, new vulnerabilities appear every day um for existing open source or closed source packages. Um and so my read is that uh you know, unfortunately when the Solar winds event happened, that kind of put the world um on notice that, hey, often times we're relying on these third-party software what they will call the software supply chain um if you will. Um and and that is actually like a big area of risk. A lot of people were not actively paying attention to. Or maybe they were paying attention to it but often times it was this initial security review that would happen. And you do a third party risk assessment, you go through all the architecture diagrams, you have them show, you know, vulnerability reports and SOC2 reports and all that good stuff, but that doesn't help you from an ongoing maintenance perspective. And so, um, you know, the executive order, I think 140 um 28 came out, really kind of kicked off this um first initiative that, hey, we have to start paying attention um to some of these uh third party um risk that we're kind of consuming and there was no really good ways to do it at scale at that time. And so, um that is where SPDX and Cyclone DX I think really started to gain traction and these um for those that don't know are two um what they call machine readable um formats for S-bombs. Cortez: And so taking what we were doing in Excel sheets for a really long time, putting that in a structured format um in the form of SPDX or CycloneDX, which then allows for whether you're distributing that to someone or receiving an S-bomb to actually ingest this in a machine readable way, um and then put that into, you know, other things that you're doing from a vulnerability risk management standpoint. So, that's kind of my read on, you know, how S-bombs it kind of gained traction and popularity. We'd love to hear um any of your thoughts there as well, Trevor. Christian: Well I I I I just want to say I thought the I think it was the shell shock attack was a a good impetu for S bombs as well because a lot of medical device manufacturers didn't even realize they were lying on bash for instance and a lot of other organizations. And what do you think Trevor? Trevor: Yeah, I think that, I mean there are a dozen if not, you know, hundreds and thousands of different vulnerabilities you can point to in the Sbomb where I don't think that manufacturers are always aware of how many problems there are. I'd say by far the most common vulnerable component that pops up with the companies we're working with is Log4j. Like from whenever that was, six years ago when the first Log4j problems started coming out, manufacturers are still using these out-of-date versions, and they just didn't know it was a problem. Or they've been developing their product for so long, they just never bothered to deal with all these legacy components that are built in initially, and then they eventually became vulnerable. They're just, it's a very constantly evolving landscape. Kind of like you mentioned Cortez, Sbombs contain a list of everything and everything is going to get a vulnerability at one point or another. Trevor: Uh, I think one distinction that is becoming a little bit more clear is what is significant out of out of the S bomb, what vulnerabilities really matter, since realistically, it's impossible to have perfect security. I know um one of our testers at Blue Goat that did his master's thesis on proving a piece of code to be 100% secure. It was like 70 pages of proof for three lines of code or something ridiculous like that. Trevor: It's impossible to have perfect security. So, understanding what are what are the big targets, how can we get to that, you know, 99% mark, I think is something key. And I know one initiative is the CISA Known Exploited Vulnerabilities list, which is showing the the CVEs that have actually been exploited, CVEs being like a known vulnerability in a certain component. And then a subset of those are the known exploited vulnerabilities. So ones that are actively exploited in the wild, ones that threat actors are using to try to gain access to systems. Um like Log4j, I think there are numerous vulnerabilities in Log4j in that list and then just about every firewall and network appliance you can think of is in that list. So understanding what are the big bullet items. And I'm curious to hear your thoughts on how to prioritize, you know, when you have a sea of problems, how do you figure out what's what's the focus? Cortez: Absolutely, I have many, many, many thoughts um on this particular topic and so you'll have to cut me off if I go too deep but uh I I like to think about exploitable in a few um orders of magnitude, right? And I think uh the least uh or the lowest fidelity is just a CVE in and of itself, right? And that's, you know, no shade in any way shape or form to MITRE or any of the security researchers doing all this awesome work. Um but determining that a um potential vulnerability exists is is one thing and that can, you know, it can be exploited. Cortez: And so you have a CVE that's generated, um meaning I have a open source or close source dependency I'm using, a vulnerability has been researched, and someone has posted that vulnerability publicly. That is kind of the lowest fidelity in my opinion, but at least starts to give you a signal that you may need to watch out for this. Um from there, you then have, you know, what you're alluding to, Trevor, which is things that are on the CISA Kev list and there's a few other like exploit DB and others where we say there's either an active threat campaign out for this particular vulnerability or there's been a proven exploit in the wild that you can just go download from exploit DB and try it yourself if you would like. Cortez: And so that is now an order of magnitude of likelihood of exploitability that I would be really concerned about. Um from there you then start to get into things that are more difficult to do from a pure S bomb perspective, but you can do um if you can, you know, start to get access to source code. And which are going to be things like a reachability analysis. You may have heard this term before, which is not just is this particular package in use, which is like one um form of reachability, but also is this package in use and am I using the vulnerable component of that particular package? And so that could be a vulnerable function or symbol or, you know, call uh network configuration, all that kind of good stuff. Cortez: And then lastly, um the the holy grail in my opinion is where you can then say, yes, I'm using a vulnerable package. Yes, an active threat campaign is active for it. Yes, I am also using a vulnerable function or symbol that's associated with it and I am using it in a vulnerable way. And that last piece, that last mile is often times forgotten about and that's where a lot of developers get really mad at us security professionals for um, you know, making them, um research and evaluate and and that's where your 70 page um thesis typically come from to prove um that that is actually not not the case. And so, having that framing, you know, for a second, there's then like, oh, well, how do you start to get some of these additional levels of fidelity for you to be able to make some of these decisions? Cortez: I think there's some fairly naive ways that I think are are fine because you don't really have too many options. Um I think that's what you'll see things like, oh well let's focus on, you know, direct um dependencies because those are one that we can most um directly influence from like an uh remediation standpoint. We'll focus on, you know, critics and highs because those feel like the most urgent and um we will do that only in our um, you know, business critical applications. They're internet facing, they, you know, rely on some super critical system for us. They help us make money, some of those type of things. Um and I think that is actually perfectly fine. I I it's not the highest level of fidelity, but I think it's a great starting point. And if I was someone drowning in CBEs, that's absolutely where I would start. Cortez: Um I think there's some other uh prioritization methods that are really, really interesting to start to consider. Um one of them that I'm a really big fan of is Eps. Um if you're not familiar with it, it's the exploit predictability scoring system. Um I I I like to think about CVE as or the CVSS, the the scoring which drives CVs from like a 0 to 10. um 10 being most critical, zero being you at least critical. Cortez: Um that is an estimate of the possibility of a particular exploit where EPSS attempts to quantify um of a particular vulnerability being exploited and it changes pretty rapidly in time. And so there's actually a really a lot of really um awesome research about how you can manage EPss threshold to the score if you will. uh to then be able to have the most coverage um from an overall uh exploitable standpoint with the least amount of effort. um meaning the least amount of time wasted on false positive vulnerabilities, which will then equate into this kind of efficiency um equation, which I think um from the research that I've seen, um it tends to be more accurate at actually dealing with um true positive vulnerabilities as compared to purely looking at those that are critical and high. Cortez: And so if I was trying to get to like a second order of fidelity, I would do that based off an EPS threshold, still focus on those direct dependencies, still focus on those applications that have some type of criticality, right? Internet facing, um highly relied, lied upon. Um I'll pause there for a second because I know I just threw a lot of information at you. There's a few others that I I I'd probably think about, but I I want to make sure we have an opportunity to digest it. Christian: Yeah, I have a a a question based on what you're saying. Um, I used to work in the DOD and you know, we had it's like there's a CVE, there's a risk level associated with it, and then you just patch everything, right? But it sounds like, uh maybe the industry is not really migrating, maybe, you know, we're just aware of these these exploitable, you know, exploitable factors and other things. But you know, in the Department of Defense is like we just patch things based on it wasn't exploitable at all. It was really just on CVEs alone. But it sounds like, I don't know what the percentage is, that the majority of CVEs don't actually have an exploit that can take advantage of it. So we're like not prioritizing correctly, at least the DOD was and they probably still aren't. Probably most organizations are not. But is is the industry do you feel as a whole like shifting more towards these other factors so we can better prioritize like Trevor said this sea of vulnerabilities or sea of CVEs out there? Cortez: That is absolutely what I'm seeing. I'm both in our customer base and in you know, potential prospects, which um, from a an overall standpoint, vulnerability detection is a relatively solved problem. I mean, there's all kinds of high-quality SCA tools out there. There's all kinds of high-quality tooling that will surface vulnerabilities towards you. Where the the the two next horizons are one, how do I qualify out vulnerabilities that I'm actually not exploitable in? I mean, you know, you have some improper input validation CVE, but that particular application you're using doesn't take any user-provided inputs whatsoever. And so unless you're going to perform a sequel injection on yourself, you probably don't have to worry about it, right? Cortez: And and and it's like those type of scenarios that you're you're starting to see a lot of people spend a lot of time on. And that's actually where, you know, things like um VEX, the vulnerability exploitability exchange and VDR, the vulnerability disclosure reports, which are these additions to a software bill material where you can actually communicate, yes, the CV exists, um but there it's not we're not affected by this particular CV and here's a justification why. Cortez: Um I think even beyond that though, which is, you know, not just qualifying out, but then also how uh can we start to do auto-remediations? Um Trevor alluded to a point that I think is actually super critical which often times when, you know, a big celebrity like Log4j event happens. Um it's not so much the impact of the vulnerability that's massive. It's that you can't remediate it because the upgrade that package might require a complete refactor of your application depending on how legacy um it happens to be. And so a lot of customers and and what we're really like championing is how do we try to get you into doing more updates, patching, you know, you can call that Christian and updating your your packages prior to the celebrity CVs coming out. So that way you're not putting yourself in a position where you're only um ability to remediate those is to do some type of out-of-band remediation, you know, some type of firewall protection, isolate the asset, those type of things. Trevor: I think one thing especially in the medical space. Um with medical devices, they're you know class one, two and three with class one having the least potential impact, class three having the most potential impact if something goes wrong. And all of these are governed under IC 62304 which is software life cycle design considerations for a medical device. And they're talk about that exact thing that you were mentioning where it's looking at, what is your policy? What is your procedure for ingesting a third party component? How are you maintaining it and tracking it? Um in medical devices in general security is a sliding scale. The less complex a device is, the less considerations need to be in, you know, placed in the device. Trevor: With these more critical devices, the thought that needs to go in before you're just taking any component to do a function is pretty significant. There's a heavy lift that needs to be done when you're vetting a third party component and making sure that they stay maintained continuously. It's great if you find a safe component, you think it's going to be maintained for a while. So you're not concerned about it from like an onboarding perspective. But if you just leave it and forget about it for two years, naturally it's going to come up with some problems that are going to need to be addressed. If you're letting it get to that point too, shifting up two major releases versions is often going to be an impossible task and it's going to require a refactor of the code like you said. Trevor: So trying to stay on top of it, making little changes every time there's a minor version is going to be a lot easier of a shift as opposed to making these major overhauls anytime there's a major significant problem. Cortez: Absolutely. And and the medical device space in particular is even more challenging. I would put the medical device space and maybe automotive and a few other embedded system spaces as particularly challenging because once you ship a device to a customer, the the effort to bulk remediate a vulnerability is uh immense, right? You know, you're talking about, you know, complete recall levels or having to go side by side in order to actually ship particularly these updates. And particularly because a lot of these devices are not fully internet connected, right? Meaning that they may have a little bit of internet connection in order to manage, you know, say a SAS application that goes along with it or something of that nature. Cortez: But often times there's no formal OTA process um for a lot of these medical devices. And so there's actually another framework that I it's a bit too rigid in my opinion, but I think it's a great starting point, um called SSCC, the stakeholder specific vulnerability categorization. Um it's essentially a decision tree that allows for you to walk through, you know, decision points like is this vulnerability exploitable. Is this particular asset, you know, highly critical? Um is there, you know, other proof? And you kind of walk through to then make a determination on if you need to act immediately on this vulnerability or not. Cortez: Um and and I think that, you know, having really good policy and frameworks in place for making that decision making is actually almost even more important than remediation if you're a medical device manufacturer giving the the impact. I'm not going to have if you do have to make something that um that critical of a decision. Yeah. So something, uh I know in the medical device space, there's a big push towards transparency. And Trevor and I've had this discussion many times and we've had it with manufacturers like, you know, if I if I go buy a car, I think I have a right to know like the bill materials, like we're talking about, like who makes the brakes, who makes the carburetor, who makes the spark plug? Then I can make an informed decision about the car and I know where things are coming from. Christian: And it's the same thing with if I buy a medical device, I should have, know where all the components of the software come from. A lot of our manufacturers or clients and a lot of manufacturers we deal with have like this resistance about providing a bill of materials, the S bomb to one of their clients. And can you maybe touch upon like, why they, why is there that resistance? Because I, I, I think it's kind of unfounded. But I just want to hear your, both of your opinions on that. Cortez: Yeah, I I'll I'll take an initial stab at this one. We'd love to hear um others' thoughts. So I um I hear this one a lot actually and it's not even just in the medical device space and and just about every industry and I think it comes from a bit of an older mindset of well, we cannot give people access to our IP in anyway shape before and everything that we've either developed or put our hands on is intellectual property um as for concern. And I think that's fair. I think that's a fair, you know, perspective. Cortez: I think in practice if you analyze what an S bomb truly is, right? Often times it is a list of components. You'll have, you know, some metadata about the S bomb itself, who generated what tool, Generate it, right, the name of the project, the component you have a component name, um a component version, maybe a unique identifier if you're lucky in the form of a package URL um or a C. Um and you know, some license information. And that's it, right? You know, maybe I'll have some authors and few other fields. I'll say over simplifying here, but um for the most part, that is the only information that is provided. Cortez: And so, from my perspective and and from my client's perspective, your intellectual property is not your usage of, you know, anti colors and you know, nojs, right? Your intellectual properties uh your intellectual property is the way that you're using both close source and open source components is much more important and that is pure source code um at that point in time. I can assure you that your developers are doing what all developers are doing which we're all Googling and hopping on stack overflow and maybe now usingr and, you know, cursor and a few of these other tooling um to kind of get us there and and none of that is proprietary whatsoever. Cortez: Um now, I will say that there is a um and and and and the kind of second piece of this stack I want to address is often times I'll get pushed back to say that, okay, well IP is one, but are we not giving potential threat actors a road map for how they can go and you know, exploit us because they know all of our open source components and they know what vulnerabilities are there. And and that is also in my opinion a bit of a misunderstanding about how threat actors tend to operate meaning very rarely are they looking to almost uh I call it vulnerability sniping where you're looking for just this one hyper specific CBR to take advantage of. It's typically much more of a broad approach where you're looking to um take advantage of a thousand different exploits. You want to see of those thousand different exploits which ones are going to work on this particular environment. Particularly if you're trying to do privilege escalation which is is the typical entry point so that way you can then, you know, exfil some data or install um some type of script that you can then take full control of a system. Cortez: None of that um is valuable um or can really be perceived from a software bill of materials in and of itself. And so, per usual in security, I don't want to say that there's zero risk um because that would probably be unwise, but I do think that the risk is extremely small. I would say less than 10% and by no means outweigh the benefit of having that transparency um transparency um for the rest of the industry. So that's kind of my take on it. I would love to hear more about yours. Christian: Yeah, I want to just say one thing I let Trevor take this to take take take it. But we've we've had a client basically in the past go as far as telling us that if they publish the S bomb, it's a playbook for the attackers. So you can take you can you can address that questions that that topic, Trevor. Trevor: You know, I think if the S bomb is in fact the playbook for attackers, you have bigger problems. If your security posture is so bad that your S bomb is giving away that information, you're going to get hacked either way. Trevor: Um, I used to do a lot of bug bounty hunting and I would do a similar approach to what Cortez was saying. I'd do massive widespread attacks. I'd pick like three common CVs that are turning up everyone. And then I would hit it against any company with a bug bounty program and 99.9% of them wouldn't hit and then that 1% would hit. If they had that S bomb open, it doesn't matter. I'm not going to look at that S bomb to try to do a targeted attack. It's indiscriminate. It's widespread. It's grab anything you can grab on to and see what happens. Trevor: And so that's going to be the approach that threat actors take. If you have a vulnerability in your S bomb, something that lets you get from the outside in to a device, to a system, to a car, to whatever it is, it's not going to take that S bomb to let a threat actor know, they're going to find out either way. And so, now, even if that S-bomb is the deciding factor, that leads the attacker down the path to get into the system. Your S-bomb shouldn't have these vulnerabilities. Part of that transparency is to, so that if you can look at it and go, hey, wait a minute guys, your S bomb has 80 CVDs and you have no rationale for why they're there. What's going on? That's the purpose of having an S bomb out there is to have that transportation, make sure that buyers are making an informed decision. Trevor: So your S bomb shouldn't be a problem to begin with. If you're taking care of proper cyber hygiene, you're keeping your packages up to date, you have a secure policy in place for vetting third-party components and packages, this should never come up as a problem. Christian: Yeah, so something, uh, I I know that in the medical device space, there's a big push towards transparency. And Trevor and I've had this discussion many times, and we've had it with manufacturers like, you know, if I if I go buy a car, I think I have a right to know like the bill materials, like we're talking about, like who makes the brakes, who makes the carburetor, who makes the spark plug? Then I can make an informed decision about the car, and I know where things are coming from. And it's the same thing with if I buy a medical device, I should have, know where all the components of the software come from. A lot of our manufacturers or clients and a lot of manufacturers we deal with have like this resistance about providing a bill of materials, the S bomb to one of their clients. And can you maybe touch upon like, why they, why is there that resistance? Because I, I, I think it's kind of unfounded. But I just want to hear your, both of your opinions on that. Cortez: Yes, I I will definitely talk to this one because this is obviously where Fossa kind of got our roots and so there's there's really many layers to this that I want to discuss. And the one is actually kind of circling back to a point that you said earlier which is, you know, how ridiculous it is in my opinion to have concerns about IP theft or vulnerability blueprints just off of a list of components because the reality is we've actually been doing this for a long time in the form of license attribution. You've had to publicly post your list of components, the licenses that they're using, um and so a lot of this information has actually already been out there. Cortez: Now, um there are scenarios where you are going to be required to open source your code if you're doing um certain what they call copy-left licenses. And so you have copy-left licenses, you have strong copy-left and weak copy-left. Strong copy-left meaning that you have to open source absolutely everything, weak copy-left meaning there's some um really specific circumstances by which that you'd be required to do so. Then you have permissive licenses. You can think of and and sorry, on the copy-left side, that's often times GPL, GPL, a lot of the GPL variants. Um there's a few other um licenses that you have to be worried about there as well. Cortez: Um and then on the permissive side, you have like MIT and a paty where you can almost, you know, have free rein as long as you're reproducing um that license attribution. We've actually seen a lot of this in the wild. Actually, there was a recent legal case. Um I'll have to um define it for you and we can can include it with some of the assets that we distribute. Um where a um open source developer was using a uh LGPL, I think license package. If you are using a uh LGPL license package and you're using it statically linked, specifically statically linked, um then you're required to open source your um source code. Cortez: Um now you do have options, um which can make things easier. You can rip out that package and stop using it, um which is often times a very expensive um action or you can just um choose to provide the source. Um this particular developer um was brought to court and they had to provide their source code um because of that. And so that was actually a win. Um I think for the open source community to make sure that people are actually providing um, you know, back and giving back to developers. Um but there's a lot of really interesting scenarios that we've seen. And and I would say in the embedded space, medical device manufacturers, automotive manufacturers, all of those kind of things, that is where it's most concerning because a lot of the GPL variants in particular, those obligations kick off whenever you're distributing a product. SAS products um tend to not really have too many license obligations, but if you're distributing like a, you know, a binary or if you're dynamically versus statically linking, if you're modifying a package in any shape or form, these are the type of actions that then start to trigger that kind of copy-left requirement. And I, you know, I will I I will get off my high horse here in a second, but 100% view this as a security problem. Often times this is like put down to the license compliance team. Cortez: Um but if you are, you know, a medical device manufacturer, you've already shipped, you know, a thousand devices to hospitals, and it's later determined that you have, you know, some type of LGPL variant and you're using it in a statically linked way, um you have no ability to rip out that package. You will be required to um to open source um your code at that point. And now, you know, to bring the topic full circle, now you have a blueprint um in order to have, you know, an attack. The spam you're not worried about, having to open source your source code, that's a completely different animal there and and attackers will take advantage. Um so yes, the the license obligations piece is an incredible risk and one that I think most people don't fully underestimate if you're not delivering products to customers. Yeah. Christian: I think we're coming up on time here. So, uh I'll I'll throw it over to you too for any uh parting words of wisdom about S bombs, which is the, it seems like we've been talking about S bombs quite a bit. Yeah. So I'll start with you uh Cortez, any parting words of wisdom for people out there? Cortez: Yeah, I I do have some parting um words of wisdom, which is one, I I like Trevor's point, which is it's a check box today, but I think we as an industry have a real opportunity to improve everyone's security posture by moving it beyond a check box. And I I would really encourage everyone to start thinking about how you can generate S-bombs as kind of your first step, but even beyond that, how can you start importing those S-bombs so you can even look across your supply chain and just make high-quality decisions. Even beyond vulnerability management, we see a lot of end of life, end of support, end of maintenance, um um status recommendations which will give you signals into when that next celebrity vulnerability really kicks off. Are you are you prepared to actually triage that? Are you prepared to actually remediate that? And the last kind of word of wisdom I will leave is I don't see it today, but I highly suspect that even hospitals themselves and purchasers of medical device manufacturers are going to start requiring S-bombs as they, you know, get burned in of themselves. And so the FDA is kind of driving it today, um but I think that the more that medical device manufacturers put themselves in a position to be prepared for when their customers start requesting, which all other aspects of the industry is doing. Um then um put yourself in a position where you don't have to do a scramble activity. Um I'd be, you know, remiss not to mention that there is a tool named Fossa that would be happy um to help you um with all of those things if I give an opportunity. But even beyond that, I literally just love, I live breathe, um, you know, not just S-bombs but the SCA space in general. I'm happy to have any more conversations about it. Trevor: Yeah, I think we covered a lot of really good points today. I think if anyone has a takeaway from this is that an S bomb is not going to compromise your IP, it's not going to compromise your infrastructure. It's not going to compromise your network. I know we talked a lot about S-bombs being a path for attackers and we've also heard in the past clients complaining about well isn't this essentially giving away the secret sauce of how we make our product? Trevor: No, if you're, if you're gluing together a whole bunch of components and that's all you have, sure, it might be a little bit of an indication. But usually the secrets of what you're doing and what makes you have such a great product is what you're doing yourself. These components are supplementary. So, I think that just making sure that manufacturers, customers, everyone really in the health care space and in all industries and the security space are becoming aware of all the good sides of S bombs and trying to push out these misconceptions about what they can do wrong since for the most part, it's just not true. S bombs are a helpful tool. It's great to, you know, let everyone know what they're buying, know what go what goes into a different device or a component network, whatever it is. And uh yeah, just making sure that everyone, everyone isn't getting too scared of putting their ass bomb out there. Christian: Awesome. Well, thanks so much Cortez for being a guest on our podcast. And thanks everyone for tuning in.