 Well, let's go ahead and get started. We've got a lot to talk about today So I'm Jeff Shapiro from Linux Foundation and this is Gary O'Neill source auditor, but you guys may know me from SPDX So welcome everyone. Thanks for coming. So We're gonna be talking about S-bombs today And I know there have been a number of sessions about S-bombs and maybe some of you have already seen some of them Maybe you haven't our goal is to give you a primer to give you enough information So that you understand how to read an S-bomb use an S-bomb and generate an S-bomb So these are two definitions that we chose Which I think give a good really good Description or summary of what an S-bomb is so NTIA is the national telecommunications telecommunications information administration, it's one of the government agencies that's creating these One of the specifications for S-bombs Based on the new mandate to supply S-bombs to the federal government They say and I agree a software bill of materials is a nested inventory. It's a list of ingredients. So it really is a Exactly what what it says just it's a list of everything that goes into your application your package your service Gartner who does a lot of research Says S-bombs improve visibility transparency security and integrity Of all the software in your supply chain and all of those things are important S-bombs it's S bombs should be human readable But they have to be machine readable if they're not machine readable They're not very useful because we use tools generally we use tools to generate and consume S-bombs They give a list of your components and dependencies. These can include source files packages libraries binaries Things that you can put into a container Essentially anything that can make up a software system can and should be in your S-bomb Includes some basic and vital component information such as the author of the package The name the version enough information that you can Identify where it comes from and you can get provenance information about that component It's important to note that the components that are in your S-bomb can be open source closed source proprietary For internal use they can be you know written in-house They can be Acquired from from anywhere in the world So why are S-bombs important? So we talk a lot about security vulnerabilities You've heard not just with S-bombs, but in general why of supply chain security and checking for vulnerabilities and is is critical license compliance is Actually one of the main reasons why S-bombs were originally developed many years ago Maintainability we talk about provenance about where your software comes from Reproducing builds etc and new in the last couple years is government policy So security vulnerabilities you want to be able to track vulnerabilities. You want to know if they exist on your system License compliance is it has always been important Regarding knowing which licenses apply and finding any license conflicts and just to repeat maintainability is Really about increasing the reliability and reproducibility of your of your builds and now the government says if you want to deal with us You've got to supply S-bombs, so there you go now. It's not just about supplying them, but hopefully they're using them too. That's another matter So let's talk a little bit about the the standard formats that are out there You know there's actually three standards at the NTIA mentions in their document It'd be nice if there was only one but as with many standards, you know, there's many to choose from You know, what's important is that you use one of the standards now I'll go through these three, but I will say that there is some collaboration going on across these different standards I work with people from OASP and the cyclone DX community to try to make sure we can do round trips and write tools To be able to translate between them So it's not as bad as you think because there is some collaboration going on But these are the three choices you have. I'm I'm involved in the spdx community. It's an ISO standard We're working on 3.0. It's a very large community We support a large number of use cases that are out there and also a lot of file format So there's the standard the vocabulary and then there's the different file formats that are supported So we support everything from a simple tag value format to RDFXML even a spreadsheet Which the lawyers love to consume spreadsheets as their as their standard formats Cyclone DX is from the security community. They're pretty focused on the security use cases They support JSON XML and protocol buffers as the file formats and then SWID is a NIST standard that focuses on software identification So let's talk a little bit what I want to do in this talk is get right, you know kind of get right down into the details I've gotten a lot of feedback from the community that says S-bombs is too hard. There's too many fields I'm looking at the spec. I got to fill all the stuff in. It's not that bad if you want to just do the minimum amount It's actually pretty darn simple and I'm going to go in and show you some examples of exactly what that looks like So this is from the NTIA. It's the minimum S-bomb for it to be a viable S-bomb to be used So these are the these are the things you need to have so the supplier name Who is supplying you the component now? I want to separate out the supplier of the of the Of the of the S-bomb itself from the supplier of the component that the S-bomb describes So the supplier is a supplier of the component that's being described by the S-bomb then of course you want to know the name of the Component it's important to know the version because it got to be very specific and this one the other unique identifiers This is if you've heard of package URLs or CVE's there's lots of ways to identify it This is critically important for being able to correlate it to databases like vulnerability databases and satisfy the security use cases I Would encourage you to use as many identifiers as you can find because One database might you know recognize a CVE another may recognize a pearl if you put both those in the S-bomb You stand a much better chance of being able to find your vulnerabilities Dependency relationships you need to know what are the dependent packages and how they're related And then you have the author of the S-bomb data itself and then when was the S-bomb created? So basically being able to track information about the S-bomb now Jeff and I would like to recommend a couple of additional fields beyond the Minimum one is some way of verifying the component a hash or some Mechanism to be able to know that you can you can look at your component and say yes That's the same thing that's described in the S-bomb Download location Where did they actually get it from again? That's helpful to be able to go in and verify that it's the right thing and then license information so beyond the Identification of the package. What is the license communicating that can be really really helpful to your downstream users? so I'm going to go in and give a little demo of Exactly what's in an S-bomb and I'm just going to do a minimum desk the S-bomb this here is just the Structure you'll see this in the code in just a minute But at the very top is the creation information about the document the package information file information in the relationships So with that I'm just going to switch over Well, well Gary switching. I want to mention we will be posting these slides on the sketch website after the talk So you guys can go there and download them. I noticed people taking a few snapshots. There's a reason that you've seen these These tables again and again and again in all the sessions here at open-source summits because they come from the NTIA and So it is the government specification and that's why that's why we're all talking about it. Yep. Good. All right So here here's this is a complete S-bomb. This is all you need to do to satisfy the minimum as 38 lines Question yeah, sorry Let's oh, can we make the font a little bigger? I'll see if it's not as easy as you would think but I will try to do that quickly Let's see And it's a few clicks away. Give me just a second. I'm almost there It's Eclipse. There's a lot of options Okay, see that's 12 let's try bumping it up one there. How's that? oops, I Just got to get rid of the dialogue and then we're back. Oh, right So we mentioned the the document information That's this part of it right here, and I'm just going to go through what all these different fields are It's a little hard to drag well without my mouse. There we go The first thing the spdx ID that's just the identity by the way I'm going to be using spdx JSON as the example because I know spdx the best being part of that community JSON is probably if it isn't already it is quickly becoming the most popular format that's being used for spdx So and this was all hand written by me So it's not really that hard to to build one of these things just and we will be posting these Samples on github as well right so you can go take a look at the examples later So in the creation information we have an identifier for the for the document itself, and that's just a it's always spdx That's document. It's important to know what the version of the spec is so that you can validate against it So we got the spdx version, and then here's the creation information This is the author of the sbomb that NTIA minimum requirements So you got the timestamp, and you can see it was created by me The name of the sbomb itself, so it's not the name of the package or the component It's the name of the sbomb We also like to communicate the license of the sbomb itself, so that's the data license That's the license of the sbomb So if you're giving it to somebody else, they can quickly see what it's licensed under license of the data And then this document namespace is a unique identifier so that if you get an spdx document You can look at this and make sure that that's exactly the one that you're looking for So if you're referencing an spdx document someplace else, you can use this as a globally unique guaranteed unique identifier So that's the pack. That's the the information about the sbomb itself And then on the packages Information here, so this is the information about the component and It's got an ID the ID just has to be unique within the within the spdx document It's got a name again one of the minimum requirements the supplier one of the minimum requirements who supplied it in this case I'm using as an example one of the tools that I maintain which is the Java tools within spdx So the organization that supplies it is spdx a little confusing because it's an spdx document Don't be confused by that. That's also just happens to be the supplier here The package file name, which is the file name That's actually downloaded and then this is the verification information I mentioned that would be useful as additional information So that's the checksum of the package itself the download location where I got it from and then these external rafts These are the other identifiers that we can use to correlate to the databases so in this case I used a package URL and then there's one other key piece of information that we need which is There's the package, but in many cases you have a document that has hundreds or thousands or even tens of thousands of packages What's the top? What's the root of the sbomb that I'm interested in? So we need a way to say this document is describing this package and we do that through relationships So the relationship here just says that the spdx ref document Describes the spdx package and that's all we need and you know now that we have this we can actually just go into the We can actually go into the online tool and just see if we if this actually does Validate and Sorry, I thought I had this at the right location. So we have this online tool Which is which you can get to a tools.spdx.org and you can just drop the the sbomb into it And let's just do a we tell it as JSON Validate and We see that it's valid now It's a valid spdx document, but it is it doesn't meet the minimum requirements There's another little feature on the tool here, which is the NTI a conformance checker and this will actually go through every one of the different Packages that are described and check every one of them to make sure they meet the the minimum requirements. So if we do that Greg that over and That's valid. So That's it there there you have a minimum sbomb So if you're a maintainer of an open-source package, that's all you need to do if you do that a lot of us will be happy because now We got high fidelity information that we can bring into our project So when we send downstream, you know Information we can include the information that you wanted in the sbomb very precisely and very accurately That's all you need to do But you can do more which we'll be getting into next Let's see here and let me just mention that while Gary wrote this sbomb by hand just typing it in to Demonstrate how simple it is typically you'll be using tools Of course, you've got a large software system with hundreds or thousands of components You're going to use tools and we'll talk about those too and there are tools available to generate your sbombs so a Number of you have seen this diagram before this is the software lifecycle again. This comes from the NTI a I did not write this myself and This is not to demonstrate the complexity of sbombs This is to demonstrate the complexity of software lifecycle so there are many phases in the software lifecycle and The main point that I want to make here is people think well, when do I use an sbomb or more importantly? When do I generate an sbomb and the reality is any Single any anywhere on this software lifecycle is a is a is a valid place to use or generate your sbomb So I want to talk a little bit about internal versus external use a Lot of people think okay. I want an sbomb So that I'm writing an open source package or component and I want to generate an sbomb to help my downstream users First of all, thank you. That's what we want you to do a lot of people think okay I want an internal sbomb because I am a corporate enterprise and I want to track vulnerabilities I want to make sure that I'm you know up up on license compliance That is an extremely common use case Both are important if you want to generate one sbomb Great if you need to generate an internal one and you don't want to share that information with anybody outside your organization for Confidentiality proprietary reasons. That's fine. Just be sure you're generating an external sbomb For anybody that's consuming consuming your software So the generation itself as I said that you can generate an sbomb just about anywhere on the software lifecycle Two of the more common times to generate an sbomb are during development When you are writing all of your source code There are lots of tools out there the the SCA tools that scan source code repositories and They will generate an sbomb based on all of your source code There are also tools out there that are See ICD tools that you run when you're doing your build that will generate Sbombs based on your build. We'll talk about that a little bit more Doing it during the build is usually a great time to do it It's important to know that you know sometimes, you know Hopefully someday everybody will be generating sbombs And you will never need to generate an sbomb for somebody else's software because they will do it themselves for you That's ideal and then you'll just be a consumer You'll generate your own sbomb for your own software that you're that you are writing and you will make use of The sbombs that everybody else gives you follow the components that you're that you're getting from everywhere else But I Unfortunately, that's not the way it is today so there are times when you need to generate an sbomb for things that you receive that don't have them and That can be tricky I believe you're up. Yeah, I think there's one slide. Did we miss something? Okay So I wanted to talk a little bit about the yeah, I think we're missing a slide there But that's okay. I can wave my hands a little to make up for it. The let's talk a little bit about the tooling It's actually my favorite topic. I love writing tools. I use tools and First thing I just wanted to mention is that the the bill as Jeff mentioned the build tools is the ideal place because it's got Visibility of all the code coming in and it's got visibility about what's being produced so it's the best place to be able to generate tooling and There's a few tools out there that can help Both in in SBDX and some of the other standards you'll find a lot of tooling that plugs right into the build environments That's there. So within the SBDX community. We have a maven if you're part of the Java maven community We've got a plug-in for that. We got a plug-in for gradle. That's just about out SIFT has a get hub action and a tool that's out there for generating that and we have an sbomb generator that the SBDX community supports that covers a lot of different build environments as well So that's the ideal place to be able to put it But what do you do if you get software that doesn't have an sbomb now now? It gets a little bit more challenging because you got to dig into the code and try to find out what's going on So we're we kind of break the tools down into three different areas There's tools that look at the build metadata. So these aren't the build tools You're not doing it at build time. You're doing it afterwards But perhaps the the code that you're bringing in has some of those build artifacts the maven POM files the gradle files You know the the python build files or make files see make files whatever they are There's a lot of tools out there that'll look at that build that data and what they're really good for is finding the Dependency information that's there. They're not so good at looking at the source files typically But but they're very very useful and typically pretty easy to run and reasonably accurate then there's Scanners that look at at the file level and search for strings most of these are used for doing license analysis They don't typically identify the actual packages and package versions But for doing the license portion of sbombs actually do a pretty good job And there's a few good tools out there for doing that and then this last section is what we're calling the source snippet scanner So these are tools that actually inventory a huge database of available known open source files and Can actually look at the code that you know the inspect the code that you're bringing in Compare it to their database, and they'll try to tell you Exactly what version and what package and so from that you can actually pick up some of the other important metadata And be able to bring that into the sbomb the problem with these snippet scanners is there's a bunch of false positives So in some cases, you know, you might get two or three hundred possible Matches because not only is it finding the actual code that that it actually is but it's finding the code in other Dependencies and you know it's imported into other projects So these typically require a human to be able to go in and look at the results to find out exactly which one it is By the way, I heard a talk earlier that said it's impossible to find what the root verse. That's not impossible That's what I do for my day job is I can look in fact. I've done this so much I can look at like a list of three these three hundred day Oh, I know what that is, you know, I've done this so many times So it is possible to do it, but it's it's it does require humans So a little bit more involved a little bit more expensive. So this is just a few examples, you know within our community the Open source review toolkit or tea is something that looks at some of the build metadata The open s-bomb generator sift sneak there's there's quite a few others And if if you have a favorite tool that does this it's not up here. My apologies I'm just giving you just a few examples us out there Source license scanner. There's a number of open source tools that are out there Phosology is probably the original one written many years ago Scan code toolkit is another one that's widely used and then the source snippet scanner most of these not all But most of these are actually commercial tools because it does take quite a bit to be able to scan and maintain a large database So there's a few examples of that So it's also worth noting about the tools that today These tools are excellent both the commercial and open source tools but in my experience most of these tools are really good at One of the one or two of these things, but not all of them I think that we're still waiting for some of the tools to be good at doing everything and A perfect example of that is source versus dependencies. You hear people talking about scanning source code for license compliance For vulnerabilities Scanning no, I won't get into the details But you know you can scan source code for for actual vulnerabilities in your code Which is different than scanning dependencies for known vulnerabilities the source scanners that check for vulnerabilities are If they're sophisticated enough, they're actually finding flaws in your known or your common flaws in your source code But these are not CVE's that are already out there in the database So we scan source code We scan dependencies for all of your third-party dependencies all you know is as deep as you can go in your dependency tree The point I want to make here is that to get a complete for an S-bomb to get a complete picture of What is in your system? You really need both so just doing source or just doing dependencies isn't good enough Because let's face it engineers copy and paste source code and they plop that source code into their repository So you've got third-party components in your source code repository that you're compiling Linking building into your packages, and then you've got binaries libraries artifacts, etc So to get a really complete S-bomb you need both So let's talk a little about how this relates back to S-bombs So you've scanned your source you capture that you want to include that in the S-bomb itself. So how does that actually work? I'm just going to go back and give you a quick example of that and Switch over to an S-bomb with source So it has the same package information we had before so I'm not going to go through that Basically what we do is we just add in a file section So every file that you identify by the way these can get quite large You know you can imagine with a lot of source files, but each one has an ID again It's unique within the document you have a check sum for it so you can do the validation on it And then and then the name of the file and that's basically it now There's a couple other things that we need to do we need to be able to tie the source file to the package It does no good to know that these source files are laying out there You really want to know these first files belong to the package. So again, we go back to the relationship. We have the We we still have the spdx document relationship from before but now we have the s the spdx package Contains the spdx file and that's how we do that now There's one other thing I'll just point out briefly is within the package sometimes It's really convenient to be able to know that that you'd be able to validate all of these files really came from You know that that package that the contains is really right so we got a little Algorithm of doing checksums as checksums essentially to generate this thing called a package verification code and You can add that into the package if you like the package metadata and basically what that lets you do is if you if you Calculate this based on the source files you have you get one number you look in the s-bomb. Oh, it's the same number Okay, it's valid. I can move on saves a little bit of time So I think the the next thing I wanted to do is talk a little bit about the dependencies So now we collected these dependencies. How does the dependencies look within the spdx or or? S-bomb files, so so if we go back to the packages, it's pretty straightforward We already went through what the packages look like so we're just adding another package now I got to give you a little bit of a caveat and you'll understand why in a second. This is made up spdx tools the thing that I maintain does not contain this component And you'll know why this is important in just a minute But I just I just threw that in there as an example of a dependency So it's got some of the same information from before and again We go back to the relationships and we're going to say that The the package that this s-bomb is describing is Dynamically linked to this spdx ref now one thing we can do now that we have this information with the metadata and by the way I have the package URL of this as well of the of the dependent package we can actually go in and start running running this against some tools and There's a tool that that we worked out called the spdx to osv and it basically just takes an s-bomb and It goes and queries the open source vulnerability database I believe Google maintains that and and generates an output, so I'm just going to run that quickly This is my one dependent on the on the internet, so I'm always a little nervous about this part of the demo It looks like it worked. Okay now if I if I just take a look at it It's like oh dear Something came back if there's no vulnerabilities. It's an empty file. That's a good thing But oh my looks like that dependent package has some kind of a vulnerability in it So so now we know we got something to worry about So this is just a little bit of a demonstration on the security side of it of the usefulness of being able to collect those external references and the dependent relationships And let me go back to the presentation So talking about security You know, this is one of the most important use cases. It's out there You know we I've already talked about how we use it to correlate with a vulnerability databases the more external references the batter I've said that three times I'm going to say it three more times because I think it's the most important thing to keep in mind if you're generating s-bombs Use those external references and I just wanted to point out You know if you're if you're interested in other security use cases We got a really nice how-to guide. That's actually part of our specifications So now I just want to give an example of so We found a vulnerability. What if you want to communicate that to your downstream users? Which is kind of convenient to include in the in the spdx file I'll just show you how that's done and by the way, these are all spdx 2.3 Versions so this is all using the the current spec that's out there So we talked about these external references, you know the package URLs and that we have a category of external references called security And we have a number of different types of security Information that you can actually include in this so basically what we do is just add another external reference We say that it's a security type and in this case I just took the the CVE that that came out of the OSP and just included that in the s-bomb now when your Customers get your s-bomb your users or downstream users They can look that up and know that that vulnerability is there in 3.0 by the way we're really extending that and There's a lot of work. I see it all over there being done on VEX which actually lets you describe whether your software is actually vulnerable or not or whether you're impacted or not by these Vulnerability just to be quite useful So the other really common use case for s-bombs that we've talked about a few times is licenses a License can apply to a code snippet, which is a Fragment like a cop you copy and pasted something from somewhere It can apply to a single source file an entire library or everything in an entire container so Licensing is is complex and we're not going to go into details about licensing, but it's important to know That you need license information To make sure that you're not risking your your your intellectual property so what we want to point out here is that the spdx spec in particular has two different Classifications of licenses for the packages and components in your s-bomb. There is the declared license Which is sometimes? People talk about it as the detected license that is specified by the author of the package So that is whoever whoever provides that package or component to you says This is the license often these are found by scanning tools and then there is the concluded license The concluded license is the license that the person or tool the author of the s-bomb itself Says I'm using these components and this is the license that I believe applies to this component in the s-bomb that I just generated Now why are these different? Well, usually they're the same usually they aren't different, but the important thing is Sometimes a component probably a simplest use case is you get you get jQuery From out from the it from out there on the internet and you're using it in your system And jQuery is dual licensed under MIT or GPL and you say oh, I'm gonna choose the MIT license So the declared license might be MIT or GPL and your concluded license is MIT because I choose to use it under MIT So that's just one example, but they're typically the same but they can be different And I just want to make a plug here for spdx license identifiers. These are not in the s-bomb These are in your code, but they're used by tools to make sure that the licensing information in your s-bomb is accurate So these spdx license identifiers are machine readable Please put them in all of your source code every single source file every file header and Your s-bombs and everyone else's will be much more accurate when it comes to license data So now let's see what licenses look like in s-bombs So going back to the whoops, I think I missed it. There we go Going back to the and this will be my last detail. You're probably getting tired of seeing these these very detailed ones But this will be your last one So there's there's these that the concluded and declared licenses apply to both at the package level and at the file level So within the package The package information. I think I got to scroll down a little here You'll see these new fields. There's your license concluded and the license declared That that Jeff just just described. There's also a little bit of a shorthand little convenience field license information and file many times When you're you know when you're going through a compliance process They'll want to know what are all the licenses that you found in the files themselves as an extra check So you can actually put those into a nice little array or list there and include that in the package and then in the files We see the same information of the license concluded and the declared license is called license info and files in here as well But that's the that's actually the declared license. That's there So that's pretty much it as far as the is first passing along the license information within the within the document Let me switch back to the presentation So so that's it. That's it. That's the last example I appreciate you guys listening through all the all the gory details But I'm hoping that by going through the details you can see that it's really not that hard You don't have to have lots and lots of fields to build an effective s-bomb. That'll help your downstream consumers In terms of what's next we're very busy on spdx 3.0 We're we're doing we're building some additional what we're calling profiles for the actual, you know being able to track the providence of the actual build of the software and Also another profile for how the software is actually used and and that's important in areas like safety Where you want to be able to communicate The software is only valid until this particular date after that date. It's no longer supported. So you should upgrade so Information like that. I think one of the most interesting ones is the s-bomb for AI There is just so much going on in that field and the team has done I think just a great job of capturing what kind of information should be communicated about AI and And when you get into AI, of course, there's a lot of data that's associated with AI So we have a profile specific to the data that's available as well And then the the other area that we're working on we just spun up a group to look at the s-bombs for software as a service So this is being able to represent service information So if you're going out on the internet to acquire a service, what would be the s-bomb equivalent although s-bomb in this case Maybe service bill of materials as opposed to software. So That's the future. So, you know, where do we go from here? first start using s-bombs today and and if you're if you're Getting s-bombs from your customers. Don't just put them on the desk actually use it to find vulnerabilities use it to validate that the license information and Also use it to make sure you actually got the software that they think they gave you as well So there's a lot of uses for s-bombs. You can have today ask for s-bombs from your suppliers You know, even if you're an open-source user ask for it for your from any of your dependencies that are there and join an s-bomb community Cisa spdx. We're a very open and welcoming society of Like-minded individuals. So you guys, you know, all of you are welcome to come join our community and Open SSF has an s-bomb everywhere program that would be glad to get some additional help So that's it. I think we have two minutes for questions. Yeah, so these are some additional resources the government specs Some of our spdx specs and and descriptions of tools that we showed you and more There's a great research report from our Linux Foundation research group on S-bombs and cybersecurity that I encourage everybody to take a look at as I said, we'll post these slides To the sketch website. So you Right after so that you guys don't have to worry about writing all this down now questions, please I saw you guys are working on spdx for software as a service Would that would blockchain fall under that or would you guys be adding a category for that? That's it doesn't fall under that blockchain currently. Oh, well, I shouldn't say it doesn't we don't know yet You know it could fall into it in future. We're just getting started But but but in terms of like you there's there's actually there was a proposal Five years ago to use a hyper ledger and blockchain for certifying s-bombs that mark easy put together I still think it's a very cool and great idea, but it never really took off I might have been a little ahead of its time, right, but but it's I like to follow up on that and It was too early Yes Yeah, it's very interesting stuff though. So one of the things that I think is a Is a concern is that in some cases we might have an implosion between all of the s-bombs for AI? cybersecurity and blockchain We're actually talking about adding metaverses and other You know simulation type environments that that produce massive amounts of data which thing can make massively smarter AI I think at some point, you know just the the hashes that are used to secure the s-bombs itself Can be under fire and we should start thinking about layers of post-quantum cryptography in here because I'm not gonna put you know any menacing vibes out there, but it's it'd be easy to overwrite And if there isn't a way of representing that my version of these s-bombs hasn't changed underneath in you know Three different minor revisions that nobody really paid attention to yeah. Yeah, I could see Something happening there, but I would definitely recommend blockchain s-bombs because I feel like a lot of the the science is missing behind The the reasons for putting some of these tools together, and I think specifically for AI This is probably your only defense for enforcing ethical Standards, so I I agree with everything you said I would welcome Contributions along those lines too. I think there's a lot of really interesting work that could be done there And and I think it's important as well other questions Back here Good question So you mentioned that there are tools going one way generating from source code the s-bombs and From make files and whatnot You are there any tools going the other way around where you define everything in s-bomb and then just generate the infrastructure for you Know the bills and stuff like that Yeah, I don't I don't have an answer but I don't I don't know of any personally Like a stop 360 or false lights they actually doing it's of this process in the other way around the important s-bombs there To actually catalog the entire project and produce the result in s-bombs with the other created data It's just this is born in in some way because normally companies has suppliers suppliers Don't provide to you the source code to be analyzed they provided the resulting s-bomb from their product So you need to some way catalog in your things So there tools mostly that least mostly open source that do this process right now It's not it's we are a bit far to be completely ready for that But it's pretty good that the latest worker for my side in the case is double 360 comes from Toshiba It's been measured right now So you can fully integrate an s-bomb coming outside and create the entire part of the project Yeah, and false light was another one. We saw a demo of yesterday I'll mention one that another one that is this really simple is There's a spdx converter tool that's in that online tool I was giving a demo of earlier you can convert it to a spreadsheet and that can be really useful because looking at Json Doesn't work for lawyers, but they love the spreadsheet. So that's another tool you can question in the back here It's interesting to see that you're looking at S-bombs for AI S-bombs for data It actually is very similar to an effort that's going on in the US Department of Defense called the extensible bill of materials Actually seems very similar. They're at talking about Data bombs and AI bombs and a lot of other types of things. I was wondering if you're aware of that. If not, there might be some synchronization there. Yeah, I do you know Karen? I'm not on the in those working group that I see Karen if you don't mind me picking on your Karen Yeah, let's maybe talk after this. Yeah, and then I'm certainly aware of the extensible bomb and you know, and you know, there's hardware bombs there's you know, and the fact that you know, there's there were earlier sessions here in Vancouver about you know the about those and About the fact that some bombs Can some components can be in multiple bombs, right? You could have things that that are shared between different types of bills of materials So, I mean we are certainly focusing on S-bombs is in software bills of materials, you know in in our discussion here But yes, of course, all of those are very important as well Other questions, maybe one more question anybody up here. Yep. Go ahead Here you go. Sorry. So more is this more about logistics. So if where should S-bombs be housed and if I find Some error in an S-bomb, how do I go about reporting it? Yes both good questions I'll take the easy one the second one first. That's why we have the creation information in the S-bomb So if there's an error, you know, you look up the creator of the S-bomb And it should have enough information that you can trace it back and contact them and let them know That that there's an error In their github have a specific place that for for S-bombs They're actually starting to put it so that you know somebody a consumer like myself knows immediately where to go to find And the S-bomb for that software. Yeah, and that that's that's the the more challenging one because you know We're I have a I have an opinion of where I think they should be stored Let's let's hear your opinion. I'll give you my opinion is there's already a place for the artifacts for the Packages are stored so MPM has a repository Maven has a repository just put the S-bomb right next to it So when I download the artifact I can download the S-bomb and if you do the verification Information that we recommend you can make sure you got the right stuff together, right? And then you know you can put check sums on the S-bomb to it all works great There's definitely other opinions that we should have like a massive Repository like maybe the Linux Foundation should should host a big massive repository where everybody can check in Yeah, yeah, so there's there's a there's a lot of different approaches to it Unfortunately, there was a lot of different approaches, so there's not one consistent approach. So very good question. Yeah Yeah, very related All right now we're already a little overtime, thank you very much everybody if there are more questions after come up and see Gary And I were outside. Thanks