 Thank you everyone for joining us for this talk. I hope you're already having some great time at Open Source Summit, meeting cool people and learning new stuff. My name is Velicica Tanasova. I'm an engineering manager in the Open Source Program Office of VMware. This is Ivana Tanasova. Ivana is one of the very talented Open Source engineers. I have the pleasure to work with. We are both very excited to have you here and to be composing the ultimate S-bomb together. This is how we are going to do it. We are going to walk you through some challenges and how we can overcome them. I promise it's not going to be just plain theory. We are going to have a demo, have a cool tool that we are currently working on to see how things are done in practice. Hopefully, at the end, we'll get some good questions. We welcome both questions to which we are able to answer and questions to which we are on. We won't be able to answer because this is how we all learn and this is how we all get better at what we do. So let's get to business. I want to show you something first. Although it might look a lot like an open star cluster, that's not a star cluster. It's not a complex subway system either like the one they have in New York City. It's not somebody's network of Facebook friends. As you might have already guessed, this is a dependency graph. A dependency graph of a real life project. Can you name the project? Can somebody name the project? I'll give you a hint. It's an open source project. It has something to do with supply chain security, with container signing and verification. Somebody? Six store, what? Six stores, what? Go sign, that's the right answer. We have a winner. You win a dinner tonight, 7.30 p.m. at Dinner Talkers. You can find your address here. Okay. Let's try, oops, sorry. Let's try with one more dependency graph, even more beautiful. Can somebody name the project? Open source platform for managing containerized the workloads and services. Very popular one. Kubernetes, you win the same price. We'll see you tonight. Okay. Those two beautiful dependency graphs greatly demonstrate the way we built software today. We focus on our unique innovation and we deal with common challenges leveraging existing solutions. And that's a fine software development approach. We don't have to reinvent the wheel every time. We focus on our unique innovation and our solutions are brought to life so much faster anticipating and meeting our users' expectations in a timely manner. And that is awesome. But every third-party dependency that we use comes with its dependencies and they come with their dependencies and so on and so on and we end up with tons of known and unknown dependencies. And that might get us into trouble one day. If I go back to the analogy with Facebook from earlier, my immediate friends come with their friends and they come with their friends and so on and so on. And we end up with tons of known and unknown connections and that might get us into trouble one day. In our Facebook time in this talk, let's go back to our modern software. How sick are you of this image already? We've seen it so many times, but yeah, somewhere there is that small project poorly or not maintained at all that is weighing under the complexity and the weight of the modern digital infrastructure. And yeah, those dependencies, they've been there forever. But we've started noticing them now in light of recent cyber attacks when we finally realized that we need to pay closer attention to the security of the software that we use. And to do so, we must know what software that's actually in use. To shift from a passive stance if we get hacked to a proactive mindset when we get hacked requires increased knowledge of all software assets. And improving the security posture demands a hard and software supply chain, one that explicitly declares all software components to help identify and mitigate risks before they become a crisis. And here comes the S-Bomb. A software built materials can help address these needs. An S-Bomb uniquely identifies a piece of software and its dependencies in a machine-readable format. And it helps organization by reduced cost, license compliance, and security risks. For example, an S-Bomb can help identify if there are known vulnerabilities, security vulnerabilities in some of our dependencies. It can help share provenance information and it can help gather relationships information for our dependencies. Or it can help identify if some there in the dependency tree there is some tiny dependency, yeah, dependency graph to be correct, there is some tiny dependency with an incompatible license that can get us into a real legal trouble. S-Bomb's potential to track known and newly emerged vulnerabilities is widely recognized. According to the Linux Foundation report on S-Bomb and cybersecurity readiness, 90% of organizations across the sample have started their S-Bomb journey. And it's going to be quite a journey and it would require quite some efforts. Industries need to build confidence with S-Bomb standards, tooling, and best practices. S-Bomb is not a brand new concept, but what often happens still is that when we try to find that document, we receive some random format custom invented document that contains less data than we need actually. And it happens more often than we would hope for and bring some major problems like having not comprehensive data and that custom format S-Bomb can fully benefit from the existing automations. It prevents interoperability and hinders the data exchange. And what I'm trying to say with this is that we need to stick to a standard. And we already have some standards. The SPDX or the so-called software package data exchange standard start as a pure of the Linux foundation open compliance program and it's the official approved ISO standard for now after being the de facto standard for around eight years and it pretty much looks like this. It contains information for packages and files included and the relationships between those packages, it contains document creation information and so on. The 2.2 version is the last official ISO approved version for now and the next minor 2.3 version just came up with improved ability to capture security related information. And now the 3.0 version is baking up with some great redesigns of organizing the data into profiles including a core profile that contains general information about the document, software profile that contains information about packages, files and snippets, licensing profile, defects profile which contains security related information, build profile for build time information and so on. Those turn into a very powerful instrument of knowing what's hidden into our software and one this version is officially published, one can easily translate 2.2 and 2.3 documents into 3.0 but obviously the vice versa would bring some data loss and those profiles should be fully valid SPDX S-bombs by themselves. And they are great for customizing the model based on one's specific use cases and requirements and allows adding some data elements that address specific use cases. They are all subsets that make up SPDX but operationally one can use any combination of them like for example core software, licensing and defects profile together or any other subset. And there are other standards as well like the CycloDX which was initiated by OWASP with the intention to be more focused on security information and it supports labels like CPSuite and Perl which allows identify if software has some non-vulnerabilities that are related. And all S-bombs formats are intended to be interoperable and out of any corporate boundaries and should be easy to exchange between tools that operate with them should be easy to replace. Cool, so we know what data we want to convey across organizational boundaries in an S-bomb and we have the standardized formats meaning that S-bombs can be machine generated and read the exchange can be automated and we can make it scale. But how do we do that in our modern complexity with that variety of ecosystems, programming languages, package managers, build systems, et cetera? Do we have the tools to do that? A lot of communities are currently focused on developing open source tooling for efficient exchange of S-bombs to allow all the benefits that we can have of them. We are not going to walk through the whole landscape of tools but what we would like to leave the room with at the end is what an ultimate S-bomb stands for and this landscape plays a major role in the definition of ultimate and this is because the tools appear from need and requirements and the requirements represent the various use cases and we want those use cases well represented in the data. From all the tools, third is the one that we are most actively engaged with. It is a great inspection tool for generating S-bombs for container images and from container images and Docker files and it was started in VMware's open source program office and is now under the stewardship of the ACT project. Together with some great other projects like Phosology, ORT, SPDX tools and others. It's a post-built solution and it supports the existing standards and it's great for use cases where you receive the container image that doesn't come with an S-bomb and you need to generate it post-factum or you have one already generated but you want to double verify the data and feel it if something's missing. And let's have a look at some other tools as well. Salus is a good build time solution. It was implemented by Microsoft for their specific use cases and what was open sourced a while ago and can be a really good fit for some other use cases. And there is one really nice tool. It's a bomb tool that was created just a month ago and it's part of PicG Conf. It supports build time, generation of S-bombs and it's specific for CNC++ packages and it can be a great solution for that specific use case because it can bring more accurate data for those packages like compile data, for example, things that other tools might meet because they are not focused on that. The SPDX S-bomb generator generates S-bombs from source code and you can attend the state of S-bomb tools, Birds of Feather by Nisha Kumar on Thursday to learn more details about it. And the Cade's bomb is an emerging and all-in-one solution now and it supports generating S-bombs for various use cases like from source code, container images, directories and so on and it also allows operating with that data afterwards and there are others as well as we can see it's not a small list. Great, having tools that generate S-bombs at different stages of the software lifecycle is awesome. Each stage, however, has its unique features and S-bombs might have differences depending on when and what data was collected. Missing dependency and built metadata might reduce the benefits of S-bombs, the security and compliance benefits that they bring. So we need to make sure that we have all the pieces. As you might already have noticed, I'm a person of analogies and if I take a glass of water and I add a drop of red paint, the water will soon turn red, right? So just one vulnerable piece, sorry, just one vulnerable piece can put the entire system at risk and we'd like to mitigate that risk. How do we do that? If you look at the Sousa security framework, we can see the red triangles that mark the treats to the supply chain that Sousa addresses. It's highly common that we generate S-bombs at the source code stage or at the post-build stage, which is the package here in this picture. But if we generate S-bombs at build time, this would bring high fidelity information about what dependencies went into our software build and it would bring more complete and accurate data about any modifications that were made by the compiler or other tools. And there are other variations as well, like for example, we can only have the object called or there might not be a good build time solution for our specific use case. So in this case, binary analysis tools can do a great job for analyzing what dependencies are in our software components and as we saw from all this, we can see that each tools has a slightly different approach. One can be built or post-built, they can generate from source, they can generate from container images and so on. And this diversity is highly necessary for capturing an S-bomb that's exclusive. Definitely, definitely, we need the best of all worlds because we cannot expect to have from source or build time generated S-bombs for everything. And at the same time, we cannot just settle for post-built scan S-bombs exclusively. So we need them both. On the other hand, software is modular in nature and every component has its purpose, dependencies and lifecycle. If we incrementally left shift our S-bomb generation on per component basis, we'll end up with wider in quantity but smaller in scope S-bombs that we refer to as micro S-bombs. Having micro S-bombs to describe each component that makes up a larger software piece would result in much more accurate built and dependency information being captured. I like the back button. We'll fix the direction still at the end. I like the back button better. Yeah, but at the end, we might end up pelt high with hundreds or thousands of S-bombs. Ivana, can we escape that nightmare? It's hard if we really want to generate all the information and capture everything but the good thing is that we can stitch them together into a single S-bomb and we refer to this as composing. And this is why we created a functionality that can do this for us and can stitch those micro S-bombs together. And what it does, it parses the micro S-bombs. It merges them into a single S-bomb with removing any duplicates, updating relationships data to have an accurate dependency graph at the end and make up a fully functional S-bomb at the end that refers to the latest versions of fall from all the micro S-bombs, bringing all the benefits together and making it easy to operate with a single document. And let's see some practical examples and some demo that we did with micro S-bomb to be more concrete and show real examples and real data. This is a running container from Photon Image and I've configured a pkgconf inside and as we can see, there are not many packages. So this is why I installed Cinnamon Desktop Dev that comes with 205 dependencies in it. And we will see at the end that all of those will be linked to pkgconf. What we would like to do, we would like to generate S-bombs for all of them. So we create an spdx folder that will contain all the spdx files at the end. And we list those packages and we will use the bomb tool that I shared about ago for generating spdx for each of these packages. So we can see all those spdx files available at the end and those are 205 micro S-bombs for all the packages. So let's have a look at the real S-bomb, how it looks like. We can see the car package, a carfc package. It has car dependency, it has the geobj and glib. And let's see some relationship data in there. Looking at the relationship label, we can see that carfc depends on car or it depends on geobj and glib. Geobj depends on glib and et cetera, et cetera. We can see that there is a good representation of the dependency graph. And what we would like to do now, we will copy all those spdx. I do it externally just because it's a more practical use case, usually one does this in CI-CD system. But it depends on the specific needs, one can also ship this with a specific image and build it inside. We see that all those are now copied here, all the Cinnamon desktop dev packages, spdx representations. And I will show the tool that we implemented. This is a simple example config that allows you to configure the core compose document. It's just some example information here and one can specify to the specific needs. It's just an example. So I will use the composer tool now and we'll compose all those files in the spdx directory into one ultimate cinnamoncompose.spdx. And if we have a look here, I will open that directory. We can see all the spdx packages, all the packages that are referred to by spdx. And if we open this file and we have a look, we see this root document containing all those packages information. And if you look at the relationships, we will see all those packages related. And if you can see, I don't know if it's seen well, it describes them because there are various kinds of relationships and they're not dependencies of this top level artifact and they're described by it. And if you look at the Cairo FC package, we can see that it's here with its dependencies with Cairo, Geo, Objects, Glib, et cetera. And we have all that information stitched together into a single document. And I think it's a good step into having an ultimate document to operate with. And if we have to complete the key takeaways that we would like to leave you with today, one of them is that yes, generating an ultimate S-bomb, yes, it's technical challenges. And there are a lot of communities that are working on this and are overcoming those. And in the end, it's not a rocket science, but it might really come close to if you try to integrate it into some legacy systems. But there is one even more important challenge in it. Yeah, there is one more challenge peaking behind communities and organizations need to introduce the necessary changes to their processes to adopt S-bomb and to start getting involved in S-bomb production. Providing S-bomb comes with a lot of benefits one might expect to realize, but there are also concerns that need to be properly addressed. All actors in the supply chains need to start providing the necessary transparency in how their software is created, distributed and consumed. We need to come together to take full advantage of S-bomb capabilities and have more secure supply chains. And with this, we would like to thank you for attending. And this is a list of some of the references that we have in our talk. So if you'd like to learn more about some of the tools and projects, and those are our context if you'd like to get in touch and exchange some information or have ideas about what we are working on and ideas for improvements or like collaboration. And you can also find us on the VMware booth tomorrow at 4.30 p.m. and on the Thursday morning. So we will be happy to exchange any information. And if you have any questions, we would also be happy to answer. One question, I don't know if we... Yeah, if we have a microphone. Sorry, there was so much. First. Yes, with your compose tool, can you compose any SPDX files or only SPDX file generated by a specific tool? No, it works with a document and as long as it's a valid SPDX, it can generate. It just depends if the tool really generates valid SPDX. I tried it with turn, I tried it with bomb tool, and it's on the list to try with some Zephyr SPDX files. So it works with all that I tested with and it works with both tag value and JSON formats and it can output in the format that you would prefer and it works with mixed formats as well. It parses depending on the file it parses at the moment. Okay, thank you. It's an open source tool. Yeah, it's open source. It's called as bomb composer and there is... Oh, I didn't add the link to the most. Yeah, I didn't see it. Okay, it's called, it's under VMware Sample Storypoint GitHub and it's called as bomb composer. Yeah, I don't know. Okay, I will, I can write if you'd like. It says bomb composer and it's open source and I would be happy to collaborate on it and if you have any comments or ideas or other use cases that it doesn't address yet. There was one question in here, in the second row. Yeah, hello, thanks. Bomb tool you used in your demo. Is it package config bomb tool or is it something else? Yeah, it's the package comf. Thank you. Quick question. Is the composer as bomb generator in its own right or is just composing existing other as bombs? It's composing existing files. What it does is it stitches together all the SPDX files. So it cannot generate like... Yeah, it's not a generator. The idea is to get all the data together. Hey, great talk. Thank you. So I have a question from the user experience perspective. So when you are composing as bombs by stitching together other documents, there is, there might be a situation, in fact there is that situation where you may not want everything in all of the as bombs. So you, I know that this is not implemented yet but at some point you need to decide that you only want a certain number of packages from one of the as bombs to be added to the final document. Have you thought about how to give the user the choice of which packages to include in the final as bomb? You mean how to advise which packages to select or how to apply this with the current implementation? Yeah, exactly. For example, if I take two as bombs and I want every package from the first one but I only want one of the packages from the second one, have you thought about a mechanism to give the user a choice how to select that package? Currently, there is no such functionality because it didn't come to mind. This is case but this can be added as an argument and one can list, for example, forbidden packages and then it would be easy to, because we parse and load all the packages so we can just remove all the forbidden packages and it can be pretty straightforward implemented if it's just listing them and there are not some other analysis and if we need some smart analysis then it's good for discussion. Okay, yeah, well, thank you. Any other questions? Seems like we don't have. Thank you, we thank you for attending our talk. Thank you so much. Thank you so much. Very cool.