 S-bomb. The rest of the story. Introducing our three explorers. Alan Friedman is a paladin, a warrior who swore an oath to protect and help everyone else protect themselves and others. He isn't actually good with weapons, but has studied many in arcane tool and art. A noted scholar before taking the paladin oath six years ago, he recently sojourned from NTIA to CISA. He works with communities and trades across the realm to help build shared scalable defenses. Well, not scalable like a wall, because that would be bad. While he certainly didn't discover the book of S-bomb, he has spent far too much time talking about it. Nisha Kumar. Nisha is a barbarian, a fierce warrior that rushes in to defend open source from the dangers of clutter and toil. She is most effective with the snake staff, but is also pretty good with the gopher club. Nisha belongs to the open source technology center tribe at VMware. And Emily Fox. Emily is a former paladin turned rogue known for her stealth and getting software engineers to develop more securely without their knowledge. She lurks in cloud services at the fruit company, providing precision and security architecture design while also co-leading the security technical advisory guild in the CNCF. She repeatedly demonstrates resourcefulness, cunning, and versatility, making her skills and those of Nisha and Alan essential to any successful S-bomb adventuring party. Our story begins. In a world of compliance requirements, security compromises, and ridiculously long dependency chains, three unlikely travelers cross paths to clear the smoke and mirrors around S-bomb, the rest of the story. Our champions of security, compliance and open source, Nisha, Alan, and Emily have arrived at a local pub to catch up. They talk about the latest supply chain attacks, the residual effects of solar winds, how everyone is seeing an increase in attacks. Eventually, their conversation transitions to the most recent US executive order on cybersecurity and the multiple efforts cropping up across the world to implement the software bill of materials. As they talk, a stranger approaches. Our travelers break off their conversation as the stranger stares intently, weirdly. Their face appears to be worn by countless hours of Excel use. The stranger whispers, that which you seek. The stranger extends a long crooked finger to indicate a shelf in the corner. Our travelers don't recall being there the last time they visited. The stranger coughs and turns back to our intrepid trio. They warn, you may never use it, but when you need it, it is valuable. Alan jumps up off of the stool and walks over to the shelf, grabs a heavy, large book, closely resembling the complete rainbow series in size, and holds it up. Emily looks at Nisha, who shrugs as the stranger fades from view. So Alan, what on earth do you have there? Why, this is espom. Nisha and I have been chasing down the mysteries of this for quite some time now. Indeed. I feel like we spent the last year chasing and talking about this artifact. What's another session to set everyone straight on the actual espom story? Alan drops the espom in the middle of the table. Our companions settle in to begin planning their journey. Two strangers sit listening intently. So I recall Alan and I talking about this a long time ago, back before SolarWinds consumed any sense of supply chain innocence. How do we expect folks to use it? Should we just throw it at people like a confusion spell? Because ultimately that's what it's bound to cause. What kinds of information are in this thing? I don't recommend throwing it at people. We want it to be useful, not confusing. And it really depends on the espom. There are a lot more metadata that could be included beyond the minimum requirements. Some can provide information about the source code, the build environment, and the actors who attest it to the process. That makes sense. I mean, security folks scare enough people as it is anytime we can help others produce actionable security relevant information that is easy is a win in my book. But what about formats? Is one better than the other? I keep hearing that there's a lot of them out there. Two standards, both alike and dignity, in fair software, where we lay our scene. Alan, no wrong book. Oh, sorry. Get a little confused when costume. So basically, there are two primary formats that are reasonably widely deployed today. Cyclone DX, which comes from the OOS world. It's a fancy project there. And SPDX, which is a Linux foundation project that just got ISO status. Both are great. Both have active development communities. And the important thing here is that a standard format enables you to create a broader tooling ecosystem. So what we're interested in doing is saying, what's the metadata that we're tracking? Let's have a common way of tracking it with clearly labeled fields. And so we can use the minimum sets to convey and move the data around. So it sounds like if someone is already using one format over another, there's no reason to change it. But what if I'm not producing a sponsor and I'm not using a specific format? I don't want to end up in my entire tool chain and tech stack and tech technology ecosystem. Just be able to produce this thing that somewhere somewhere on the internet or in the world is probably going to use might look at but then not know what to do with. As Alan said, the specific format is not important. But the metadata within it is, regardless of what format you choose, it becomes useless if the metadata is not there. If you're not already producing a sponsor, look for tooling that complements your existing tool chain. There are many open source tools created and maintained by volunteers in the community and in industry working together to make the state of the art better. This is how open source works. Yes, so the success of standards is openness. And the vision here is that we should have a shared understanding of what we have and then building on top of that data layer is an industry. So we have a great open source community and open source tools and that's great. There are some people trying to make money by building tools and hopefully they're interesting enough. People say, hey, yeah, I'll pay for that. And that's okay too. The important thing is that we have a shared vision about the value of this data layer and that we're building on top of that. So it's not the potion of invincibility that I keep hearing about and it's going to solve all of our problems in cybersecurity and cloud native, right? I don't know too many people that have actually been saying that. I think that's something that people sort of as a straw man try to poke at. But reality, it's just a data layer and we think it's a foundational data layer. So imagine it's something to akin to CVE, right? There's nothing magical about giving a vulnerability a data string or a number string. That doesn't help you. But once we have this shared vision where we can communicate about, say, a vulnerability or about the components that we're using, then we can work together and then we can build more tools and find more use cases on top of that. Having navigated past the misconceptions in the pub, our travelers embark on their quest. So this book has a lot of information in it. That's great. What can we do with this information? How do you all see this meeting and SBOM consumers needs? What use cases exist for the content in SBOM? That metadata that Nisha and Alan have both referred to. So in SBOM is an important part of the balance supply chain breakfast. It's the beans in your English. You're full English. It's the chocolate sprinkles on your Dutch roll. It's the muesli in your morning routine. It's Apparently, Alan skipped breakfast today, but I'll go with that analogy. SBOM is like a key nutrient that if you were deficient in manifests itself as symptoms that seem unrelated. Once you have an inventory of your deployed software, you can do things like correlate what you have deployed with what vulnerabilities exist. Or if you potentially have software whose license doesn't match your organization policy. Excellent. So it can help organizations not only make but automate compliance and security decisions before deployment and after deploy. That's fantastic. What's important is that it won't convey vulnerabilities, but certainly provides you with a map about what you've got to match against what is vulnerable. This sounds like it really was designed for on premise environments. Actually, the impetus was for on prem. In the midst of time when software used to live in place rather than in the ether, the value was really that defenders needed to know was on their network and you can't defend what you don't know about. And in fact, a lot of the early adopters that care about this are in critical infrastructure dealing with on prem software, things like medical devices and energy and industrial control system world. But the spirit of needing to know what we're dealing with what we're trying to defend that lives on with the cloud native security warriors today. Honestly, that's a great point between on prem and cloud native. With more organizations either moving to acquiring or being born on cloud, companies are constantly evaluating their current product space. I can see the SPOM helping here. Yes, companies are making acquisitions consolidating and driving digital transformation. Having an SPOM would help consolidate in key areas and reduce variety of versions of one software component, organize deployments and so much more. Essentially, not having an SPOM is the supply chain equivalent of forgetting your 20 sided dice in D&D or maybe not bothering to comment your code. As Nisha, Emily and Alan continue on their journey, the beast of secure builds steps in front of them, blocking their path. They must confront it before proceeding. I've heard so many things about SPOM. It seems everyone is assuming it can do everything except be that potion of invincibility, that it can provide integrity over the entire supply chain, solve open source security and auto reports security vulnerabilities for you. That's ludicrous, right? So in fact, SPOM doesn't do any of those things by itself, but try doing any of those priorities that we all should be working towards without an SPOM. It's painful. We've all tried to experience doing it and trying to build our own or roll our own, and it can be very difficult. And SPOM makes all of those easier and more scalable. Yep, you are responsible for your supply chain's integrity and SPOM can help you establish the state of the items it knows about. This doesn't imply integrity of the software supply chain and signing an SPOM is not a minimum requirement. If an attacker were to successfully compromise the publishing infrastructure that produced the software and the SPOM, and if all of that were signed, you'd simply just have an inventory of everything in the software, including any libraries the attackers introduced in the code base through the build. The SPOM doesn't stop that. Essentially, though, folks can generate it from source build or post build with binary analysis. Generating the SPOM from the build seems the right way to go based on what Nisha is saying. If you build it, you better SPOM. We know that compilers are the dark arts and build systems really can be as well these days. This is why it's so important that in addition to source code security, folks are paying attention to what goes into their build workers, disabling SSH access, and so much more. The build system can be compromised and impact what is in your software and your SPOM. That's why in the optimal case, a secured build process is what we need, not just for our software, but for the SPOM data to track it, especially in cloud native, as our vision is that we're agile and we like to move fast and break things. Having subdued the beast of secure builds, our travelers have approached the swamp of sharing uncertainties, unclear on how to move forward. There are a bunch of minimums and depending on your industry or regulatory requirements, these minimums may vary, right? So at its core, an SPOM is about identifying a component. And to do that, there's some basics that we need. We need to have some identifiers, ideally some identifiers that other people use so you can map them between databases. And then there's a bunch of other use cases as well. So one popular way that people sort of say that is we want to use SPOMs to track vulnerabilities. And in fact, some of the data formats can track vulnerability data in the SPOM, which is very useful if you're a developer. One of the risks, however, is if you start depending on the SPOM to track this data and it moves across organizational boundaries, then you're not sure if it's live. And so we have to be very, very careful about the assumptions that we make about the state of the data in the SPOM and what we can and can't depend on to be completely up to date. So basically, because we've got so many vulnerabilities today, and we want to make sure that the information that's available is complete, accurate and up to date, because we've never ever deployed any software anywhere in the world that has remained secure for its entire lifetime. Yeah, we can actually take a page out of the manufacturing playbook where the bill of materials is something that gets passed on from supplier to supplier until it finally ends up with the product that gets shipped. And then there is a remediation process where defects out in the field get collected and sent back to the suppliers. And they use the SPOM to find out which component has the defect so that they can fix that component. And the cycle repeats. So that makes a lot of sense. And I'm assuming that they have really good established relationships. They all trust each other. Everything's good. But honestly, that SPOM is probably going to come from a complete stranger all the way on the other side of the world. Somebody you've never met. How can you trust what's in it to be accurate and what if it's incomplete? What tools exist to produce SPOMs and isn't producing an accurate SPOM a challenge to begin with and don't even get me started on consuming them. That just seems like a nightmare. So we've got a couple of fun challenges here. You're right. They're all things that we need to tackle. So one is, hey, who is this coming from? And of course, we have natural tools for that, signatures, digital signatures. But of course, those of you who play in XML and JSON know that wrapper signatures are non-trivial. Fortunately, both SPDX and Cyclone DX have been working on developing those and they're great projects like Sigstore to enable it. Second challenge is saying, well, how do I know the data is true? And there are a couple of things you can do. One, you can count on the fact that it's illegal to lie about a product. Two, you can always do the trust but verify. You know, you should talk to earlier about source composition analysis tools and binary analysis tools. Those may not be the first best option, but they're a great way to validate some of this data. And then lastly, we have the question about how do we make sure that we can consume this data. And where we want to head is supporting automated decisions based on rules. And there's a huge development opportunity here. We're going to need smart people to think about this. This is the whole growth area of code as compliance and policies code. What we want to do is sort of think about customizable approaches that are less complex and more straightforward. And to do that, to make progress, we need to share what we have and work towards common policies and decisions that are useful to the SBOM consumers. That's right, Alan. Making the SBOM actionable for policy makers in an organization is an opportunity right for the taking. A swamp monster emerges from an alcove of algae and growth and announces loudly. Ha! I already have that with my source code analysis tools. Nisha rolls a 19 to detect glamour and the swamp monster fades to reveal a small fly. Aha! Dependency trackers like you see in source code analysis tools typically rely on a package manifest. A package manifest will give you some of the information, but not all of the information. What actually gets installed is determined by, say it with me now, the builds! So what about sharing SBOMs? Ah! There be dragons as we've reached the limits of our map. We know that this is a priority and there are a lot of folks that are exploring how to do it. One of the easiest ways that we can do it today is there are companies that are already saying, hey, I've got my live build, I've got my live SBOM, and I just post it online. And that's great for a lot of organizations. However, there are going to be some folks that say, you know what, I'm not ready to make this data public for whatever reason. And so then we're going to need to think about what access control can look like. Or you could publish your SBOMs through customer portals or websites or even shipping it along with your product. Very much like how you would be able to ship SBOMs with container images and store them both in a container registry. And there are emerging technologies like manufacturer usage descriptor, which is a way of having a secure pointer to an SBOM or the D-bomb model, which is an access control overlay that allows you to sort of put a lot of supply chain data pretty much anywhere and then assign, read and write and edit accesses so that your customers and your upstream providers can all talk about it and you can control how they're doing it. Right. And that makes sense. And what's important really here is that it's only good if it's relevant to the software that's in use, not to versions behind. And that's why it would be great to be able to produce it as part of your build because it can reliably match what you're shipping or making public at the time. So given that I'm a crafty, clever fox that I'm putting on my attacker hat, how do I explain that no attacker is going to leverage the SBOM as a shopping list of places to exploit? As it seems like your really key area for doing reconnaissance work. So, you know, it's 2021. So we don't just talk about attackers or monsters. We actually do a little threat model. So you're really powerful attackers. They don't need this, right? If they're going after your software, you know, Jidra is free, they can do reverse engineering, they're not going to, they'll figure out what is in your system. And at the other end of the spectrum, you've got your automated attackers, right? People who are just doing spray and pray, looking for toeholds that they can start a ransomware project or something like that. And there again, they don't need the roadmap. They're just doing automatic scanning. And if you have a flaw, they'll find it. What we need is to give the defenders the roadmap so they know what it is that they should be paying attention to and worrying about. That's right. The S-bomb is a tool for the defender, not the attacker. If you were to give a map of your castle to an attacker, but have each entry well defended, the map is not going to be of any use. That makes total sense. And like, it's part of a good defense and depth strategy. The S-bomb is not going to defeat that all by itself. Realistically, even if they had that full shopping list, they're going to have to do a whole lot more work. But what about sensitive information, such as sources and methods? We can't possibly share everything. Please tell me no one's putting secrets in this stuff. No, the S-bomb is not meant to store your secrets. There isn't really a formal standardized way of sharing sensitive information. SBDX has this concept of profiles, and one of them is the usage profile, which gets shared between suppliers of components and consumers of those components. And this is something the auto industry is championing. This could probably provide a template for how other industries could share information. I mean, ultimately, you want uniform adoption across the board. Aspom and supply chain security is way bigger than just cloud and cloud native. Some industries, it sounds like are moving really fast, like automotive and finance. That's right. As a cloud native community, we want this to be adopted beyond just Netflix and Twitter. And for that to happen, we need to be really careful about how we build and inventory our software supply chain, and we need to consider what kind of checks and balances we need before we deploy our SaaS offerings. A lot of people in cloud native, when they think about SaaS, they think Twitter, and we really want to move on to we want this to move on to industries that are more serious, like healthcare and finance and the government systems. Things that keep going in my life. Wait, Nisha, are you saying that there are people involved in security that aren't on Twitter? I'm pretty sure I would have read about that on Twitter. Our travelers have navigated the swamp of sharing uncertainties and are heading back to the pub to share their story. But how that story continues is up to you, the community and industry, to make something of S-bombs, to use them. The winds coming across the land, blowing from executive order, hint that this issue is not going away and will only get more important. That's right. The leaders of the realm in the White Castle or at least the White House have decreed that S-bombs will be a priority. Anyone who wants to sell critical software to the government will eventually have to have an S-bomb. And I have a hunch that companies aren't going to want to have two different versions. And so we're going to see most organizations realize that this is something they're going to need to have. Can we succeed on this quest? Our party of adventurers have some solid members. And Alan. Hey. But we need more help. How can folks get involved? Well, one thing folks can do if they want to sort of see the big picture on S-bombs is join this international community-led effort that's brought together experts from a range of sectors and different types of technologies. And to do that, very excited. It's an open effort. And so get in touch with me through email or find me online. Or you can join the main thing, open source projects out there. Both SVDX and Cyclone DX are open initiatives and would love your help. A project that is near and dear to my heart is the term project which generates S-bombs for container images. So it sounds like there's a lot already out there, but there's even more for folks to get involved in. Tooling that can help generate S-bombs as well as complement the overall supply chain security process, such as Tuft, Spiffy, and Toto SIFT so much more. Our travelers return to their table, awaiting new friends and colleagues to join them on their next quest. Will they see you there? The rest of the story is in your hands, but are you willing to commit? Thanks for watching S-bomb, The Rest of the Story. Stay tuned for scenes from our next episode where our explorers figure out how to do a live Q&A. See you soon.