 Yes, hey Thomas, is that fine, check, check, check, check, check, will the recording be, will everyone else be heard in the recording, because it is a discussion, oh well, yes you will need the handheld mic, as usual, yeah, this is the corollary to Murphy's law, anything bad can happen, it happens to me, yeah, yeah, can't pre-record a discussion, but that's okay, I wanted to come here and I'm so happy to see everyone, it's been a long time, so whenever whenever they say go, we'll start, the what? Oh yeah, that was a long time ago, I don't remember much actually, I can tell you a story though, at the time when I was looking for a job, I couldn't find one and so for the, so I finally did this thing where I recorded my resume on a CD and then I had, I designed like a Smith chart front cover for the CD and printed it on the CD and that's what I gave out as my resume and just going like you know above and beyond, nobody will do these things, but I needed the job that badly, so okay, okay, sounds good, hi, this is going to be not a presentation, I'm just going to have these slides, I purposefully did not upload the slides, because I wanted input from you to figure out what we need to do next with regards to S1, so the objective for this buff is to first understand the tooling landscape and what I'm hoping we get as an outcome is a list of tools and what they do, we identify missing functionality based on what folks are using S-pumps for and next steps to fill in the gaps for that functionality and then objective two is to try and improve tool accuracy, we would like some common knowledge on where exactly do people store their metadata and where the tools are looking to find that metadata and I am just going to be editing the slides as we go, but that is by design, this is supposed to be like 45 minutes maybe, but it is just a starter, people can always like you know use this as their sounding board and complain about stuff and then we will find a place to slot that in and follow up with discussion later online next time we meet etc. We want to see what language ecosystems need the most help with generating that S-pump and then what tools we can create to help the language ecosystems. So, I am your facilitator, my name is Nisha Kumar, I am a security engineer at Oracle, I was previously at BMW, that is how I managed to get into the conference circuit. I poke my nose into communities like SPDX, OCI, that is open container initiative not Oracle cloud infrastructure, I have to keep those two acronyms in two separate places in my brain and they often cross. If anyone is at the NTIA or CISA S-bomb working groups they will find me there and various other S-bomb communities, I look like that purple cuttlefish on the internet. So, if you see that coming up on a zoom screen that is me, ask me later about why that is. Yay, the mic is on. Okay, I do not have to yell that much. Let us level set first. Why do we need S-bombs? I have started off with a few that come easy. First is the executive order which lots of people have already memorized that number. The other one is to find Log4j which my company has been struggling with as probably a lot of other companies. The third one is to find Libraska, I stole that from Julia Fioroli's presentation. So, and some people have actually memorized the XKCD about the infrastructure and the one guy in Nebraska who is maintaining it. So, the second and third one tells me like you know there is a search component with regards to S-bombs rather than us looking for these things we would like suppliers to just give it to us and make our lives easier. So, that is one generic thing. Anyone using S-bombs for anything else? Yes, Thomas. So, a lot of the security problems I looked at like the first question should be why the heck are we using this piece of open source in the first place? What are other teams are using? And if you have S-bombs you can just look like oh I know that our team in my company is doing something similar. Oh, let us look at our S-bombs. What are they using? Oh, they are using this other open source library. So, why don't we align the company to use the same open source license of open source packages and also add it we might also look at like using similar versions so that we basically can reduce the maintenance of it. So, we have to upgrade the new versions. So, this is literally what we did in my company. We had an SDK team, 10 different components, five different teams basically using the same open source. They complained about the compliance of the S-bombs and stuff. They said like well, why don't you just align on a common engineering stack and a common set of dependencies? Actually, that had a lot easier. I know it is not as sexy as security, but for me security is reactive. Let us do things pro-active and look at the engineering stack itself and start with upstream. So, a number of us who have worked in the compliance space really focus on hygiene. But I also understand that a lot of people have more pressing issues like cleaning up. Yes, go ahead. Yeah, I just came from another talk about S-bombs. Apply to the AI field where it allows for the traceability where there are not depending on I mean there could be multiple use cases but applying it to AI to get insight in the model and the data set and maybe up to the point where actually as an organization you're reporting on the usage of those AI algorithms. Is it for the algorithm or for the data set? And there they were talking about both the model and the training data set. And there's something going on already to model that within SPDX. So, I would say that falls under use case. That's another use case, but it seems to still be like a transparency thing. Trying to find something and evaluate whether we need it or not. Yeah, I agree. Is it good? Is it not good? So, yeah, anyone have any other wise? Well, basically integrity check. So, does integrity checking for artifacts mean that you have to have an S-bomb for the artifact? No, but it's a useful tool. Okay, how is that useful? So, for example, when you, when we, for example, we produce releases with lots of artifacts, like a bunch of binary source code, and we have tools to verify all of those to see if nothing's sort of there. Okay, so rather than hash each of the artifacts, you create an S-bomb of the artifact and check the integrity. It has a hash. Okay. So, it's like an integrity check for every release. Exactly. That's cool. I didn't think about that one. How do you pronounce your name? Nadav. Nadav, sorry. If you would like to do prioritization and risk management, you need the whole picture. So, this is one. And as far as I know, it's very important for legal agreements. I mean, often legal agreements say that if you have CVSS about this and that, and it's discovered, it must be fixed within seven days, 30 days, 90 days, depends on severity and other issues. Anyone else have ideas or what they're looking for S-bombs to do for them? How? Trademark Compliance. You're like compliance guy. I get a lot of the questions about what you can do. Basically, the question is always in our software stack, do we use software from country X? Actually, but it's actually also the other side. It's not only trademark compliance, we also get sample companies that do not want to use open source software from a competitor. Mm-hmm. So, it falls under risk management. Is anyone here just focusing on vulnerabilities and is not really that interested in like the general risk management hygiene picture? No, everyone's like, no, we know that's going to happen, but this thing is more important than this thing solves a whole lot of other problems other than the vulnerabilities. That's what the group understands. Okay, sounds like we're in agreement with that. Okay, so it's a pretty sophisticated group right now. Let's go through whether we have all our tools in place. One of the reasons why I didn't upload this to SCED is because I've been in a bunch of S-bomb talks and I've been curating the tools that everyone is talking about and what they do and what they're targeting. So, I have here a list of tools. Of course, turn is the first one because that's the one I know the most because I'm the maintainer. So, everyone knows these set of tools, right? Am I missing anything? You're missing a lot of tools and you need to make some corrections. Oh, go ahead. So, SIFT can do transform. Okay. And ORT can do consume to a certain level. You can define package managers that are not supported in SPDX and ORT will consume it. Only with 3.0 will fully support all of the things. How does SIFT transform? So, it's between SPDX to CyclonDX or to their internal format. And back then, I understood always transform was basically from one S-bomb format to the other. Okay. So, consume means consume S-bombs in any of the formats. There is the Microsoft S-bomb tool. Oh, yeah, that's right. And that just generates. So, I've listed only open source tools because our main goal over here is to figure out what tools the community as a whole can use. And so, there may be some features in the tools like SIFT and any of the other like trivia or something like that that may not be available in the community version. And I'm not really sure what features are available and what features are not available. Yes. Yeah, that would be my next question to ask about. Is it just the open source tools? In that case, I know of another tool, but I'm not even going to mention it. I think it's good to focus on the open source tools. Yeah, okay. I have a couple of open source tools in the trust source stack. They are for different package managers and they directly create S-bombs in the SPDX or Cyclone DX format. Okay. You find them all under GitHub slash trust source. Trust source, okay. Okay. Oops. Is it trust dash source? No. C-E-E. There we go. Great. And that just produces. They are designed to produce, yeah. Okay. But it's not. You can go, perhaps it's not the best practice, but you can go to the package managers and produce something which is akin to an S-bomb. Yeah. True. We'll talk about that. We'll talk about whether that's a good idea or not later. The bomb tool from package account. That's, sorry. I got it. Bomb tool, right? No, no. It's another one. That is S-bomb. Yeah, everything is bomb tool here. Okay. This is S-bomb tool. I know. I think I have it over here and it's like right at the bottom on this. I have it over here in this table. It's just not seen because I'm terrible at formatting. No, it's the Kubernetes bomb and the other is part of package account. Yeah. I'm just going to see like. Oh, so it's not physical. Yeah. That's what I meant. Okay. There. I'll remove it from there. Anyway, yeah, I got that one. Yeah, it's produces. Oh, it produces. Does it produce for anything in particular? C and C++ packages. That's cool. I think that's like the one ecosystem that doesn't really have a package manager. So things that use like make. If Zephyr, they have some S-bombs, but I have no idea how they produce it and whether they use some of these tools. Yeah. So I think that we should look at standalone tools that anyone can use rather than rely on a build system to generate it for us because there are some in for OS is there are tools that actually like build the whole OS and then the final part of it is generating the S-bomb. That's a lot of work for just like regular Joe developer to set up and run. So we're looking for things that they can set up on their workstation and run or put in a CI CD pipeline and run like a get up to actions kind of thing. Because the aim for this discussion is to figure out how we can make this as ubiquitous as possible. So we don't have to burden people when we say like, okay, give me an S-bomb. Where's your S-bomb? So, okay, does anyone have any other tools? I was going to mention Docker and Yocto, but since you just said that, I won't. We're missing the Cyclone DX standard tools. So like Cyclone DX, Nathan plugin, they have like 150 of them on the website. So this makes Cyclone DX star or something like that for all the Cyclone DX ones. And then the one which is called, is that something that, is that something like anyone can use? Like is set up, it does a number of things though, right? Not just produce S-bomb. It's, it's more full stack application almost with the UI and all that stuff. So it's not like a CLI thing that you can run by itself. Yeah. So You go back to the previous slide, it is one check if we have the whole list. Yeah, if I should this, I have a like, there's a, there's this webpage that has awesome S-bomb management, GitHub page, which actually lists a lot of them already. So I was just checking which one we have on the list. Why didn't you say so instead of me going through this? Yeah, but that's, that's all the compliance tools that are out there pretty much. There's not all the S-bomb tools. I'm very, very looking for just the S-bomb ones. So what's the name of the thing? Awesome S-bomb. Okay. Awesome. And then S-bomb all caps. That's basically, is that there's the list page that lists all of the, a lot of the S-bomb things. So it explains what an S-bomb is. It shows the tools. I think I thought of it and it captures blocks and videos and slides, podcasts about S-bomb everything is there. Okay. So let's look at this table. I think we have enough and figure out what functionality is missing because, you know, in the end we wanted, we have, we have several functions that we're looking to for S-bomb. We want to be able to find, find a certain package with a certain version. We want to be able to figure out what the risk of using a package is. We'd like to apply it to various use cases and integrity checks. So do we have tools that like identify S-bomb, like a package in an S-bomb or parse S-bombs? Yes. Bomb has a query, small query language, which you can feed it an S-bomb and query, for example, packages by PURL type or by name or it's simple right now, but I've been adding the use cases as I've been needing them. Okay. Can I do it for any bomb? Like any S-p-dx. Any S-p-dx. Okay. As long as it's well-formatted. So if it has a, yeah, if the syntax is not right, it will Okay. Let's assume for now that all of S-p-dx's conformance checkers are working. Okay. Assuming that all the S-p-dx's conformance checkers are perfect, then you should be able to The other is that it also lets you like visualize the structure of the S-bombs. So it'll show you a tree view of how packages and files are. I mean, it's a simplified view because as we know that the S-bomb is like a graph, not a tree, but they will use the first um the first relationship you find so build a tree view of what some things were. Can that functionality be separated from the bomb tool? I'm planning to spin it out to a library of its own but it's not there yet, but Maybe. Yeah, I mean we can work on that. Okay. Okay. Anyone else have ideas on what to use? One, often the names produced by different tools are not the same name for the same package. I don't know if it's a gaps in functionality, but often when you try to compare different tools, it's an issue. Yeah, that's the that's the accuracy bit. We'll get to that in just a little bit. To cause a bit of a mayhem and then we have a major issue. I think when we don't have proper metadata, proper package managers. So CCPP, it's a major issue, but also we have issues with the stuff that are brought in during not too great build processes, for example. I mean usually those, I mean usually software that does it works best when the build is great and the package managers are great and vice versa. What will you just pass the mic over there? So perhaps you just mentioned the standalone. I understood standalone in the sense of, okay, I'm a project and I need a tool, but perhaps we could also be more accurate here say, okay, is the use case rather an organization that needs to manage several build materials or what is the perspective from, for example, one open source project that needs an S-bomb tool, because then if we would distinguish here, I would also list software 360 because, but that is rather a hub, right, for S-bombs where you also want to map, different projects, who uses what and all this stuff, but I think that would be then another level. So what is the scope? Yeah, that's a good question and I should have put that at the level set thing. The scope here is just considering that there is a need to do it and everyone is in their own little silo. Each one may have different use cases either centralized or just have their developers generate an S-bomb for each one of their projects or have a team generate S-bombs for each release. Thinking about that rather than focus on a top-down approach, I'm trying to figure out a good way of doing a bottom-up approach. So something I can integrate in my build pipeline. Yes, something to integrate in your build pipeline. If your CISO or your legal person was like, we need S-bombs now, the team doesn't have to go scrambling around, you know, looking for tools and infrastructure. They can just be like, here you go. Yeah, but then perhaps we can also have here rather also some tax or something like, because a GraphView, I don't know. Yeah, so in the build pipeline, I just need to detect it and produce all processable output, right? And then I might have another tool for the UI or something like that. So it seems like we're pretty well covered with the producing bit, but we are missing we're missing all the other tools, which is like things that will read S-bombs and identify like whether your component has, whether your S-bomb has a certain component or like give me all of the licenses of all the components of your in that's in the S-bomb. So it seems to me and you can you can correct me if I'm wrong, because this is a discussion that we need tools to be able to parse the S-bombs and query them. I think there are a lot of them already there. Yeah, solutions that can do that, probably not all of them are open source or fully open source. But however, when we when we talk about what is missing, I think one of the very important things is since the S-bomb is always outside of what it is talking about, we need the relation in the S-bomb to whatever it's actually describing. And this must be something that is static or unmodifiable or something so that we can have a kind of certification mechanism that is allowing me to retrieve or verify whether the S-bomb that I have in hand is associated with my binary or whatever I'm consuming. And I think there's there's a cool solution that we have to take into consideration on them out now that's six store. And I think that especially on the production side, the the S-bomb produce production or production needs to make use of this. Yeah, yeah, yes. But what I would love to see if that is decentralized, because what my observation is, okay, we have the Python ecosystem, so we need to wrap around Python ecosystem to extract their bill of material about if they have a new idea, then we have to follow. Then we have the NPM ecosystem. If they have new ideas, we have to follow. And so Thomas is the best practice, best example. So we have so many things to do in the analyzer and so on to always run behind, right? And they have new ideas and then we have to add up. So if we could have incentives for those ecosystems, say, okay, could you please, if you do, have you have new ideas, how you structure your bills, whatever, if you if you develop your ecosystem, please also think about S-bomb, how we could consume that much easier instead of us thinking about re-engineering the stuff we get from you. Yeah, that's what I would love to see. I really liked that idea. And maybe to add incentive, like, have a public page like which languages are covered or easily work with S-bombs or maybe on the package level, like where we can report packages that produce incomplete S-bombs or are sort of broken to like naming and shaming the tools and the packages and hopefully encourage people to act on it. I think they've tried that before. I would also please prevent that, but I don't want to catch your words. Nisha, just to mention, we have like nine more minutes and I think you have one or two more topics. I think you've already jumped to that topic, which is the ecosystems. How do you define incomplete S-bomb? Because in the SPDX, there are there are fields that are required and this is the required minimum. So everything can be added or can be missing and how they define in this context the complete S-bomb. Maybe I was more trying to say incorrect S-bomb or like whole parts are missing, but completeness is a different topic. Yeah, I didn't want to raise that. Why is completeness different from accuracy? Because I have completeness in there under accuracy, but maybe you have a different perspective. I think he wants to say something behind it. Directly to your question. Yes, for sure. I mean, I can be complete but incorrect and accuracy I would say it's combining both. There was a talk on Tuesday about completeness and correctness. So first idea, I think that was a good start to look at this and I would add to, from the build systems perspective of the ecosystem, they are fine. Okay, we listed everything, but if you then want to look into it deeper, you'll find out, okay, well, but this is a black box, right? And so there should also be no black boxes anymore. It should really go to the source every time. So since we're on the topic of accuracy, most S-bomb tools, licensing, is a joke. It's literally all full of no assertions. It's all likely. I'm actually currently doing a project where I run a lot of these open source tools and I'm working on generating S-bombs for them every night in the Gate of Action so we can actually see the things. So the other thing that is kind of missing is actually, and I don't know if you had it in the previous slide half, is that actually the S-bomb standards can currently not capture the reality. So the standard itself is not capable of making an abstract of what is there. It's not capable of purely communicating what's there and what's not there. The reality in code cannot often be captured in an S-bomb. Or, well, actually, let's say, just reality cannot be captured in S-bomb. Because S-bombs cannot only be about codes. It can also be about applications. It can be about much more. So reality cannot be captured. Because again, I work on S-bomb. It's a very complex problem to take something reality and try to abstract it. And then the question is also the second thing is that we haven't agreed on how do we model it. So every tool currently, if you take one simple, say, MPM project with six dependencies, every tool that you run will make a different dependency graph or a different S-bomb. Even if the packages were exactly identical, even if they all agree on the package naming, just how the dependency tree should look like, how reality should be encoded into the S-bomb is not defined by any of the standards. Therefore, as a consumer, this is why I think consumers' tools are hindered. Because how am I supposed to consume this? So I can get the basic package information. But what is the relationship between the packages? Is this the test dependency of this other package? I cannot tell because basically every tool encodes it differently. Yeah. It's possible for me to consume. One of the gaps, I'm sorry, I'm using Perco. Dolpho has identified is that we don't have a common standard of how to express certain artifacts. Like what you said, one person decides like a dependency graph looks like this and another person says, no, it actually looks like this other thing. We have that problem with containers too. Because we started off early, all of us are thinking, oh, you open up a container and you see all these star balls. Each one of them is a layer. We'll call them a layer. But some people are like, no, that's an implementation detail. You shouldn't really be caring about that. You should only be caring about what's manifested at the topmost read-write layer. There are differences in opinions, but we haven't agreed on what these S-bombs for each of these artifacts should look like. But Adolfo is working on an initial set of semantics for each of those artifacts and hopefully that would... So I only have two more, one more minute here. But do you think it's worth getting together to talk about semantics and how one person names a library and how another person names a library and come up with... I think that it's a good thing to talk about this, but probably it's not about the naming convention alone. It's also about the meaning of what is the package or what is the component or what we have in the file. When we look into... I mean, SPDX is allowing us a lot, but when we receive inputs, then we get all and nothing. Sometimes everything is a component. And you know from the naming that it cannot be a component. It's a file. It's used in that area. And here we have no... That's probably a point to the accuracy or the guidance of how to use it. And depending upon what format you're using, the guidance is different. So it makes it more complicated. I don't want to be a spoiler, but what is a material? Because now with Cloud Assas call, if I have now all my components listed, in one component, I have a REST API call, I will never find that in my bill of material that I have a REST call to Assas or something like that. And the question is, is this just a list of physical material? That's BOM? Or is this also then the next level that we also have to have an idea of, okay, what's really happening? Yeah. So I have a... We should also check the FASAN project there. I have a point over here where... Do we really need an S-BOM for use case X? That's a topic that everyone is now talking about with Cloud. Does it really apply in this case? My opinion is... Well, my opinion is no, but we do need something else for that. Until the data privacy colleagues will come and say, hey, where is your data process? Yes, all the BOMs. So in electronics, there's something called a data sheet. I don't think software has any kind of understanding of what a data sheet is. A data sheet is not a BOM, it's kind of like a general information thing. Okay, I have to stop now. Is it a question time or we need to leave? Oh, at the end. Okay, well, we can... Thank you for coming.