 And thank you everyone for joining in and being interested in this topic. Certainly as we go through this, I certainly welcome your interactions and your discussions. If something's not clear, please chime in and hopefully we can make it an effective session for everyone. So what we're going to be looking at today is, you know, what is the software build materials. The easiest analogy that seems to work for most people is it's effectively the ingredient list. And when you have things that have ingredient lists like that, you might look at something like a Twinkies and think, oh, that's going to be fine. That's going to be vegetarian. I can use it. Well, there might be beef that in there. And software build materials are sort of doing the same sort of thing for the software that you're running on your systems, as well as what you might be wanting to use and import into systems to make products from. So we've got, you know, different modes of working and looking at how we can actually sort of summarize this information in an effective way so we can automate it is part of the challenge right now. Another way to think about the software build materials is like when you get a kit from IKEA or wherever, there's a view of what's actually in it and how you actually put it all together. And this is another type of build materials, and we're again looking at what a software version is. So we've got three perspectives across the supply chain. We've got the perspective of those who are producing software. This is sometimes referred to as a supplier or the upstream. There's a point of view of the people who are actually choosing which software they want to, you know, incorporate or use. So it's a consumer downstream is the other term that gets used with this. And then there's a perspective of those who just want to use it. You know, it's in an organization. It's in your own laptop, things like that. And so the perspective of those who are operating. And so each of those has a perspective on what an S bomb is. And so I just want to make sure that we're also aware of that right now, because it does play a role. And the challenge right now we have is an open question of, you know, how many organizations can actually answer, you know, are they affected by the vulnerabilities we've been hearing a lot about this on the news. And having an accurate software build materials for the software on your systems. Let's you answer that a lot quicker than a lot of manual digging and, you know, looking looking up and assessing. But the automation generally isn't here. And so you're seeing large costs or immediate and things like that that are happening. So what we're trying to do by getting this automation places make it much easier to actually just detect that you might be affected. And then also some it helps with some of the knowing whether or not you might be vulnerable to certain types of supply chain attacks as well. If you can see that you've got an impacted, you know, affected component and you've got the hashing and so forth. Some of these things help you remediate and fight, you know, detect to remediate more than anything else. So, you know, we've all been hearing a lot about, you know, the SolarWinds one and that numbers amnesia 33 in the last couple months. So what I think is that, you know, a cost to developers to fix an issue is pretty small. However, the cost to users suddenly become very large. So we're seeing a lot more awareness show up, you know, some headlines are starting to show say as much as it's going to cost you 100 billion to deal with all the follow up from the supply chain attack from SolarWinds. And, you know, the amnesia one is like for IoT devices, and you know, it's not always clear, you know, you know, there's, you know, there's millions of them out there that may be impacted. And then how to remediate. So, figuring out how to make things more dependable in future is obviously going to be something we're all going to be caring more about and part of making things the systems be dependable is actually knowing what's in the systems. You think it'd be obvious, but we've evolved so fast in this area that it is a challenge for us all. And the other aspect that's happening here too is, you know, it's not just, you know, time and money. It's actually people's lives in the sense that, you know, when this, some of these software and some of these systems are in hospitals and they're hacked. And, you know, people don't know that they have an impacted component. It could mean a design old service or, you know, you can't use certain devices and that could mean someone's life. So it's starting to get in the safety realm to that we really want to make sure that we have a very accurate picture of what's going on and how we can be effective. The thing is, we have not really been focusing on that we've been mostly focusing on features. And, you know, right now 99% of the co bases were made with open source components. This is from black ducks report last year. And, and they, from their estimates and their scans and everything's 70% to the audited code bases were open source components. So, open source is there and features are there and you know people are wanting to use those features because it provides functionally they want to make you know interesting things happen. But getting it so that we actually have an accurate picture of what's happening. You know, dependencies and what's called what you know how all these pieces hooked together. There's a lot of components out there and those components like to do a lot of really interesting things that the challenge though is knowing what's actually in the container or you know what's in the instance you basically installed to do a function. We don't really have an easy way right now just to serve our systemic way. There's ways to do it but we don't have a systemic way of making it just as easy as transparent of like okay I'm going to load down this you know, software okay what's the software build materials anything that I'm not, you know, check for as concern points before I run it. And it's not just an individual level is at the company levels to the xkcd June that came out at the end of last year was just so perfect. Because we've got a lot of really interesting infrastructure and that's very powerful out there but there are pieces that there's dependencies buried in there that people just don't have the awareness of. And being able to sort of have a way of seeing that that transparently such that when you hear that there's an issue and you know you've got dependency you can actually find out quickly that am I impacted or not. That's what's missing right now. So this is just to give you a bit of a context as to a why we care about software build materials. The other challenge that's out there is that there wasn't really a good definition of software build materials that would serve intuitively knew what they think they wanted it but they're what no one was really codifying it and so a couple years ago the NTA. Took on the challenge to try to get a multi stakeholder group together and figure out okay what is minimum viable was really a software bill of materials and they're coming at this from the securities perspective. Mostly but you know a lot of the issues have been here and there's been software build materials that important from licensing use cases as well. Because you know in order to run open source you need to know what the license is and you need to be able to adhere to the terms of the license. In your usage so. There's a lot of stuff already there in place from licensing and getting that aspect of built integrated and moving it forward has been part of the challenge that we've been working towards. So a software build materials is can be including libraries modules open source proprietary free or paid it's anything you're running on a system we should be able to represent effectively and be able to query it. And so if you're curious about this type of information I encourage you to check out NTA is as bomb site. And there's more links in here too and there's a fact about these types of things as well. But this group basically sat down and after many months of debate worked on coming up with a minimum viable so this is, you know, there was group called the framing group in framing component transparency and so they serve us as a simple reference example. About, you know, okay you've got your application and hey it's including a buffer from bingo and it's including a browser from Bob, and Bob's browser is including a compression engine. And so, you know, do we have, you know, do you know everything that's here do you know the known unknowns. Can you be definitive about you know what's actually there what's not there things like that and those were the aspects that they honed in on as being able to define what a software build materials should contain doesn't say anything about vulnerabilities and say anything about licensing is just components in the relationships. And from there, we can add and layer on additional information to help different use cases and solving these, but at the heart of it it's something very simple like this. Now, there's use cases pretty much in the industry for software build materials to be pretty much used anywhere within a software life cycle. You know, you can, you may want to before you bring in a piece of software understand what it is. And so you want to include some open source components to provide some functionality in the application you're creating. You're going to be able to see what the software build materials is and the dependencies and the licensing and importing it that might be done before you even start developing it. You know, as you build it, you might want to generate it automatically so that you have a definitive source which such that when you go and release it or. Hey, you've got, you've done some testing you may want to, you know, augment it with the results and certifications and so forth. So and then when you're shipping it. We're asking you for the software build materials. So, pretty much anywhere in the life cycle we want to be able to set up the ecosystem so we can generate these things. And that's going to take some tooling. Okay. Yeah, we have a question. Sure. William, would you like to unmute yourself and then ask a question. Just not. Keep going. Um, so, um, you know, why are you hearing about this now, why should you care now. That's all the people want. I think I'm hopefully some of the slides I gave at the start to her gave a bit of a context, basically because our lack of transparency and lack of automation is starting to cost real significant money. The cyber security aspects can potentially now start to impact people's lives. And so we really need to, you know, none of us are working on software that if it gets a bug in it that we want to, you know, think they potentially could, you know, cause someone to lose their life. And at the end of the day, software vulnerabilities are just bugs. So we really do need, you know, bugs happen and we want to fix them as early as possible. So when the component is shipped, and there's a bug that's discovered after the fact, you need to know that this bug is there so you can fix it and then you can deploy fixes in the field. And having that transparency is what's been missing in the industry right now. So, um, you know, these things have moved very fast. The system has evolved tremendously in the last five years. We're seeing more and more reuse happening. It's all time to market from people's perspectives, you know, the startups coming up, but we pull all these pieces together, we can go to mark with our concept. You know, we also seeing people using containers, the whole Kubernetes infrastructure has exploded. And we've got, you know, a lot of functionality that's much more accessible to people than it was before. And it's easy to sort of, you know, set up a container that contains your application and let people just go and work and run it. And that's very powerful. But what's in those containers and, you know, what are those containers loading. And, you know, do we have the transparency to know are we making ourselves vulnerable by using it or not. And some of that's missing right now. So there's people working on that. And we're also seeing some of the regulatory authorities now starting to wake up to the fact that we do need to know what's going aware with the cyber security supply chain threats. So awareness started growing a couple years ago with the FDA, and they're letting the NTA effort for sort of define what the industry wants. They've given some guidance in that, in the sense that, you know, they're expecting in future to be able to know what the software build materials is that's coming in with the devices. They haven't put a date on it or any, you know, specific wording, but they've signaled and joined meetings and indicated that it's important. And the other thing though is like the federal energy regulatory committee has also signaled that we want to kind of what's near the software before we put it on the grids, please. And so, getting these types of things and we're seeing more signals happening in the legislation in Europe as well with the NISA and the IOT cyber security framework, so forth so in that case. Yeah, we actually have a question from Ann Joseph. And if you want to unmute yourself and go ahead and ask the question that'd be great. Good morning. Thank you so much for joining us this morning I really appreciate it. I wish I can actually sit down and have a one on one but my main question for now is since we're talking about fixes we all know in our industry. It's like a major issue. Do you think the P fixes is it's mainly because of software, because I'm finding that because I compare comparing to you I'm a novice. Well actually I'm going to ask you because when you see the term P fixes can you expand the P please for me. When I say P fixes. I will say probably problem fixes it could be like a software or hardware fix. All good. No, that's fine. I just yeah any type of fix that you need to apply to a system. Yeah, and I'm finding that because I'm new. I'm finding that we do a lot of patch fixes when we do our releases and I'm realizing that it's because of the is it's not really the software I think the hardware is not keep keeping up with the software capabilities do you think there's a way that we can leverage it like you know how we have expiration dates for for food. We have like an expiration date for components of a server or mainframe. This is actually a very active area of discussion. In extending the formats that are being used for representing this information in fact there's a group working in Japan that's sort of centered around the automotive industry. And they want to have something like usage. So like what sort of, you know, when can you use this and up till when and what for what purpose and have that information carried with the software as well as just the component in the relationships. There's people that are wanting to sort of get to that stage of carrying that and standardizing on some of that information. The idea being, hey, you're allowed to use this software where you're testing things out but you can't take it to production. Or hey, you know, we're only going to warrant this until the end of the long term support period, which is like two years from now. Right now you have to do manual service scrolling through the check and find some of that information for some of the open source pieces. And, you know, some of it's written in contracts when it's commercial. But I think we're going to go there. I think right now this sort of stuff is we still need to crawl as an industry here and get to the stage where we start having this automation happening automatically, you know, in parts okay. Does that help. Yes, thank you so much. I appreciate it. Hopefully we can talk one on one, because I love your knowledge, and I can learn so much from you. Thank you. Sure, happy to have another question and answer box. What are the differences between the software bomb in the context of security and licensing from Martha. Okay. When we're talking a software build materials. There's sort of two main use cases that seem to be used for it and they have come from the two different spaces for. So when you're looking at source code and you're looking at the software build materials for it. That tends to be a summarization of the licensing that sitting in the source so that you have an accurate picture of what you might be pulling in for obligations if you use it. Once you've compiled that or built that source. Then the some of those files may have fallen away and their licensing may not be significant. So you may have a different image that has only one license then are two licenses from that whole plethora. And you may also quite frankly statically compile in some libraries that have their own licenses. And so the licensing at that point in time. It may change based on, you know, whether you're bringing in something like with a reciprocal license or, you know, something like bringing in the GPL as a statically link would potentially change the overall licensing of your built image. For instance, as a property of the license of that library. And so there's a lot of different scenarios and nuances so there's uses for both of them. Having a very accurate picture of the dependencies and which actual components are being brought in from a built image is key for understanding a lot of the cybersecurity aspects. For the other ones it's sort of like more focusing around the sources and then the linkage to the image and the cybersecurity tends to focus on, you know, the linkage as well all the way down. That's kind of how I keep it in my head at this point. Does that help. Okay, I'll keep going anyhow and move beyond this. Just wanted to sort of catch through that. I think we're seeing the implications of the funding and we're also seeing that, you know, Europe is as well as the US is starting to look at, you know, starting to standardize on the materials. And, you know, we have the, this is the from NERC's SIP document, which is, you know, we need to understand what's in there. And so, pretty much who should be using an SPOM is any organization. That's, you know, wanting to make sure that they're supporting their customers effectively and and quite frankly being efficient themselves. The challenge is, you know, we've got to prime the pump here, and we have to get to the stage where a lot of this is, we have tooling, we have it available. There's a lot of commercial options out there right now, but that doesn't scale to open source and see earlier comments that most of this stuff is coming in from open source. Like, you know, that 70% of the code of products is open source. So that's a gap. So we need to make sure that the tooling is available and open source so that the open source projects have an easier time keeping an eye on their licensing and can summarize when they put releases out pretty easily. And, you know, any product, be it a product or project, I should say, you know, may want to have this available. And, you know, when you're when a project is using a dependency from someone else, you know, you want to know potentially if it's got a vulnerability or if it's outdated or it needs to be updated. So there's a lot of rationale that needs to come in here. And as we're sort of talking from earlier, these are sort of like some of these cases, you know, when you're producing the software, obviously vulnerability monitoring is key for your dependencies and working on your code base and, you know, only including what you really need when you're offering software again, vulnerability management, but, you know, real time data, what's happening. And when you're sort of choosing software and you're bringing things into great into your products, you know, all of these are the cases that we can use having a software build materials accessible to us and, you know, be able to deployable. One of the other things too is, as we start getting this being adopted throughout the industry in a wider fashion. We need to have the processes in place and so the open chain project. Which is now a nice of the standard has been calling for build materials all the way along. And the companies that have self certified should be able to generate them for you for their products. And so that catches a good part supply chain. And once they bring something in if it doesn't have a bill of materials they have to generate the bill of materials for the pieces that they're using to so it's, you know, they're responsible for what we need to be looking at, access it or say what they don't know. It's probably the best way of saying it is like being it being exclusive about what they understand and what they know what they don't know. And having the processes in place to quite frankly, you know, to work with these types of build materials. And, you know, getting that it's been a couple year journey, just getting it so that we have some of these large companies able to work with this. So at the end of the day, having these software build materials in play just sort of makes financial sense. You know, there was a quote that was made last year that never talking about 100,000 man hours would have been saved if they'd had access to this stuff in terms of when dealing with a couple of vulnerabilities. What does software build materials look like today. Well, it can be anything from a spreadsheet to a file in one of the formats to, you know, PDF to text in an email. You know, everyone seems to have their own version of things and this is what we want to try to see if you can standardize on a little bit. So this is an example here and it's got the key elements, but you know, this isn't something we can take an automate. You know, it's got, you know, these are the license, you know, these are what's included under this. Here's what the licensing is. And you know, here's some of the versioning that's in there as well. So there's, you know, there's things in there. The challenge though is everyone doing things in a different form means we don't can't automate and we can't go to scale. From the anti discussions. A minimum viable as bomb. Should contain pretty much supplier name, who's produced it. And then what the component actually is in some sort of name generic name space. There should be some way of uniquely identifying that specific component. Be it a version number. Quite frankly, a hash or some sort of global namespace with a relative index. There's multiple ways of doing it. It doesn't need to be prescriptive that you can only do it one way. And realistically, we don't want to do it only one way. But we need some way of understanding that if you're referring to a component, there's a unique way of referring to it, be it a package URL be it a CPE. There's something that's, you know, that is definitive within a name space. And obviously for the component you want to know what's version is. And to improve the reliability here because people aren't great about after they applied patches updating version numbers and things like that you really do want to have a hash. So you can say yes I'm talking about this and I really need this of some sort on that component. And then from those components that component you want to potentially have relationships. Because it has dependencies on other components included in it, or it has, you know, interactions. And so, being able to serve at least go down one level at a minimum, hopefully more is kind of needed in terms of being able to be a get this automation going. And then obviously the person who created the SBOM needs to be identified personal or company, whatever, who created the SBOM or tool for that matter needs to be identified nuts for building the trust. So if, you know, third, so basically if maintainer from a project created the SBOM to go along with the release as part of the release process, that would have a higher degree of trust in my mind personally, then if a third party tool is sitting there scanning and trying to figure it out. Or when you've generated an artifact out of a build, getting that accurate, I probably would trust what's coming out of the build as the first thing rather than someone taking doing a binary analysis on a binary. You know, it's just a question of understanding who's created it and then why, you know, what level of knowledge do they potentially have an authority over the information. But at the heart of it is really just these elements and then being able to sort of say, do I have unknown knowns or known unknowns, I should say. And if we've got the unknown knowns and known unknowns, we've got being able to signal that in some way, you know, is a set complete of the dependencies is what we're looking for. We have another question from Julie. Would you like to unmute and ask a question. Yes, this is Julie Cub from NTIA ITS in Boulder. And I was wondering about the code signing of binaries in terms of the the SBOM. So I noticed that it has all the items in your list. But what we've recently implemented is code signing of binaries so that if somebody changes our code will know that it's not our our original or our latest deploy. Yeah, the hash function is meant to sort of capture that type of thing, be it a hash or a signing some way of basically authenticating it. There's also the signing of what's been given to you and the trust points between and some of that is beyond what I'm talking about is minimum viable here. So there's there's a lot more that can be done. What I'm trying to sort of distill down is the means of the minimum elements. And so if you've got signing on your binaries. You're saying the signing, you're saying, okay, this is a person that's at some element of who's given it to me and what it was like, what it was like at that point in time. Is that correct. Yeah, there's some I haven't I'm the software engineering division G so I haven't done it myself but we now have a an ability a tool to code sign our binaries. And then when people download it they know if our executable was what we originally deployed. Yeah, and that that mechanism, people have been using hashes for that as well. For knowing whether it's matching and like you know when you're getting some distros, like you gain OS distro, they will have things all the elements and they're potentially signed and they'll have their final images signed, and then have them available in that way. So, the signing is a key element of this is just a question of the mechanism for doing the signing and the checks, but the key is to have some sort of independent check on the image that hasn't changed. And the version number is not sufficient, which I think you found. So what sort of going from there. So, let me sort of keep going on and we can come back to that at the end if you'd like to talk more about that. Right now there's a variety of current software build material formats out there. So, I've been involved on the SPDX one for about 10 years now so that's when I'm, I know best. The NIST has come out with SWID, and that also can be used to represent this minimum Bible and then in the last few years, the OWASP communities come out with Cyclone DX. And again, it's available to generate, you know, through the package managers and through the builds, and is able to again represent what minimum Bible is. So we've got multiple options out there that are suitable for automation and can potentially be the key elements can be interchanged between all three of them. The SPDX file format can actually go to spreadsheets, which legal departments seem to like to use. But we also have a format that is, you know, tag value, which is like a JSON. And we have JSON and RDF and YAML and XML for SPDX. Cyclone DX also has JSON and XML as the most common formats, so it can support them quite well. And we have XML for SWID. So all of these elements are there and interchangeable to a certain degree with various tooling that's in play. So when you're talking about what to do to represent those minimum Bible efforts, like I say, this table just basically shows you these are the fields that each of the formats recommends you use to fill in the elements with. And so, you know, for working with Cyclone, you'll be looking for using the publisher for the supplier name, a name for the component name, and then some unique identifier information and versions of forth and hash. So there's ways of doing it in each of them for these minimum elements. And what we want to try to do is at least use one of them, rather than inventing your own is kind of what we're hoping for here. So there's not just there. I don't think we'll ever see one, just one way to do it, but I do think that as long as we can keep it consistent and keep it interchangeable between these formats, and then build on these formats. When missing use cases are there, or needed or detected, I think we're on a path and at least automation. And, you know, part of the automation means we need tools, be it a tool to sign something, be it a tool to, you know, consume something. So in the discussions that have been going on in the NTA efforts, we've put together a taxonomy of type of tools, where we're sort of looking at, you know, are you producing it, are you consuming it or are you doing something to transform your build materials. And in the produce, maybe tools that are creating it as a part of a build, or maybe a third party tool looking at someone else's source, you know, source repo or, you know, binary analysis tool to do an analysis for, you know, components that are in there. Or maybe a tool that's, you know, taking and doing one of the other two and also doing some manual editing on the top of it to refine some information that's ambiguous. This tends to be useful in the licensing in particular, where there may be ambiguity as to are an option as to which license may be chosen for component. And you may want to explicitly assert that you're planning on really seeing this combined work under one of those options specifically. So that you can't really do that automatically. So being some having some degree of edit on top of some automatic is usually where we're seeing things emerge that are productive. Then you may want to be zooming it into your, you know, be able to look at it. Some of these formats are not exactly friendly to the human eye and the text stream. So, you know, viewers to look at them to integrate them in with your system to do diffs between things to import it into your database and then, you know, do policy checks on top of it. These are all types of tooling that's potentially useful. And then being able to translate from one format to another or from one file type to another file type. So that sort of tooling is needed here because again, we've pretty much recognized no one's going to do, you know, no one one format is going to rule them all it's all we're going to have multiple formats out there but we want to make sure we preserve the interoperability. And sometimes you want to make be merge what's happening within a in a software build materials with other material data, like you may want to in your own system. You know, the software build materials information with lookups to the MBD and understand which, you know, what are the vulnerabilities that are known about a piece of component at a point in time, and you might be tracking that internally in your organization. So, you know, and you may or may not need to release a report on some of that information. Similarly, you know, we need to have ways of making it easy to pull these things in in the standard format and have tooling libraries to say, you know, I want to read the Cyclone DX or I want to read this SBDX getting it so that we have these libraries there and, you know, that are open, and that people can contribute to and find bugs for and tell us about them. All is going to be helpful. I have a question Kate. Sure. In the question and answer from you. Yeah. Why are there three different formats seems to add complexity, especially in the transform area. Yep. Because everyone has ideas and know, and like I say, this is what we've got right now. And I'd rather have three than 1000 at this point. So, as PDX basically started on doing this as a part of doing software releases and licensing back in 2010 so I guess 11 years ago now. SWID, I think started in 2009 for the first revenue had a major revision in 2015. And so it's there. And it has additional information on usage. And that's where its strength point is. And then the dependency check tools that were coming out of OWASP has to have this internal format of Cyclone DX. And they were finding it very useful for tracking built artifacts, especially in some of, you know, the dynamic infrastructures. And had sort of standardized on that. The Cyclone DX basically, you know, adopted some of the licensing information from SPDX and SPDX is looking at adopting some of the vulnerability tracking stuff from Cyclone. And, you know, it's sort of looking at evolving potentially more of the usage information that some of SWID has. So all of these are living projects and are evolving. And I'd love to see them all evolve, at least into similar capabilities, but I don't think we can, you know, the communities have their own interests and their own needs that they're, you know, they're working on in their own areas of expertise. And so I don't think we'll ever get just one. I would like it, but there was a couple of efforts that we're trying for doing that, but you know, there's, it was a bit too frustrating for some people. And there was an effort that we tried that last year. I'm afraid I can't quite see the chat while I'm presenting, but I'm assuming I can go forward for now. Anyhow, these, we've got some Google Docs up there right now that have been worked on in some of the working groups for each of these communities that list the tools. And there's other nicer views. And we have to make up even a prettier version available on this in the NTA site at some point in time in the near future. But if you're curious about some of these tools, this, these documents are there and they're publicly accessible. And if you see a tool that's sort of missing, go feel free to add it. Each of the documents, you know, has a template, standard template to be used in it. And to talk about whether it's producing, transform, consuming or transforming so you understand when you see the tools, it's something you might be wanting to look at further. And we talk about like, you know, things like physiology, which is an example here, you know, it's got some websites on GitHub location. It has, you know, how to go about installing it, how to use it and you know which versions of the formats are supported in it. So, you know, we've got, we've been trying to sort of classify the tools, and it's not just the open source tools, we've also got commercial tools in the list. And so if you see, if you know a tool that's missing, like I say, just please let us know and add it. How we're sort of looking at some of this stuff inside the LF well obviously the open chain for the processes from the common data format like for the data formats at the LF we're using as pdx. For what we're working with, and then we've got some tools projects that are tools projects under the act umbrella that are working to create workflows and work these things forward and so I'll be spending most of the time talking about the sbx because that's what I'm most familiar with but I'm not trying to say anything negative about the other two formats. There's people that can help you on those two. So, the open chain specification is out there now it's an ISO standard. So that makes it easier for procurement people to start to specify it. And it pretty much identifies minimum level of processes it's about 10 pages it's not a hard read. You know you can get it, you can get the 2.0 version of it off of the websites. And then or you can get it from ISO directly. It's translated into a variety of languages, Chinese, Japanese, Korean, Portuguese, Italian. So, if you're interested in processes behind working with sboms I'd say, you know, what you need to look at inside your organization and say take a look there. Software package exchange is can extend well beyond that minimum Bible. It's a lot of use cases that can support that are not part of that. So, it's easier focusing on the basic sbom concepts but it's easily able to represent an sbom. And it can let you exchange more, you know, more information in the ecosystem. Oh, sorry. When you get a break I have another question on the question. Okay. Is it okay, good timing to take that question? It's a bit longer question from Joy. A very interesting approach and tooling solution. How about getting 2021 3DS bomb ES back into Ella in 2021 timeline. So, the 3T so see earlier comments about trying to get everyone working together. Basically, the 3T effort started up its own group and myself and some of the other SPDX people sat in and in on those discussions as part of trying to get it to all see if we can find one unified solution here. And there was, you know, I think we've got certain things are reconciled. And so the new, new version of SPDX SPDX three is going to be containing a lot of the 3T. Some of the 3T ideas we've refactoring SPDX three. So we've got to two right now we're working on and for SPDX three, we've refactored it to just be a core, a basic core, which lines up with sort of what you're seeing here and lines up with some of the stuff that we saw on the, you know, some of the stuff we sort of seen in the SPDX light community. So NTIA had in parallel with what was happening in NTIA and coming up with this core minimum viable. There's a work group in Japan from open chain that started looking at we wanted to have a minimum set of SPDX and they called it SPDX light and that's actually an appendix and this back and I'll talk a little bit more about that in future. The 3T folks were looking at trying to come up with a model. Well, SPDX already had a model underneath it. And so the question is okay, well, what can't you represent and how can we evolve together so there's been many, many, many, many, many hours of long discussions with the 3T and the SPDX community on trying to unify. And the 3T folk are sitting in on the SPDX tech calls now and working on the model in common for the next round. So it's moving itself forward slowly. Hopefully that answers. I'm sorry, I can't see the chat. Well, I've got the presentation up but when we stop presenting towards a little later. I'm happy to get more discussion about that. No other questions Kate. Okay, thanks. So to the point here we have an underlying model with SPDX and we've had it for, you know, pretty much since we started. So there is actually data model that sitting there. And that gives us the power to go to all these formats, and to transform back and forth between all these different file formats. And so, and also to validate quite frankly, that you know, if someone gives you an SPDX document, you know, is it valid to document. Well, by doing the checks against the model and the framework, you can say whether it's valid or not. And similarly, you can go to a spreadsheet between a spreadsheet and a JSON file with the tooling. And so that's been very powerful for us in the SPDX community. And as a result, this is what we're serve. I'm sticking with, which is making sure we always can have an underlying model. And that's one of the things that, you know, OMG obviously cares about. And so, you know, we're in a certain discussions with, you know, making sure that anything that we evolve to is going to have an underlying model that can be validated. So, SPDX today is being used already with various tools as an interchanged format. Quartermaster and OSS review toolkit, both can generate SPDX as part of their builds as they're building systems and monitoring things. OSS review tool can also generate Cyclone DX. So another format is there with that one. And we can also have tools out there that are also going and doing the analysis of existing images. So in specific, specifically of interest, the TURN project is taking and doing analysis of a container and summarizing it. Phosology will take and look at sources and repos and basically let you go through and summarize what the licensing is. So it has the edit aspect associated with it. And it also can go in an input in other people's SPDX documents. So you can compare has something changed over time with what you're looking at from a source perspective and what was issued as an SBOM before. And then the project has created tools and libraries for various languages, for Java, for Python and for Go. So you have standard libraries to include into your tools to actually just sort of read and write formats and make sure that they're valid and you can transform them. So, you know, we're trying to build up an ecosystem bit by bit by bit, as are the other formats. So if you want to know what tools are out there right now that there's a shortened URL document and there's one for each of the other formats in the same tiny CC format if you want to look at the other formats too. But with the SPDX one, here's the ones that are there. So let's actually start getting into the more just, you know, get into the, okay, what does this really mean when it hits the road. Okay, that initial example that we had. Sorry, I guess I can't know I can't get the chat to come up. Anyhow, the initial initial example we had earlier could have been represented from a draft diagram into something that was just a table or spreadsheet and have some of the key elements. So let's take this example and sort of work it through a little bit more. Okay. One of the now we can now we'll sort of go back and start to see things. One of the tools that's out there right now is been contributed in from cert. And they did they created this to help the NTI effort. And it's stateless anything you're putting in it you're not you're not sort of logging but it's a good way of for experimenting. And so I've got here the link to it in the slides. And when we bring it up. Here's a swift here's what it actually looks like. And what you're doing is you're filling in the key fields. There and you can add components and it will eventually serve take and look, you know, generate so let me just load up. Let me just import the I filled it in before the before this to for that example. And so here's your application. And what you might want to do then is you've got your component name application which is your primary. And then you've got saying that this is your primary component and then you've got Bob's browser, Bob's browser and its version and you've included it. And it is parents component is primary. And then you've got the Carol's compression engine. And it's parent is actually the browser. And then we've also got the bingo buffer. That's, you know, related to the application. And actually, it's actually a compression engine. So this is, you know, and so if you go and click on this to generate the S bomb. Here's what it looks like in SPDX right now. And so you've got the SPDX information. And this tool also show you what it would look like in swid. And what would look like in cyclone. And they've also got the Jason versions, this tool implements adjacent versions for the SPDX ones you're going to have to go to another tool but I can show you that in a minute to enable show you a graph. So if you want to start experimenting with the different formats, this tool just lets you sort of start experimenting with the minimum Bible and looking at these things. And we'll generate a valid SPD, you know, all the valid formats. So when I go back, let's see. This is one of those things where the website is interesting because it doesn't seem to quite go back to that top level, but I'll just close it here. The other thing that's of interest here is the SPDX light is got a very similar concept. Then the minimum Bible does. And it does include here the SPDX light fields. And so if you wanted to, you could extend this and fill in the SPDX light fields, which then makes it easier for you to import into systems that are already have SPDX and are expecting this. And so some of the companies have been asking for it. And so this will let you experiment with it. See what it looks like. Figure out some next steps. That type of thing. Kate, we have three questions. Oh, okay. I think I can actually see the chat now too. Good. Okay. So the first one is, are there any ideas for the process? How software suppliers transmit that from info to the customers. Like a fast disclosure portal question mark. Yeah, there are some ideas on how to convey the information to the suppliers. One project that is being spun up is something called the digital bill of materials, where you can share a basically share in a standardized fashion and set up effectively channels and applications for private public and private. And if that project ends up, you know, gets spun up when we're doing that one of the things I want to see come out is for there to be effectively a channel so that any open source project can log in. You know what they consider their reference bill materials there. There are conventions out there right now. For the materials and where to put things. So generating them like the free software foundation Europe has a site called reuse dot software. And for people creating them, you know, doing software development, they have some guidance so you can make these generate software real materials for instance. Hopefully that helps. Next question I'm seeing from john. Okay, but not really anyhow. There's no, as there is no current standard for an S bomb the three separate formats were created by three different organizations. Open chain and the least foundation among numerous other groups are working together to agree on a standard format. Well, actually, so the S bomb, you know the term S bomb is interpreted by a bunch of people so all three format, what we're trying to at least try to do through the anti efforts is agree on what it should contain as a minimum Bible at least. So we can at least start to tackle it. And I think we've got some degree of agreement on that and all the formats can represent it so I think it's moving itself forward. And I think that's going to be as good as we're going to get for a while. So I guess the last question is, should code snippets also be included in this bomb. If, yeah, there's, there's reasons to it and some of the formats can support it. Specifically as PDX can support having snippets included. If the licensing is different than the base licensing or some piece of codes been imported. So yeah that use case is very valid and has been represented. And so on the licensing, you know build materials for licensing is being able to include snippets as component as an elements relates the files that they're in is something that's already there. Okay, Tim's asking. Is the D bomb you mentioned the one unisys is working on yeah the D ball it unisys is working on trying to form up consortium with others that are interested in helping to evolve that so Chris Blask is taking the lead on that and happy to connect you if you're interested in learning more. Okay, great. Thanks for answering the questions. You know, like I say this is all the interactive part right now so feel free to unmute and just ask questions directly to. Oh, can I clarify what I mean by snippets. Sure. So what a snippet is, is it is a couple lines of text that might have been included from somewhere else so there's a lot of repositories out there that say, you know, hey how do I do this and so these two lines are you know, here's this here's this little, you know, phrase of Python code. And then someone takes that cuts that out and puts it into the application they're running. That's a snippet. In the sense that it was probably put up on a different license terms than the types of terms that you know they may be releasing their code under. It may be the same but it may also be different and so sometimes it's useful to be able to, you know, call those things out. Hopefully that helps. So what we've also got here, let me go back to the slides and I'll just sort of do it that way this way here. So as you can sort of see, you know, when we actually take and you know we're looking at that example. I'm not going to have any generated but let's see if this will work. So we're looking at we can we can basically see the compression you know we can see the same graph that the initial diagram was having. And it was a nice feature just to be able to have these graphs and you can download these things and examine them further yourself. The other tools that are out there to play with. And are useful. And there's a diagram. Yeah, just in case things are not going to work. If you hear about that the specifications out there and it's just a subset of the fields and those are the fields you saw and you've expanded it out. And what it's just defining as a valid SPDX document. It's not like it's not but these are the fields that various people want to see when they're bringing in products. And so they basically articulated these were the fields that they were looking to see and some are mandatory and some are optional. They're not all mandatory and but if you want to learn more about those this part of it. The SPDX specification is publicly available. And you can, you know, go to the appendix on SPDX light. And it sort of talks about these are the fields and then if you go into the sections in the spec on the document creation information, it tells you whether something is mandatory or not. So, all of this information is hopefully recently at your fingertips and if things aren't clear, you know, just chime in on the SPDX checklist. You know there's people willing to help there. Okay. Yeah. As we're looking through that list of mandatory information. We're beginning to hear laws about bugs must be fixed and issues must be fixed within a certain amount of time. Yeah. That's starting to be getting to track that information in here and can we use this. How quickly the nesting. To be able to fix things in time you need to be able to discover them in time right and so this will help with that. In terms of the terms and usage of for the software and the you know terms of service and things like that that service sidecar type of thing. And it's potentially a profile type of thing. There's also a lot of stuff on vulnerability that people want to know like another case I'm hearing is when you ship me this or when I'm taking ownership of this what were the known vulnerabilities at a point in time. So we're looking at extending the specification for you know showing that use case and I know I think cycling's got that one already handled. And we're probably looking at pulling some things very similar into SPDX in the next release to be able to show that type of thing too. But usage in terms of you know service agreements and things like that. That would be something you might want to convey along with the contract it might go on a deep on that you really wouldn't want to put into a bill materials. If it's you know between proprietary company you know between one company and my commercial company and other commercial company they'll have various terms and one of the myths that's out there on this and I'll just say it right now. The license that we've put the data in an SPDX file under does not preclude you putting commercial terms around it. And we chose that very carefully with a lot of lawyers involved in the discussion about nine years ago for that reason. So if someone says oh well it's CC zero for the SPDX no that just means it is basically you can share it effectively. It does not mean you it does not preclude other terms to be applied. So I will I will just bring that point up right now I got the chance because it just seems to come up over and over. We have a couple of questions. Answer. Thanks. The first one is why is it called SPDX light it looks like the list is longer than the SPDX SPOM minimal list. So the list I was showing you wasn't the SPOM SPDX minimal SPOM. The anti the list I was showing you for SPOM was one that anti agreed on is minimum and SPDX requires a few other fields in order to be a valid file format. And so some of these other fields here are things that the minimum doesn't have but we think it should specifically knowing when it was created is important. That's not in the minimum viable right now. And so if you want to try to understand you know which which SPOM for this product is the most current having a date stamp is a really useful thing. The other thing is to is our versions of the specification will change over time. We've evolved you know for multiple releases as you can see that isn't a minimum viable, but I do think it should be. Because you know the specifications, you know, cyclone has evolved as pdx's evolved swids evolved all of them have evolved. So being able to know exactly which version of the specification you should interpret the data from is kind of key. And then for SPDX since we came in from the licensing background obviously having a data license. So that you know what you can cannot do with the data is useful. And so then, like I said, the other fields here let me just go back to that example field. Um, let's see if I can bring it up somehow. There seem to be another related question if you want to take that relationship seem to be one of the powerful features on SPDX, but the light version does not include these relationships. Is there a reason to get rid of them? No, like profile. No, actually, it's the light profile can use all the relationships that are in SPDX. If the people working on light profile on just sort of standardized on on the level plus one. They're certainly welcome to. And the includes profile is there music contains it includes an SPDX and so you can certainly, you know, match up with the minimum viable. But it's really useful to know if something is statically linked or dynamically linked. And so being able to work with that and have that type of information. I, you know, I kind of like to see that as cyclone evolves in this direction that maybe we can collaborate and making sure that we have coherent sets of relationships that we are working both both projects are working towards, because they are useful. And like say anything get things have gotten added to SPDX have been added because someone had a use case and we couldn't solve with what was there. So all the relationships of things that people have wanted to be able to represent in the builds or build dependencies of things like that, that are important for understanding what's going on. Okay. One more question. Sorry, that's okay. Should cuts components. Also be included in as bomb. Okay. You want to explain what you mean by cuts components here. I'd like, you know, I've got an idea in my head that I want to double check here. Can you unmute and just sort of chat with me. And you hear me. Yes, I can now thank you. Thank you. Thank you so much for this presentation. Actually, I'm an open source license compliance expert. Maybe that's why these questions are coming up from my mind. So cuts is commercial off the shelf component like vendors, we buy them from vendors. So should they also be included and then I mean I'm working from AMD right now. Advanced micro devices. So as of now the S bomb, it doesn't contain all those things. So the issue here we, I mean individually as a company we have is our products are moving so fast. So let's say every month there are new versions, new features and everything. So in that scenario, would you still suggest that as bombs will be useful. Yes. Very much so yes. Yes, yes, yes, yes. Okay, there's nothing to preclude you representing a commercial product with an S bomb. And okay. One of the things that was done in the NTIA effort is they. We had a health care group to approve of concepts of trying to use these minimum viable fields and to see between the medical device manufacturers and the hospitals where they containing were they able to communicate effectively. And so, and there it was all things like windows and, you know, patches on windows and, you know, sub components and things like that. And that was all done on behind NDAs, just because, you know, some of the bill of material information is considered. It's potentially an issue from device manufacturers. But there's nothing like say that's why I mean like you can represent this information in these S bombs. You know, it's just a matter of coming up with okay what's it called well it's windows called windows and it's called this version of windows and oh hey there's a, you know, a hash or a signature on the image so that you have it to know. All of these concepts should be able to be applied to commercial software as well as an off the shelf software as well as any open source. Thank you so much. Thank you. Okay. Yeah, happy to get you on how to sort of get these implemented. Because you know, get this type of communication happening throughout all these places but as you say it's all moving so fast we need to figure out how to automate. Yes, yeah. Yeah, thank you. Sure. So if you want to play around with the Swift mom generator. I will be putting the link in towards the end of this or probably shortly actually you can sort of play with it it's stateless so that they're not storing it anything on their server. And then I think the other tool I just want to show you guys is the spdx online tools. And here, I've got it loaded up already. And what happens here and this is sort of if someone gives you an spdx document. This gives you a way of validating it to see is it real or not so one of the things I can just do let me just go grab it is I downloaded that ACME application. And one same one I imported in and I just opened it, which was actually generated from the tool originally. And it's file type is tag. And so I just want to validate and I'll just tell me if it's valid or not. So someone gives you an spdx document it's pretty clear. It's pretty straightforward for you to take a look and see if it's validated this tool will also let you convert it. And so if I wanted to take the same file. And get in again. And I want to take it from tag. And I wanted to take it over to Jason. You know, call it ACME there. Then it can convert it and I can download it. And there you can sort of see it in Jason. So you can go between the file formats and this is the part of power of having a model underneath you. You can go between you know what's potentially easier to use in your system if someone gives you something in, you know XML you could probably move it over to Jason and vice versa, depending on what you're using internally. There's other to play with things and then there's a lot more, you know sophisticated tools associated with binary analysis and with, you know source code scanning and so forth. There that you can find from the tools. From that tools directory. I guess the other one thing to serve, you know, show is, you get lots of questions about how to represent things. And so, who's part of the SPDX group and is also, you know, co-lead for the legal team has been working on pulling together visible examples for everyone to work for them. And so we've got these SPDX examples here. And so if you're curious how you might want to represent something. We've got some simple examples showing here what, you know, a basic hello world what does it look like, and you know it's all in one package what would a bomb look like. You could do it in separate packages like, you know, especially as we start to get into very complex containers, you're going to want to partition things into logical portions. And so with the SPDX stuff you can do it and these are examples you can go off and go in and look at to see, okay, here's how this thing was done. Here's what the military looks like here's what the fossil look like. And it has, you know, the content of a source and for binary. You know, so here's what, here's what the SPDX would look like for the source for this hello world. And then here's what it would look like for a binary or built artifact where certain, you know, things have been coming forward. So those examples are out there to explore and to learn more about. And then those are just small ones and then I guess one of the things we're starting to do here at the next foundation again with the view of sharing. And make it easier for other people to see some of the large projects that the LF were actually putting up the source s bombs that are sort of scanned. So, you know, basically the LF energy program for instance, if you wanted to go and see what the s bombs looked like for some of those projects in there. And this has been produced from phasologies tool with some manual editing on top of it. And I guess this one's two megabyte so pretty big, I probably should find a smaller one, but as you can see you can go and click on it and start to look and see what the. What the S bomb would look like for the sources for this, but it has been curated to some degree, in terms of what's in the file and is there assertions at the higher level and things like that. There might be a few places in there too that there might even be some snippets for those who are interested, but I don't know. If I may, I want other reasons for curating. Why would you want to curate. Why would I want to curate. Yeah. Well, you want to curate because the sometimes when you're doing the scans you're finding that you can use a piece of software under the terms of, you know, BSD, or my BSD three, or, you know, Apache to their maybe that any license header at the top. When you're deciding to take and build it in you may want to say I'm an explicit license has been chosen but there's no real way of signaling that as to which are the options of something when there's multiple licenses is being there so being able to, you know, curate and say yeah no I know that they intended it to be shipped under this license from the overall projects perspective because that's the one that works with the rest of the pieces of licensing that's there to that helps people guide people further. Thank you. Sure. Yeah, is is the with the ability to update software not just on windows machines and that type of stuff but in devices that have been deployed out in the field for years. The ability to have meeting standards really needs to track the embedded software release, rather than the device is that certification something that would be found in the nest bomb, or does it get tracked outside of it. That is an area that we're trying to grow into. So we have standardized ways of tracking what's there. I think it will need to be in there. What certifications are there and what certifications associated with things. However, I don't think any of the formats are catching it right now. So it's an area that if you've got viewpoints and thoughts feel free to go to like you know, go on to the spdx issues and describe the use case so we can make sure we're thinking about it and give some examples, and that would help us evolve. A lot of this stuff gets conveyed in other ways too. And it's not possible for automation but before you deploy you want to know what's been certified what's been tested things like that and, you know, establishing it so we have a clear pass of the evidence and the handoffs of the evidence as well as the pedigree is an area that needs to work in this area in in this bomb format but that's, you know, those are cases beyond like what I've got here right now is just your basic crawl. Working with us bombs. I think those are some of the running potentially you know crawl walk run I think those are run cases and possibly even flying cases. I think we'll go there but we've got to build it up because you know, there's different levels of knowledge throughout the industry and we're going to need that stuff for the vulnerability stuff no question. As well as quite frankly for the do I need to retest everything for a certification or not. The IT side device side. Dennis the question. Very well, thank you. Okay, just checking. Anyone else have any questions. There is a question that came in. Okay, sure. In the question and answer. The granary shown up to now is at the package and module level what cases do you recommend to go to the file granularity level. So the source bombs source code bombs we I recommend those good the file level, especially from the build, because right now we're just seeing the components. You know, an approximation for license and we found from analysis that's been going on on the licensing website anyhow, that the licensing at the top level doesn't really match reality all the time. What's actually there from the interactions with licenses. I gave a talk on this with Richard Purdy from Yachto about three years ago now. And we were looking at the Octo project and seeing how you know what what the coherence is there and so I know that that project for instance is very much interested in making sure we start to have, you know, automatically generated S bombs from the Yachto, as well as the reproducibility. So that project is again focusing on those areas, and then having the information associated with reproducibility carried in the S bombs. It's going to be something that maybe needed from the safety certification perspective, because you need to know for some of the standards. You know, who's, who's built it where they authorized what the reputations were things like that, being able to track that as part of the S bomb is going to be useful down the road to, especially once we interact with open source. Any other question came in on the chat. Yep. Oh, that's right Steve's just reminding us. So for this example repo, if you don't know how to do something, and you want to figure out how to do it like, you know, the examples here actually are showing the file level back to the earlier question. But if you've got questions, please just open an issue. We're looking for things that people don't know how to do so that we can come up with reference examples. And so that's there too. So I guess just to sort of wrap this up then for getting close. There are benefits for adopting an S bomb. And I would encourage you to sort of start taking the steps towards doing it. Be it as a developer to go ahead and make it easy for them to be generated from the code you're working on, like by putting standard licensing in, like, you know, sbx license IDs and the headers or something like that. Or, you know, setting things up in your CI CD pipeline says that on your releases you're generating out an S bomb. So, you know, so as developers, you can do things and then, you know, as you're bringing things into your organization, you decide whether or not you want to use an open source project, go and look for its S bomb or ask for it. And then, you know, when you're creating products, be able to make it available to your customers. So it helps with the licensing and it will help down the road with the vulnerabilities. And it will help with the risk quantifications. So, and then I think as we get this whole ecosystem sort of shifted over. We started to see some operational costs getting lowered. So, you know, I think it's, it's, it's a large lift for the ecosystem, but I think if we can take it bit by bit piece by piece, over time things will get more efficient. So with I guess that There is one question in the chat about API. Do we have any API to make a call from some pipeline. For in terms of what. So, like, there's various tools that are out there that will generate out and have API interfaces so that they. So you can, you know, incorporate them into your CI CD pipelines and generate a desk bombs were served. We've been doing some experimentation. I think, you know, anything that's got some command line interfaces can work with some of these. And do the generation and so some of these tools definitely have command line interfaces. And so like scan code will let you, for instance, is another tool that's out there that will let you generate out SPD access bombs. When you're doing your builds and like, I think there are others. And so checking out through the tools and seeing which ones have command line interfaces and which ones you want to plug in. And then the server has a little linter tool that you can plug into your CI CD pipeline and it'll help you again, I would gen out an S bomb from your builds. And it's a checking that everything is finding its licenses properly to. Okay. One more question from Steve in the question and answer. Okay. Um, You know, for this because that the SPD example repo we've got. Yeah. Sorry, how would it benefit an open source project and community to create a response for their own project releases. That's the question. Oh, how would it. Well, Debbie and has its variation of this already and has some degree of compatibility with us. Quite frankly, it benefits by being able to keep the discipline on the licensing checks. It means you suddenly keep your code usable. One of the things that starts getting surprising people the time is when they starts actually doing the scans at the source code level. They find that pieces have been brought in from other projects because it was convenient and that may not be compatible licensing. And it's much easier to find this as you're scanning and as you're building along and fixing it right as you go along rather than when you're trying to do a release or someone's trying to use it and coming back to after the fact to So from a licensing perspective, at least having the scans happening and the bill of materials being generated means that, you know, you have a check that you can put into your pipeline flow and say, Hey, if it's not matching this license, we reject and we grow we work it or go find it and where it's easy to do so. Because the earlier you fix it, you know, see spot these issues and fix these issues that, you know, the cheaper we know it is to fix them. So we're working on this right now in the Zephyr project and we're using Zephyr as a prototype here. And we're working so that we can eventually get the Zephyr builds to be generating out the S bombs as well on build so every time you're building the IoT device image. We want to have a file level as bomb available so you know exactly which files are in there. One of the cases that pointed that we needed this for us was amnesia 33 and that certain software stacks were impacted and in our LTS on that project. We did use part of one software stack we didn't use it at we didn't use the parts that were impacted. And so we had our own code for those parts, but we needed to be down at the file level to understand whether or not vulnerability was appropriate or not within the Zephyr release. So, getting it so that we can develop builds and as people are trying to create very customized images for these builds or for distros. Having that level of transparency is going to be key. So one last question looks like in the chat in the actual source code we have standalone components. What is the most straight way to have information stored in order to generate NSB DX document for the product. So, the reuse software project has worked up guidance on how to start to articulate the licensing and some of the reference information that's valid for an IP perspective into your source. So tracking the key information in the source file with the source file is definitely the preference and then the tooling will automatically generate out a few if you follow the release guidelines you can generate out an SBOM right with their link tool. And we've taken that information and those guidelines and applied that to the links kernel. So if you look at the links kernel, you'll see that we're following the guidelines there of how to where to put licenses, where to put, you know, the identifiers how to connect everything together. And we're doing that in Zephyr as well. So, like I say, I encourage you look at links kernel, what's been happening there and then, you know, there's a whole bunch of other projects that have adopted the license IDs anyhow, this point now so it's easier. And the more we have these adopted the lesser guesswork happens is just is it this license or is it this license very or is this license very I think. So, Philip on with Don did some it has a did a study of it and the number of variants that he found with his candy tools is actually quite disturbed disturbing for the same license and you know, expecting these tools to do effectively AI to try to sort of guess the licenses and you know, still have to fall back on man, you know, someone manually looking at it making judgment call, making it as quick as we can to automate what the licenses, I think helps the whole ecosystem. I think that that's it. Pretty much. And thanks again I guess for everyone who has asked questions and hopefully let me just go to the last slide. There's more information out there for those who are particularly interested on the licensing side. There is a free course that you can take that goes through the basics of it. This one here. There are there more more terms available. So, open source, you know, licensing basics for software developers will tell you how to go about creating the SPD X IDs and putting them into the files, as well as the other ways of, you know, catching it so that to only can start to recommend, you know, recognize this stuff and give you a bit of an orientation about some of the licenses as well. So if you get a chance, and you want to learn more about that just take the course it's about an hour and a half course it's not too long. But it does give you some of the basics. So some of the stuff makes a little bit more sense. But it does give you some of the resources. So I'll just say thank you very much for joining us today and turn it back over to our host. Great. Thank you so much, Kate. That was wonderful. And thank you Shua for all of your help as well. Thanks everyone for joining us. We'll be posting this recording on the Linux foundation YouTube page and also we'll be sharing Kate slides on Linux foundation.org. Everyone has a great day and we'll hope you join us again soon. Thank you. Bye. Thank you.