 So next up on our list here is Nareef Patel and Schubert Karr from the LF. It's talking about auto-generating S-bombs for open source project written in any language written on any platform. So please take it away. All right. Hey, everyone. All right. We'll try to keep the slides at minimum and show you some actual code. So, you know, most of you I'm assuming are familiar with the SBBX format and as the language or kind of the protocol of defining, you know, software packages. What we have done is we have essentially created an automated tool. It's called the S-bomb generator. It essentially generates you a software build-off materials for your open source project. So if you move on to the next slide. Yeah. So what does it actually do? Right? So, you know, we'll go into details of SBBX. I'll put in some links in the presentation as well. But net-net, right? Currently we support SBBX format 2.2 and, you know, we'll wait for the next version of SBBX that comes out. So the tooling will support that format. The key focus here was productivity. You know, generally the spec is great, but how do I actually generate a consumable SBBX document, which adheres to and, you know, validates and processes all the parameters. Most of them which are required and some parameters might be like mandatory fields that are, you know, defined by the spec itself. So that's what the tool delivers for you. We created a simple, you know, CLI-based interface. This tool is very early so that, you know, just wanted to make sure this is like just a better stage. And we got this tool written in time where there was the Biden executive order coming in. And, you know, everybody was scrambling for, like, you know, how do we define S-bombs in a digital way? And like, even if there is a spec, how is there an implementation of that? So we put this tool together pretty quickly and now the community is growing. We wrote the tool in Golang. You know, we're going to show you how that it's structured. It's portable in the sense of, you know, we tested it to run on, you know, Mac, Linux, Windows, different versions of it. It has, you know, we had two options, right? We could write like S-bomb generators in a particular language, let's say Python or like, you know, write the same implementation in Go or write the same implementation in Node versus what we took as a generator approach. So, you know, the CLI itself is written in Golang and it's portable, but more than that, it's really the generators that do the magic. And so these are the ones that we currently support. Now, a nuance here, you need to be watchful of is it's not just the language, it's the language and package manager combination, right? So as an example, we started with Java, but out of the box, the first one we worked was Maven Central or essentially, you know, that's the language package manager combo. We did not support out of the box Java Gradle. However, once we put the first release out, we started getting full requests from people in the community to support, you know, Java Gradle combo as well, right? So this is the current stage that we have. We also built in a, you know, a GitHub action, you know, developer tooling is great, but like, unless you actually integrate it with your CI pipeline, it's not very efficient. So we put out some examples with GitHub actions, you know, you can write other, if you're not using GitHub as an, for example, you are other tooling, you know, there are different ways you can write like pipelines for Jenkins and whatnot to integrate it into the CI stream, right? It's open source, obviously, you know, at the LF. License Apache 2.0, there is no CLA, you know, we distribute this under a DCO. It's better and it's growing, right? So that's kind of at the very top level snapshot. What it really does it, it does not go, you know, like, if you look at SVDX, you know, there are three primary, you know, I would say use cases, right? One is more about licensing. There's a license list about, I think roughly like 200 to 300, you know, licenses and like exceptions are documented there. This does not do that, right? What it does, it leverages that core information. But that being said, this tool is totally focused on generation of docs, right? So what does a SVDX doc contain as of today? So if you move to the next slide, yeah, so it's a very high level description, you know, we can send you more information about this or you can read up on the SVDX website. It's a standard format, you know, you're communicating the components, the licenses, copyrights that are associated within a software package. But when you talk about a software package, software is written in a sandwich. You have n number of packages and dependencies, you know, transitive dependencies. And I say like, you know, you compile from a source code, but there could be like runtime dependencies. So how do you, you know, make sure that those relationships are also part of your description, right? So, you know, we look at this into a seven layer format, right? So obviously you have fields which just describe what is used for documentation creation, versioning and all that. But when you run this tool against a particular open source project, you could be using 90% of your code base might be using third party packages, right? So how do you define those packages? What are the individual file level information, right? So if I look at file information, it could contain copyrights, it could be a license of the file, it could be checksum for the file. If you look at snippet, you know, how do you define licensing within, for ranges within those files, right? Obviously, you know, there are other licensing information, which is, you know, it describes licenses, those are not on the standard SPDX list, right? Those, I think they were probably, if I have to get that number right, I think they are like probably around 300. Those are predefined in those license lists, right? So this is like anything that's missing from that. And obviously annotations, right? So these are essentially comments that people made on various entities or elements within the document, right? So you might be reviewing it and, you know, you might make an annotation about a file or its particular license, right? So, and again, these comments or annotations might be to convey specific info, right? Like about creation dates or additional attached files or packages and things like that. Okay. So today, you know, like by default, SPDX, you know, if you look at the format, you know, there is a tag value format for input output, there is a RDF format. Today we, the tool supports the default dot SPDX. JSON and RDF, it's still in progress. We would love to have like more community contribution around that. So that's what the tool generates today. If you move on, next slide please. So I'm not going to bore you folks with all these different fields. But again, if you look at these, these are essentially what the tool is consuming in terms of required fields. Most of the fields are required, probably with a couple that are optional. And again, these are information around document creation. If you go to the next page, these are ones around package info, right? And then, obviously, there are other information around licensing and, you know, file information. And if you look at the file, that's where we go into the individual file breakdown. And go to the next slide, please. And these are ones again, around additional licensing info, which are not out-of-box covered by the default SPDX license list. So you can read that at your pleasure. But let's move on to the next slide. Yeah, this is about like how the tool actually works, right? So those 16, 17 parameters I listed, you know, those are the parameters that we validate and process in order for us to generate your SBOM document, which confirms through the SPDX format, right? But how does the tool work internally? So I have neither one on my team, if you can go neither into deep dive into this piece. Yeah, yeah, thank you, Shubhara. Hello, everyone. So yeah, this is the overall architecture of how this tooling is working. So I will go with the developer workflow. And then I will also show the end user, how it's going to download from the GitHub, and then how you're actually going to run it. So you always start as a developer from your, let's say, your developer, you're working on one of the repositories where you want to generate a SPOM for that project. So you basically download the URL on your terminal. And let's say you want to run it for express.js. It's a Node.js project and you want to run it. What it does internally, it runs the CLI, it validates the package, package or outside manifest file. So for example, if you're working on Node.js project, let's say the tool chain it's using is NPM or YAN. So if it is using NPM, then it will look for the package.json file. So it does the validation and all that stuff at the validation stage. Once it find it, there is a generator. What generator does it, it automatically looks up. So if the project is a Node.js, it recognizes that it's using NPM as a tool, it automatically does the dynamic lookup from the list of available plugins. So like Shubhra has explained, we have a bunch of plugins that we are supporting for this SPOM. So for example, on this one, it knows that it's using NPM, then it will take it from the NPM and it will run against it. So it will do the lookup, run it against NPM. It will use NPM APIs using the local machine terminals and it will return the results. So the results would be document package and the dependency of the package and dependency of the dependency. So that will return back to the generator. Generator pushed that data in order to build the data set for the SVDX compatibility. So once it generates that SVDX, based on the user requirements. So in this case, we are only supporting dot SVDX, but you can have like multiple file format. Once it's available, you can export it in multiple file format and it will generate that one file. So you can do that for each project or each language that you are supporting. We are supporting like these, we are supporting more language than this, but this is just an overview of it. However, there is another thing that we are working on it is sometimes what happens is developer may not want to use the direct APIs. They might want to say, okay, I want to work on something that I want to provide a data and you generate SVDX accordingly. So current version, what we are doing it is we are getting the data, which is the dependency of the dependency, everything using these APIs. But there is also use case, especially in Java Maven, where end user may be interested is like, okay, I'm going to provide you this file and you generate for us. So that is the part of the one you see in this color that's in the roadmap that we want to support it. So let's say this is the Maven file or Maven plugin, which has all the data. So it's going to recognize automatically during the runtime and it's going to get the data. So I'm going to show demo now. Yeah, before you go there, I think there's a quick question. Don't see. Yeah, I can read it out. Can you clarify how you build a dependency graph? Do you execute the build tool itself or some kind of static analysis? Yes, yes. So what we're doing it is we are actually, so for example, Golang, we are Golang has that go more has an option where we can see the graph. So we are using those API in order to get the dependency of the dependency, basically the graph. So we are doing that for each CLI or I would say each package manager CLI. That's how we have been doing it. Go over the code. Okay, so here's the public repository. And I've already downloaded the latest release, which is what we have released like a couple of days ago, which is 0.013. I'm going to download this CLI, which I've already done, and I'm going to run against the tool itself. So let's suppose that I'm a someone who is using the CLI and I want to run against this project. So I have this project locally clone. It's already over there. Now, I want to generate a SBOM for it. So what I'll do it is do that. And I have this is my CLI binary that I've downloaded. I'm going to run it. It's going to detect is okay, what what's like package management system it is. So in this case, it's a go more. And it also going to tell like what language wasn't it using. So if I look at four version, it's going to tell me go worse than 1.7. So CLI also tells you that, okay, you're using go more. It is a go project and the version is this. And it's also going to after that, once it generated, it returns the successful message and it returns the output. So let's see if I look at it. So as you can see that we have generated this. So let me open this. So if I open this, okay, so it's going back to the that the table that she was explaining like document package relationship and the relationship of relationship, which in this case, the dependency of dependency. So the first block, which is the document where of course we're saying it's supporting version 2.0 data license, some sort of ID created namespace and all that. So this is the document. And then we have a package information. So which is the package itself. So here, interesting thing is if I look at here, and again, this may be a familiarity if you are like having like a goal and background, but the idea here is that this is the name of the package, which using these are the, you know, dependency. So if I go to this, spdx, you can see the package information. So in this case, it's spdx. And it has all the information. I'm not going to go in the detail. But if you look at this part relationship, we can see that spdx depends on cobra depends on these are the dependency, which are coming nothing but the score more file. And this, this file has their own dependency, which is what listed at the bottom. So it's, that's why you see the document is so huge. So that's how we're doing it. But like say the current approach using the existing package management system. So in this case, go more for the go project for Node.js, it's npm and yarn and many others. So this is a one demo for the go project. Let's say I have a situation when I have a multiple package management system part of the same project. So in this case, if I do that, this is my another Node.js project where I'm using a multiple package management system. So as you can see, I'm using a yarn and there should be one more for the yeah, right here for the npm. So these both are the lock file, which are generated when I've actually built the project. So if I run it again for the tool, by the way, like I have kind of copied the binary here already. So if I run it again, again, it says, I'm gonna run, I recognize that you have a npm. So it's based on this file. It, it's telling me that you're using 6.2.0 npm version. It generated now it's going to the yarn because it also recognize that you're using yarn and you're using 1.15.2 for the yarn project or yarn build. And then, okay, it successfully generated that as well. And it also telling me that we have created two files underneath. These are the names. So if I go there and if I just, okay, we can see that it's a similar structure like you won't see any difference between whether you generate for Node.js or you generate for Golang. SVDX is the same for everyone. The only difference would be some of the naming part of it. But yeah, it's again document what's the package and the relationship of it. So that's kind of high level on like how to use the tool and we kind of seen for the go and node as well. Now I'm going to look before I go to GitHub actions. Yes, yes, we are using go more to get those information. Yeah, that's right. All right. So now I'm going to show you a couple of other things what we're doing it is we have added a GitHub action as well as a part of a workflow. This is something still it's under my profile, but I can go over what it does it is actually building the binary of it and then it executing that binary against the project itself. So in this case, against the SVDX and we have returned the one test and what it does it basically the step generates the SVDX file or a small file, and then it validates whether it generated successfully or not. So that's what this action is doing it and have one example of each thing I did last night. You can see there's a two step one is a generated a small file, we can see all the steps. And here's where it's generating it. It got the binary or I would say action and here was the step. It ran and it was success. So this is one of the like a GitHub action that we have written. It's also part of it. So we're working to move it from my profile to this one, but yeah, this is very good. So yeah, that's the overall demo I had. Shubra. Yeah, thank you, Nira. If you can go back to our slides. Yeah, so brand new project, right? Both Nira when I work in Linux Foundation Engineering and we did this to solve quickly for the community. We are looking for more contributors, maintainers as well. So and we are getting quite a few in the recently. There are links to understand the architecture. There's a contribution guide. It's under DCO. So don't need to worry about CLA's or whatnot. We'll be publishing on that page. We are standing up a discourse and a link and we'll set up a governance structure more like a technical steering committee as any other Linux Foundation open source project and go from there. So we're really looking for help and adoption and around other combinations of package managers, languages, build systems and whatnot. But this is one initiative we are doing which can actually move the needle in terms of defining the entire software buildup materials. So that's it. I think we have a few more minutes for any questions if there are any. I believe there are. So why don't you take a peek and leave them. Can we go through this list? I think we have answered a few. A number in the Q&A are actually for the previous speakers I think. But the chat had some questions or discussions. Yeah, I can go over with that package.json and yarn. Yeah, that's completely right. That log file may get out of date. That's right. But the idea here is that you will not be doing this automatically. Sorry, you will not be doing this every time manually. We're hoping that you'll be doing some, like you'll be running the CLI from the CI and hoping that you will always have an up to date log file even in the CI as well. And if you're happy with your log file then that is what you're pushing out. So the idea here is that it's more around the CI automation and it's really based on what dependency going into the production. So if your log file is let's say in x state that will be go to the production. So I think I would say on that one. And that one I already answered. Why did you build a new tool not reuse existing? Yes, yes. So the reason we had to build this tool was more around we wanted to get like the one thing mentioned like having a single language that we wanted to add a support around it. We didn't want to create multiple modules. I know OSS review toolkit does the same thing. But it's very similar to that. But what we wanted to do it was more aligned with having a more like a goal lang and that's where our expertise where. And we wanted to utilize some of the built-in package management APIs. That was one of the reasons we have taken this route. But that was one thought we recognized that, okay, how about if we can integrate with the OSS review toolkit. So yeah, that's a good feedback. Commercial availability date. Subra, you want to take this? Yeah, yeah. So Linux Foundation doesn't sell any products commercially. I think the more question is when is like a production or a GA date. I would say right now this is 2.2. We I think 3.0 will be a big change for us. So we will keep this in beta and we are growing a list of contributors and maintainers, right? But we'll probably like to call it a GA once we support 3.0, which might be a few months out, right? But that being said, today we already have users were using this very successfully against the 2.2 version of SPDX. Okay. If that answers your question. But yeah, like we don't sell it. We don't license it. It's all open source. We do license it. It's under an open. It's not a commercial license. It's let me not a closed source license. Yeah. So Gary, I wanted to, yes, definitely we do support default values for SPDX properties. So yeah, like propose something that we want. But yeah, we'll definitely support it right now. We are doing it only for package and the document. We are not doing it for the dependency, but definitely we already have it in place. I think the accuracy one is an important one. I think that raises some broader questions. I think it's important. Yeah. So yeah, accuracy. I kind of agree on it as well. Right now we, there is a one effort that we were thinking to start on it is you generate the SPD like SBOM file and then what are the acceptance criteria, right? Like because this is a subjective, right? Like each product project has a different environment. There are n number of cases that we could be missing it. So there is a, there was a plan where we will do like some sort of a field level validation based on the dependency we have on the project itself. But yeah, there is in the roadmap where we want to automate that process that, okay, you generated the SB like SBOM file. Now, how about like, let's do the validation of it. Does it work? Like, does it exact? Like without any human validation? I think that's in the horizon on it. If you don't mind me jumping as well, I mean, it's garbage in, garbage out or no data in garbage out. You know, this particular one supports a number of package managers. If you don't use a package manager or your language ecosystem doesn't typically use a package manager, then it's not going to be able to use that data. So for example, a number of embedded environments, you know, if you, for most of your codes written in C and C++, well, you know, that's not supported in terms of package manager data inputs and such. So, you know, it doesn't mean you can't use an SBOM. It just means this may not be the right tool for your situation. And about overriding and unused. Yeah, sorry, we don't have it right now, but it's a good feature to add a kind of exclude type of thing. But right now, it's going to take it, whatever you have, part of your manifest file, it's going to take it as this. But yeah, that's a good feature to include it. Will that really, you know, like yards are moved and will come. Yeah. Yeah. Will that small generate generator produce SBDK small with a dock fast? Not so as long as that that project is returning our one of our supported language, then yeah, it will generate. I'm not sure what language it uses dock fast. But as long as it's, it's a part of a supported language, then yeah, it should be put in those. Okay. Yeah. Sounds good. Yeah, it looks like somebody already is using the SBDK small generator for the dock fast. All right. I think that was it from our side. Thank you. Okay. All right. Does anyone else any parting shots, by the way, overall? Okay. Thank you very, very much for that.