 So good morning, good afternoon, or good evening depending upon where you are. I'm Steve Hendrick and I'll be moderating today's discussion about understanding the role of software bill of materials in cybersecurity readiness. Now today we've gathered together as bomb experts from the federal government and the Linux Foundation to provide insight into the growing momentum behind s bombs. And what needs to happen to ensure that this momentum persists. So I'd also like to respond remind everybody listening that the Linux Foundation has today released a survey based on based survey based report about s bombs and cybersecurity readiness and you can find the link that's released on the LF homepage, and it contains a link to the report. And I think we'll also provide a link link today, so that to make it a little easier for you. So now I'd like to start by having each of the panelists introduce themselves and their orientation to s bombs, starting with Kate, then Jessica, and finally Alan. Sure. Thanks Steven. So my name is Kate Stewart. I'm a VP of dependable embedded systems here at the Linux Foundation. And my perspective coming in on the s bomb side had started about 10 years ago when I was in the embedded space, trying to figure out how we can summarize the information that was available in packages so that we all weren't looking at the same package. So this was the sort of the starting point of the spdx project and have continued working on that. And in the last three years have been involved working closely with Alan on the anti efforts from there. So trying to co being a co lead on the formats and tooling working group to understand what the live the land looked like and how we can start to get this operationalized. Jessica. Sure. So I am just books and I'm a senior cyber policy advisor with the student drug administration and for those of you who've been following along. The FCA has been a huge proponent of a bomb for several years. I believe it was 2017 that FCA first announced its, its interest in pursuing software build materials, particularly for medical device cybersecurity. So I am thinking of coming on the heels of some cybersecurity incidents in the healthcare space, where it became very clear. We're not knowing what software packages and other software components may exist within a device or a healthcare environment creates huge security risk. So specifically thinking of a want to cry for those of you who remember way back when so FCA has been working on software build materials referred to in some cases of cyber security bill of materials in some of the FCA resources. So it's a time and we continue to do so we you know we contributed to Alan's process over at the NCIA and continue to work in our forums, including with international partners on software build materials and getting it adapted and integrated into the medical device ecosystem and the healthcare ecosystem. Thank you. Okay, Alan. And thanks everyone for joining us. Alan Friedman currently be cyber security infrastructure security agency in the US government, but was previously at NTI is part of US Department of Commerce and want to sort of clarify also this is very much an international effort that happens to be sort of the US government. And indeed, that's a big part of why the US government got involved is because we wanted a solution to exist in the marketplace that didn't. And he said the best way to do that is to bring together experts from across the different parts of the software world across different sectors across different interests across different parts of the marketplace and around the world to say, How do we make this a reality. So first at NTI a defining the basics and now it's this a focusing on scaling and operationalization. The vision is this. What is an S bomb. How do we move it forward. And also make sure that we understand it as a complex system right it's not just a technical aspect, it's not just an operational aspect it's not just a business aspect. We need to find a way to combine those and have a shared vision that pulls together all approaches. Okay, awesome. Thanks. All right, so let's start with questions. And I'm going to begin by saying that when we're going to talk going to talk about S bombs obviously and why S bombs are being called a cornerstone of software supply chain security. And this over and over again print and, and also and why it's time to require S bombs. So I'm going to start with a simple S bomb definition, which is that an S bomb is a nested inventory of ingredients that makes up a software component, and provides vital information about the component itself. So I mean, there's a lot that's packed into that but let's, let's look into the whole issue of what an S bomb is by talking about why S bombs are a cornerstone of software supply chain security. And of course, part of, part of this is what it is that S bombs are doing that's so important. So, why is it time to require at the production and consumption of S bombs and I'm just going to let panelists to respond as they may. Because some, some may have more to say about this than others. So, so again, why is it time to require the production and consumption of S bombs. Alan, go for it. You've got the most first version of this. Right, so first the cornerstone model like why is this foundation. And it's joking. I keep a pack of Twinkies behind me. Because you go to the store and you buy a nice non biodegradable treat comes with a list of ingredients. Why don't we expect that level of transparency in the software that's running our businesses or organizations are critical infrastructure right that's the bare minimum. And really, you know as a foundational cornerstone it is just that it is a foundation upon which we're going to build more things. So our list of ingredients analogy. It won't magically save you from allergies it won't magically if you have a plant based diet. Keep you from accidentally eating something like that. So for example, Twinkies have tallow in them. Now, you have to know that tallow is in fact be fat, if you're going to take advantages. So it's the starting point upon which we're going to build a lot of great other products, great other services and great other tools. Should we go back to that or should we just say that you know tell us point completely it's it's the transparency and it's the summarizing in an effective fashion. What is there. Okay, a lot of open source, all the sources available. Okay, great. Yeah, fine, or it may not be available in some cases but you know you're using it. The challenge though is how can we get this to work at scale. And so how do we have a common language for expressing this information so the automation really come to play. So one thing that I'd like to probe a little further on, and we'll probably get to this later as well, but so we're talking about informationally what an S bomb is. And so there's obviously information and they're about the license there's information about dependencies. But it seems like in the last three or four years and there's been a pivot with the addition of trying to understand vulnerabilities when it comes to when it comes to S bombs. So, and then it doesn't feel as if anybody has has identified that yet as being, you know, one of the cornerstone reasons for why S bombs are important so should we chat a little bit about this now or you want to wait until later. I think this is where Jessica has really had a good role here so Yes, well so so there's a couple of interesting parts of this right so on the one part and I think it's very critical and I think Alan and Kate can even talk about this a little bit more cogently than I can. But it is incredibly important in mine and FDA point of view that the S bomb doesn't actually contain vulnerability information I think that that needs to be said that you know the S bomb is a thing and it's a document and exist and it can be cross reference with vulnerability information but the vulnerability information should not be in the S bomb. I think the reason that that Kate sort of tagged me in this one is the primary use case for for FDA that we've identified is vulnerability response you know we we have in the medical device sector and in the healthcare sector generally all the time people will approach manufacturers or the FDA and essentially say, hey, we found you know a vulnerability in an X product or sometimes it's you know a vulnerability has been discovered in in why component and we're sitting there a lot of times we're like, hmm, does anybody know what medical devices contain why component because we don't. And then if we don't know, we don't know how to analyze what the patient safety risks are we don't know what manufacturers we need to be contacting to ensure that they're actually responding to the vulnerability. We can do the things that we need to do in order to fulfill FDA statutory mission. And so, for us. You know, as long as critically important just from the transparency measure and, you know, we can talk about some of the other things because one of the big use cases for me is actually a sponsor procurement. But that vulnerability management is huge just it's been the main driver of S bomb at FDA for a really long time. To add on to Jessica's point that vulnerability management role really is something that follows the entire software lifecycle. So, your writing software was part of an open source project. And you're sort of saying all right let's let's let's, you know, commit to this or commercially. Why would you not want to know what on your dependency graph and of course there are some tools today. You know, flags this sort of thing for you, but having that in a machine readable format that scales that everyone is using across the board is going to be very, very helpful. When you're buying something, are you about to buy something that has known bad at it right this is the right would you buy something. So once you want the freshest, healthiest ingredients or do you are you comfortable with something out of it, you may say uncomfortable with that, but that should be an affirmative risk based decision. This is the best this is the thing that's going to save patient lives. So it's okay that there's not dated software in there, because I can secure that on my network. That's a that needs to be conscious decision. And then lastly, and perhaps when we saw this in December. So the world of vulnerabilities is a very dynamic world and I think that's one of the reasons why we want to make sure that we're not sort of locking. We're mapping between SPOM and vulnerabilities, rather than binding them. Because it used to be secure. And then one day we wake up and there's a front page headline, and now we have to scramble and find out if we're effective. And this is really hard if you don't have data that you could search through at scale, ideally with tools and automation. And so that is really one of those long term things. To pick an open source project at random, right, knowing where long for Jay is could be very helpful. And, and that's one of the powers of this and I think this is why we've seen a lot of excitement around SPOM in the highest levels of software and in the highest levels of government around the world. So long term excitement. I'll also add in that safety and critical infrastructure is on a lot of people's minds because vulnerabilities are being attacked in there. So anything that potentially has to do with safety certification you need to know what's there. And quite frankly, the safety standards have been calling for it for a long time for the risk analysis. So in the energy sector in the automotive sector, any place where there's potentially safety, you need to be secure in order to be safe. And so the transparency is going to be very much useful in that space. And so we have these things also rising to the forefront is more and more stark was it open source and automation that we need to be looking at. You know, is when it comes to asking the question, you know, why is it time now to require SPOMs both on production and consumption side. I mean, obviously it feels like it's important from just the standpoint of the bill of materials, you know, the the analogy, but also it feels to me like this idea of safety and the vulnerabilities is really a more pressing concern as we look at what's going on itself today. So, so is, is that what's driving the federal requirement from an acquisition standpoint to require SPOMs. So Alan, I can take a stab at that first if you want. Here is a way we've started to look at this we FDA have started to look at this. I think everybody in security eventually wants to move from reactive risk management to proactive risk management. And the journey of SPOM for FDA has been very similar to that we sort of started out reactively we're following want to cry and other incidents were like we have to know where this stuff is, because we have to be able to respond to it in an efficient and timely manner. I think as we've matured and we've watched the sector mature both specifically related to SPOM and just in general. We actually want to move to a point where you were using SPOM proactively, because one of the biggest things that we face in healthcare is the legacy problem where we just have old stuff we have old stuff everywhere and it's unprotectable because it can't be updated it was never designed to be updated it's 30 years old but it still functions just fine. And a hospital is not going to replace a $500 million MRI, like you replaced your iPhone, right? That's not how that works. So, you know, there's a lot of challenges with legacy and what we are starting to see and this is becoming more and more of a thing in healthcare is putting SPOMs as procurement tools. And to the point that Alan was was raising earlier about, don't you want to know if you're acquiring something that's known bad and, you know, give people the ability to have affirmative risk decisions. We're seeing a value of keeping that stuff out of healthcare environments and unsafe stuff out of healthcare environments by essentially using the SPOM as a procurement tool so we're, we're, you know, looking at having manufacturers, medical device manufacturers produce when a hospital or healthcare delivery organization is, you know, comparing drug pumps, you know, they can sit down with the SPOMs of the various drug pump manufacturers and say, okay, pump A is better because it has, you know, less vulnerable components according to its SPOM, then pump B, so we're buying pump A. And so we think there's huge value in that and that actually starts to move us from a reactive risk management standpoint for using SPOMs, which is important, but to, you know, proactive is better and proactive risk management using SPOM gives us that leg up and that ability to keep stuff out that we might not want in in the first place. The, in terms of why we want to compel, right, so Steven, very interested in some saying, hey, why is the government getting involved beyond just, you know, helping coordinate. So, take a step back, you know, he's a, the fact that we don't have it today is because this is a complex system. Right, it's a, there's, it was very much a chicken and egg approach where no one was asking for the status and no one was supplying it, no one was supplying it, so no one was asking for it. And so that means has been harder to create sort of the, the market demand for open source tools and commercial tools to sort of help create SPOMs and help consume. And so one of the reasons the US government I think is getting involved is to say it's not just enough to sort of help shape this idea and help the community come together and define it. But we're also going to start driving the market. And so it's much easier, and we want everyone to start asking for SPOMs. When I talk to large organizations that produce software. They are a little reluctant to sort of share their SPOMs until you sort of frame it this way is like, wouldn't you like the SPOM for your software that that you're using and was oh yeah definitely that'd be really helpful we could do ABC. And so the vision here is to sort of prime the pump to start saying hey, let's get everyone in the habit of asking for this, that will further create SPOMs, which in turn will drive an ecosystem for saying if we have this data. We do with it. There are so many amazing people in the open space that are creating new things. And candidly, there's an awful lot of VC money out there for security, especially for supply chain. And so we're pretty confident that as there is as this data becomes more common, and our assumptions about interoperability and scale are validated. We're going to see a lot more tools and a lot more innovation to build on this. And the last analogy I'll share is for CVE right common vulnerability enumeration. Nothing magical about giving a vulnerability a number doesn't fix anything at all. I'm still there. Still going to fix it, but by creating the common data plane. Now we're all have a similar point of reference and we can start to have common tools, common processes, common services that can help us. So one and one thing that I don't disagree with anything that Alan just said but I do need to clarify one thing. So FDA, I don't know how familiar people are with FDA guidance, but FDA guidance is exactly that it's guidance about how industry can meet FDA regulations, it's not required. There's a little bit of a nuance saying if you spend any time in medical devices, I can almost see your face as I'm saying all this, but while FDA, we're not requiring as bombs, but we are recommending and guidance that you put them in there, and we are recommending extremely strongly. So just need to clarify that one bit. And again, to be slightly more precise thank you Jessica. So what is the US government currently proposing under may executive order number 14028 that came to the White House, they are going to ultimately require for things that the US government buys have an S bomb. Now, couple of points on that, from a policy perspective, the US government buys a lot. And so we think that will have an approach, but it is not. It is sort of going to affect to actors in the private sector in the open source world, other than just saying hey, we know that they're going to be more interested in having this data around and it's going to have a much more broader effect of having people say oh, that seems interesting maybe I want one of those two. Okay, awesome. Listen, I want to shift gears a little bit. You know I just came off doing some S bomb quantitative research worldwide research. And prior to landing at next foundation I was an industry analyst for 30 years and I will tell you and I was driving a lot of research and application development and deployment. And I never once heard the S bomb term come up in conversation with vendors. And this was it was an eye opener to me when I landed at the Linux foundation. A focus of the research that I did in the S bombs race to us to understand what the penetration rates were what adoption was and what projected adoption was going to be going forward. So let me just give you a couple numbers that I'm going to ask the panelists to kind of comment on whether this surprises them or not. We have 47% of the sample is using S bombs today in some capacity. Now some capacity means they're using it in a few lines of business or some or many, or they have adopted it as as a standard across their company. It varies depending upon how much they're actually using S bombs but they are using them in some capacity both on the production and on the consumption side. We have 40% of the sample is not using S bombs today but are planning to use S bomb sometime in the next two years meaning 2022 and 2023. When we look at the timeline based on when they said they were going to be adopting S bombs. We end up with 66% growth in 2022 that basically increases penetration from the 47% all the way up to what was it 7078% I think it was in 2022. Growth is going to taper off in 2023 to be a 13% percent because we're already at a pretty high level of adoption. And but yet 13% growth across 2023 ends up I think at 88% penetration overall which is quite high. I think a lot of the reasons it's high because of the executive order and similar kinds of activities around the globe. So, given all of this, does this come as a surprise to you as a panelist, or is this expected based on the work that you've been doing behind the scenes here. So, what do you guys think I'm watching Alan and Kate not come off mute, so I will, I will take a shot. This is entirely expected. I, you know, I can keep the same for short because at least in the medical device manufacturer realm, FDA has been saying for five years now that, you know, better get ready to be able to produce and consume S bomb so you know maybe, maybe I'm, you know, a little too rosy of a perspective but I think the medical device manufacturers are like yeah, we got to do this. I think the recent focus has really crystallized and got the bus over that hump of adoption because there's been people who've been wanting to do in the embedded space and have been doing it quite frankly for, you know, eight, nine years. The challenge is it hasn't hit the mainstream mind share. And so the fact that it is now starting to hit the mainstream mind share is tremendously exciting. And it also means that people have done the works and a lot of work beforehand. So it's there to be taken advantage of too. So it's nothing, you know, it's building up on things. Yeah. Great. Ellen, do you want to comment or do you want me to move on here. The last thing I'll say, just sort of highlighting on the sort of the, you know, what, what's under the water is. It's a model that only works if we have a pretty common global understanding of what an SPOM is what an SPOM isn't what, you know, sort of following a certain model of crawl then walk then run and building a modular architecture, making sure that, hey, there's a lot of stuff that's relevant to the SPOM and we want to tie it to it but maybe we shouldn't build it straight into this approach. There's a lot of different moving pieces and I think the value is making sure that we're all on the similar page we're all using very similar software, if not the same software, further up our supply chain. And so, even though our sectors are different, our technologies are different. The momentum has come from having a very common shared understanding. So, okay, well given, given this really strong interest in adopting as bombs. Maybe we should try to talk a little bit more about what each of the following groups are going to be doing, or will be doing what's on their roadmap to help ensure SPOM adoption, you know, in this year and next year. And I think we should look at this from the standpoint of the role of the government, the role of the vendor community. What should end users be doing, and also potentially what should it, you know, industry organizations like Linux Foundation be doing. So, to somebody want to start I mean I think, Jessica you've already sort of mentioned, you know, what, what's going on at FDA, but from an overall government perspective, you know, what should the government's role be now that we've got some momentum behind this, what should the government do to help perpetuate all of this momentum. So I might just heard the, what can what should the government be doing question to Alan, who sits at a little of an organization that has a little bit of that broader view, but for FDA, you know, we we're already doing it. Again, for those involved in the medical device ecosystem, I know everyone is waiting with bated breath for the updated draft of the pre market cyber security guidance. And that's going to be a secret as long as going to be in there right like it is a recommendation extremely strong recommendation has been for half a decade for FDA that you produce and consume as bombs to to have better cybersecurity risk management. And we're going to continue pushing that you know and FDA is going to continue in the forums that we're involved in and in the conversations that we have. I'm actually saying that, you know, bottom line, we understand it's hard. We understand the tooling is still being developed, we understand the best practices are still being developed. You need a phone, and that's that's pretty much the approach that we're taking. So, I see a couple of different roles for federal government, or the US federal government. The key is to help catalyze the community effort. This isn't something any one party should be driving because there are different equities right we need to sort of understand what's important for the open source world for the commercial world but proprietary world. What's important for the tool vendors is going to be different than what's important in the, you know, the users of the tools. And so trying to sort of build this model is going to be important. So moving forward, we've identified a number of areas that we want to advance collectively including how do we think about us on for cloud and sass it's a little different than on-prem or embedded. And also how we're going to move this data around. What's the transport model look like, because we don't really have some global ways of thinking about that, especially if we don't if we want access controls on layer so there's an example that. Is just catalyzing that to is coordinating this effort. As I mentioned, this is something that really is a global effort we've partnered with our friends in the German government and the Japanese government as well as companies around the world organizations around the world. So we want to make sure that this stays something that that we're is really built on collective effort. And the last thing I sort of want to emphasize is, if we're still talking about as bomb as a unique novel thing in a few years. I will have considered that a failure on on my part, because the goal is to sort of make this just part of the vulnerability ecosystem right this shouldn't be seen as a unique idea. This should just be seen as how we make software, how we talk about software, how we handle software how we evaluate software. And so the longer term, you know what roles of government is to make sure that this is integrated into all those other parts of the vulnerability ecosystem that are happening around the world. So this stands beyond the vulnerability ecosystem to it should just be how we make software period. From the standpoint of the vendor community and service providers is there's something, there's something that needs to go on there to help be able to satisfy all of the growth that that's going to that is projected to to happen this year. Does anybody want to take a swing at you know what the vendor and service provider community should be should be thinking about. The vendor and you know, having commercial offerings out there and having consultants out there that people can work with, or doing the analysis is going to be key for adoption. Some people will want to do things and roll their own and work with open source tools and everything else. There's a lot of other people to just say, Okay, I just want to hit the button. I really don't want to have to think about this hard. I'm willing to pay you some money to help me. And that makes a market opportunity for people to basically create new innovative business models as well as helping advance the transparency. So having the capabilities there and being able to work with the open source communities who are trying to do this as well as help reinforce common understanding of what the semantics of the fields mean. These are things that I think we all can be working on with vendors as well as open source to really make it move forward. There's lots of different systems out there. There's like, you know, there's lots of different vulnerability systems out there right and being able to link into all these different vulnerability systems is kind of key as well. Yeah, and I'll say for what one thing that we've been very cognizant of is for smaller manufacturers and for FDA doesn't regulate hospitals but for the hospitals who we expect to be receiving this information. We have heard concerns that they're like, Look, we're already flooded with vulnerability data we're already flooded with all kinds of information that we have no idea what to do with and now you want to dump. All of this additional information on it like we don't we have no idea what we're supposed to do with this. And so I will, I would say that the vendor tool community is actually going to be critical in actually operationalizing a lot of these things because you have organizations who are just like unless to cave point they get the like press the button service, then handing them a bunch of phones doesn't do too many good, and we don't go anywhere. So I expected the tool community to be a very critical part of this. So, sort of building on that point there's two things to flag one just on the downstream users offer completely there there's always going to be a maturity model and all of security. That doesn't mean that we shouldn't work on advancing it we know that most things in security sort of follow a trickle down path of starts off with very elite organizations, hiring world class experts, rolling their own tools and solutions and then we sort of fit into turnkey. The example here is threat intelligence. No one says hey because your small organization can't handle threat intelligence they're still doing you know the basics doesn't mean that we shouldn't build out new threat and tell tools, or sec ops tools for development. So going to flag and something that's really a concern for a lot of us inside us government is we're always worried about things that put small businesses at a disadvantage right we know that a lot of innovation comes from smaller organizations we don't want to give them these large heavy regulations that were sort of really motivated and had input from giant tech companies or giant contractors, but didn't really have small business in mind. The great thing about SPOM I think is for especially people are developing software. This is often if not usually much easier and cheaper for smaller organizations. I'm right if you have a modern development tool and a modern development pipeline. There are tools out there that can spit out as bombs in whichever data format you want. You can write can be integrated into this this is something that is is beneficial if you have a modern thing. It actually is harder if you're a legacy with legacy stove pipe pipe. Okay. One thing I'll just add about the vendor community. The research that I just, I just did on on S bombs shows that from a kind of best practices standpoint, and user organizations are really trying to understand which vendors are going to be providing S bomb tools out there and one of these tools going to be available. So I think one of the things that communicates is that the vendor community needs to take a more proactive and visible stance in terms of driving up the visibility around what they're doing with S bombs, and also putting putting more into messaging standpoint of communicating to end users what their capabilities really are here. So let's, let's talk briefly about S bombs and this, this whole issue of existing and emergent component vulnerabilities. I mean the first question is I mean I know that S bombs don't contain information about vulnerabilities but they do attempt potentially link to known existing and emerging vulnerabilities. One of the things I, I guess let's just clarify, you know, what is the stance what do S bombs do today, and potentially tomorrow if they don't do it today. What's the relationship between S bombs and known probabilities where are we with that. At this point in time. So, I'll kick us off and then I think Alan's probably going to end up talking about VEX and I will try to make as few faces as possible. Well that conversation is ongoing. So, you know, as bombs and vulnerability management is a is a complicated marriage because right we've been saying along. One of the major use cases for us on as vulnerability management. I mean, we have heard the concern raised in the past and still now that look if we give people in S bomb, they're going to go to the CDE database or they're going to go to another vulnerability database and they're going to look up. Well here's all these components and here's all these vulnerabilities and now I'm going to go back to the vendor and the vendor must fix all these vulnerabilities and I, the vendor might be like well yeah the vulnerabilities are there and the components vulnerable like you don't need to worry about it because compensating controls or you know whatever else it is that they're going to. Whatever else it is that they're going to argue and look I'm being extremely dismissive of it, and I'll admit that because this is, this is something that I find extremely personally frustrating. For Jay, not vulnerable until it was right and we've seen that all the time where there's you have a vulnerability. So it's vulnerable but it's really complicated to exploit, except until somebody puts up the new POC that makes it really easy, or until you start changing them together with a bunch of other vulnerabilities that means but suddenly that's extremely exploitable and a huge problem. So, I will say from the FDA perspective we have not necessarily been that receptive and in fact have pushed back very strongly on this idea of it's okay to have vulnerable components. And, you know, we'll just wrap compensating controls and other things around them and somehow that completely mitigates the rest. You know, it's, we, it's going to take time and it over time will get better at this, but having vulnerable components within a device is just asking for trouble. There's just more that we keep integrating software into everything that we do and into critical infrastructure that just becomes less and less and less acceptable and I don't know why we would voluntarily do that. If we have the information and we have the ability to not do it. So that, you know that's certainly where I think I'm coming from and where FDA is coming from on sort of this, this, you know, challenge between vulnerabilities and and go ahead. Go ahead. So, to coin a completely original phrase, all good software is the same, all bad software is bad and uniquely different ways. And I totally understand Jessica's perspective, especially because as a government regulator she's been lying to in the past people have said you know hey, there's some great stories where people said oh this doesn't affect us. And that's what they said it too soon and and and we've talked to lots of downstream softwares and say, I will never trust either this specific factor or need any vendor if they say. However, I think there still is a large class of ways where someone may say. This is not as bad as it may appear just by looking at ability and mapping of vulnerability to an S. Now that's true for coverage is one we sort of have to acknowledge that resources are finite everywhere. And right having someone implement a major fix or indeed a major feature might be more important than taking care of a low probability of vulnerability. Yes, who's the best position to make that risk decision is a tension between the supplier of the software open source of commercial open source proprietary and the user and there's going to be different models, obviously if you're in a very high assurance domain, where you know you're regularly under active threat by adversaries, you're going to have a different perspective than if you just want your stuff to work and you want it to be cheap. One of the things that we're working to develop in parallel to us. Is this, forgive me, this is probably the worst named project in all software, and it's all my fault vulnerability exploitability exchange or vex, and I'll post a link in the chat for one page summary of it. The vision here is it allows a software supplier, again, could be the open source project could be a proprietary supplier to say this product, and this vulnerability, it is not affected by this vulnerability, even if it contains it now. There are many reasons it could be and we're working on sort of building out machine in the goals to make it machine read. And so the vision here is to allow someone to say yes, I'm using heart bleed one dot oh dot one, because I haven't had time to refactor my code, but I'm only using the pseudo random number generator, and the heartbeat function isn't even in the stock right the compiler did not include the software that puts that puts you at risk of random memory leaks from the heart bleed vulnerability. Here is how do we enable that to happen automated. And of course, no one has to trust this is a set of assertions. And you can say you know what these vendors these suppliers totally trust they've got great product security teams. Not a chance we're still going to either you know we're still going to treat it as it's vulnerable. And the last thing I'll say is we can also there are things that we can do to supplement this with trust so this for me is a great example. I'm not always the world's biggest fan of bug bounties but this is a great example where bug bounty can be very useful where someone can assert this product this vulnerability does not affect my product and to support that. It's a $100,000 bounty, if anyone can sort of figure out how to chain it, or if anyone can figure out how to explore. So that allows us to sort of build out further infrastructure again. Shouldn't these things these things as unique want to talk about how they all fit together. I'll build on that then because that takes me into the embedded space. So actually, one of the problems we had with the Zephyr project is when Fnet my Amnesia 33 came back out and Fnet was there. Our LTS had Fnet in there, however, actually the version of Zephyr never had the piles that were affected at the source file level. So we had no way of signaling to people that that version of Zephyr was not affected. So having Vex and having a way of summarizing this in an automated fashion is going to be very powerful for open source projects as well as vendors. And in fact, you know, some of the comments, one of the questions that sort of came in from the audience here was, you know, well this can't apply into embedded. Well, actually, yes it can. And that is leading away in certain areas right now. So in particular, I'll call out like the Octo project. Right now when you're doing builds in the Octo project which is embedded all the way. You have the access to full reproducibility of your packages, which is one thing that helps with that long term maintainability, and you have the ability to generate off a software bill of materials automatically and getting this automatic building materials in the embedded space is going to be pretty much key to having these devices that are showing up in critical infrastructure like medical and so forth being able to know that we've got a clear understanding of exactly what's in there because it's been less business. So in fact, you have the summary coming out. The Zephyr project has also added this capability in so that anytime you're doing a device it's really memory constrained you have that ability to come out with a file that summarizes all of this information. And there's no reason this can't be skilled to everywhere else in the industry. Like I said we've got some proof points out there now open source projects doing the right thing automatically and make it easy for people. I think that's where we need to go for everyone. Awesome. Listen, before we shift over to question answer let me ask one more question here which and this comes this is based on best practices that end user organizations want to see in the S bomb space. The survey data that I collected shows that 62% of organizations are looking for best DevOps practices for both producing and consuming S bombs. And number two at 58% was best Ospo open source program office practices for integrating S bombs into governance risk and compliance. And then you know understanding how S bombs are going to evolve over time came in at 53% and then finally, knowing which vendors are going to provide S bomb tools was at 46%. Now, given those sort of requests for what we should be doing to support the user community around S bombs. Is there anything else that sort of jumps to mind that you think is important that will help the end user community be more successful with the S with S bombs. So I think we should be aware of watching all the tools that are coming out right that is sort of, this has been S bomb coordination and promotion within my full time job now for four years. It's been fantastic to see every six months, another wave of projects and of companies that have started on this so I think the short answer is I'm going to call back something Kate said which is we're working is sort of building out this sort of tool model. The S PDX community and the Cyclone DX community have done a good job sort of helping shepherd the tooling and their ecosystem. And one of the things that we want to do down the road at CISA is sort of have more transparency to that marketplace, so that folks can sort of understand how to compare tools and make sure that they are functionally equivalent. And so that's one of our goals. Okay. So I think we should probably switch over to question and answer from the audience at this point. So, let me, what I'll do is I'll be I'll identify the questions been asked by the audience and then we'll see who wants to or who wants to answer the question. So the first question here is how should we think about applying S bombs to development and CI CD processes. And I think to that I'd also have maintenance. You know, any, any recommendations on how best to sort of bring us bomb tooling in. And, you know, how to integrate that into so what what's happening inside of DevOps. So I think I'll start then putting plugins into the tooling there's a bunch of plug in options out there that people can integrate. So let me start with that and then see where they're lacking and quite frankly contribute back upstream and help make these things robust and able to scale. So there are, there are starting points out there. The Kubernetes community for instance is already, you know, incorporated some of this. So, you know, looking at that project, you know looking at what they're doing, helping the, you know, as one generation if it's not doing exactly what you want help contribute make suggestions help improve because we need to get the whole community working together to get this to scale. Following on the heels of that we have a question, which is I think related, which is will S bomb formats and content be standardized. So we've, I think done a decent job thus far from saying, what's a baseline model this is something that the community worked on, sort of having a initial vision in 2019, and then in 2021, sort of built out further. Here's all the different pieces that we want. We acknowledge that there are some spaces where we're still, I think there's still some ambiguities. So for example, if we want of a component, pretty common part of software, both the data formats have some advice on how to implement that. I don't think they're sort of global guidance on that. So we're some tweaks around the edges, because I think this is going to be something that is going to evolve. The last thing I'll say on data formats is there are two widely used today. SBDX which is comes out of Linux Foundation, Kate's been a great leader on that front, Cyclone comes out of the OS world. They're both great projects. They're both open. Anyone can get involved I encourage you if you're interested to think about them. My interest is to make sure that they're interoperable, because we don't think that, you know, one is inherently going to win out over the other, and that's okay. We can live in a world that has multiple data formats. And I've been really pleased to see the communities work together to make sure that they're harmonized and so I just want to doff my cap to both the SBDX and Cyclone DX team for making progress on that front. So, the next question here which is a really interesting one, which is how do the panelists feel about the confidentiality of the SBOM. Is this a blueprint for attackers. No, it's a blueprint for the defenders thank you very much. The attackers know this stuff guys. I'm just trying to give tools to the defenders to actually, you know, understand what's there. Yeah, the right. We know that security is a fool's game. So, and we know that Jedra and verse engineering tools are free. Anyone who wants to know what's in a piece of software. And the, the caveat there I will also say is, there's no need for them to necessarily be public and we know that they're going to be different sectors where they're going to say, SBOMs won't be public. One, need to make sure that we have a way of sharing them with downstream users right so customers are going to be asking for them. And ultimately is going to be up to both sectors and specifically to figure out what they're willing to share publicly versus confidentiality. The challenge there is right if you say I have this data and it's confidential. Well now we need some infrastructure to talk about how to share them. So now it's not just about moving data and making sure that's available timely in a timely fashion in access control layer on top of that. So there are companies today that are creating their SBOMs and just sharing them publicly. You know, just a well structured URL organization dot blah blah slash SBOM and making public but they're also going to be folks that are saying hey you got to go through our vendor portal or something like that see it. That's okay to vendor portals just don't scale. The next question is, can we achieve complete automation of security. No, we can do a lot of automation in security but you know there's always going to need to be and this goes to some of the point of, you know, a vulnerability might be different for different people right if it's my environment has different contextual than your environment, then I might make a decision, a different decision about how to respond to it than you. So I think automation can can help and start to help prioritize and contextualize a lot of that information but at the end of the day you have to have people who are sitting there who have the ability to make the, the informed risk decision about how they're going to handle it. Because the other thing that I would add to, you know, and this is critically important for fda and Kate hit on this a little bit security isn't the only consideration, right and I think Alan mentioned this a little bit too right treating patients is why people make medical devices they don't make medical devices so that the medical device can be secure. I mean, you have to make the medical device so the medical device can be secure so that it can be safe, but you're designing it to actually provide a healthcare service, not or treatment or whatever it is not security isn't the end goal. So there are going to be circumstances and we do talk about this in the phone space and then other spaces that sometimes you are going to be weighing the benefits, or the risks of some security and other possibilities against the potential benefits of whether or not that means you continue to use that device to continue to treat patients. So, you know, you have to be able to make those kinds of decisions. And next question here has to do with producing and consuming as bombs and the question is, are there security concerns with producing and consuming as bombs. And I thought about to which is, you know, I know the hash totals are very useful from the standpoint of being able to validate a reproducible bill, but how trustworthy do s bombs, how trustworthy are s bombs in light of the fact that there needs to be security around the creation and consumption of s bombs. Phenomenal question and definitely where we should be thinking about from a security perspective, but it's 2022 so we don't just talk about security we thread model. And there is going they're going to be different folks that are concerned about different things if you're worried about having a just a vulnerability on your network. No vulnerability that someone can exploit without a major tool, then getting the best faith best effort as bomb is going to be, you know, the important thing. If you're worried about someone actively subverting your supply chain, then we need to start layering in trust and integrity checks and the good news is, there are some tools that are moving in that direction. We need to complement, you know, the great folks at sig store, who are sort of working on making sure that we have some trust inside of here, and ultimately saying hey, in addition to my S bomb. I want artifacts about the build process to build an environment that who had access to it. All of these are we want to head to is we're now getting into very domain specific and tools specific approaches that may not acceptable to ask for, you know, an average mid sized company that's software. And so the goal here, long term is to think about how do we integrate all of these layers in so that people who want this information know how to ask for it in a globally understood way. And to sort of make sure that we can sort of follow a maturity approach where we have the basics are on things like integrity and trust and for metadata. I'm going to, I'm going to jump in because I know we're running out of time and there's a number of questions that have come in that I wanted to sort of hit on all at once. So, some of the questions are essentially around, you know, if we if we do as funds in this way and the expectations that all of these vulnerabilities have to be fixed and all these things. Well, the price of software is going to shoot up and you know and or companies may not be willing to disclose vulnerabilities because it could have financial ramifications on them. But you don't want to disclose vulnerabilities, you can roll the device and or you can roll the dice and not disclose vulnerabilities but I can tell you for example in the medical device space. We want there is an expectation or it's a strongly recommended procedure for FDA that vulnerability disclosure and devices takes place. And that's not it though, FDA regulations require that you have a safe device if you have a vulnerable device you might not have a safe device. And if you don't have a safe device because you have a vulnerability device, you might have to recall your device. And so, you know, it's a company decides not to disclose the vulnerability, and it comes out later anyway which let's be honest, it always comes out later. And how much worse are the financial ramifications going to be then how much worse is the reputational damage going to be then if it looks like a company hit a vulnerability from the public. You know that's that's never the right answer. And so, you know I understand the concern from organizations that like look this is going to be extensive. This might impact our reputation because we aren't going to want to essentially disclose the fact that we're using outdated unsupported vulnerable software and our products, and all these other things but like guys it's 2022. We've seen, we've seen cybersecurity incidents take down gas pipelines. We've seen them put patient safety at risk when hospitals are getting hit with ransomware. This is not a sustainable way for us to continue as a nation approaching cyber security when we are relying we are putting people's lives on on the line in the hands of crappy software, and then essentially now trying to turn around and say it's too expensive or it's too hard to not do that and I got to be honest with you from from the FDA perspective. That's not really an acceptable answer to us anymore. So, that's awesome. Ellen you want to add anything to that. Okay. There's a question that's in that. And then I'd like to just quickly touch on, which is, you know, to what detail should the s bombs describe what's in the software package. You know that just at the component level versus the source file level. It's a fidelity question it's how much automation you really want to play. If something has to be high assurance someone's life there, you may want to have that full trace ability down to the source file level and every hash is there and you know all your building information is quite frankly, you need that to do your safety analysis. So, you need to be able to scale from just the component level which is, you know, a low fidelity but the two of these to the live the land to all the way down to those source files. And you know the Amnesia 33 example I just referred to as an example was a, you know, was a way of clarifying that. And if we want to automate we have to be able to do that level of scaling all the way, potentially even down to the snippet level. Great. Hey, here's a good question which is, how do we retroactively generate s bombs for already deployed products. That is a fun question. I haven't thought of that. That's a great question. Well, in the good news is there's actually a thriving marketplace for this. So the answer is we use binary analysis tools and source composition analysis tools. There's some great ones out there today. There's even ones that are focused on particular sectors there are companies that are doing this explicitly for medical devices there are a couple of the energy space and kept health on space. So, one of our challenges is going to be to sort of figure out, how do you reconcile the output of one of those tools with the output of a build tool or source tool, because there are subtle differences. But in the short run, there are things that look an awful lot like s bombs that can come out of these tools. I'm most and more at time here. So, I'd like to thank our panelists, Kate, Jessica and Alan for joining me today I also like to thank the audience for the great questions. And I think more recent now has some final instructions for those of you who are listening in. Thank you so much Steven and thank you Kate Alan and Jessica for your time today it was an incredible webinar. And thank you everyone for joining us just a quick reminder, this recording is going to be posted to the Linux Foundation's YouTube page later today so you can check back there for the recording. Okay thank you everyone again so much have a wonderful day. Thanks everyone. Thank you all.