How I Learned to Stop Worrying and Love the SBOM - Dr. Allan Friedman

hi my name is alan friedman i'm very excited to talk to you today uh and i'm excited to talk to you today for a few reasons first uh you know i'm sorry that we can't have a fun event in pittsburgh i'm actually a yinzer uh born and raised i was born in mcgowan's hospital i'm a product of the pittsburgh public school system go alternate dragons uh but um i'm also really excited for two other reasons uh first just to go back and back to the slideshow um the this is one of my favorite graphics to use uh the you know i've given this talk uh once before two years ago black hat with the same title

but at the time i call it how i learned stop worrying about the s bomb over two years uh we as a community have made a lot of progress in thinking about software transparency so that's why i'm calling the talk how we learn to stop worrying and love the s bomb and hopefully by the end of it you'll be excited enough that you'll want to start asking for it and maybe even get involved so let's dive in and i'm going to ask a sort of motivational question here which is uh how many of you are in organizations that whether you make software or whether you just use software can quickly and easily answer the following question of hey

there's a new vulnerability it's all over twitter it's even on the news your boss calls and she asks are we affected and i'd put it to you that surprisingly few organizations can quickly and easily answer that question especially when it's a low-lying open source component rather than you know a big piece of classic enterprise software and to me that's kind of crazy the hard work should be in finding the vulnerabilities uh discovered in the first place not finding out whether they're on our networks and that's really what s-bomb is about so what are we going to be talking about over the next uh 18 minutes i'm gonna you know challenge virtual events as i have to literally be more

interesting than the entire internet uh or to talk about transparency uh and just how it relates to supply chains in general or talk about s-bomb i'm gonna briefly try to help you understand this is such a good idea why we aren't doing this already uh i'm gonna talk about what we as a community have done in this international cross-sector approach uh talking about the what's of s what is an s-bomb why is an s-bomb and then of course how do we do this and then ideally uh pitch you to get involved yourself and this is s bomb ask for it by name so uh we're all pretty familiar with the idea of a list of ingredients

um now this is the list of ingredients for a twinkie and maybe you like twinkies maybe you don't but sometimes you care about what's inside them and it turns out that twinkies are not vegetarian now maybe you don't care but we all know someone who has a dietary restriction uh or food sensitivity and they'll want that information in an easy and accessible format and to me it's kind of crazy that we have this information from the world's least biodegradable snack but we don't have it for the software that we all depend on on a daily basis and it's not just you know in twinkies this is you know a fancy plane that we spent a lot of money on to develop in

the united states uh that piece of that plane has buried deep in it a certain operating system a real time operating system that real-time operating system in turn has a vulnerability how do we make sure that the people who are managing uh these critical systems can find out what's buried deep inside you can't defend what you don't know about so what's the software equivalent of this list of ingredients i'd put it to you that it is this idea of a software bill of materials forgive the wall of text here we try to minimize them on our slides but it's important to sort of say this is what the definition is and here are three different definitions uh it's a

formal record of the supply chain relationships in software it's a nested inventory here are the ingredients that we have and it lists those in components and the relationships between them now s-bomb fits in to a lot of different areas of security that we all care about and you can think of this as a spectrum from the people who make software you're interested in secure development processes sdlcs uh you're probably focused on your supply chain if you're a mature organization people who are choosing software who are selecting things for their organization whether they're buying them or using open source components they're interested in supply chain they're also interested in risk management and this is where we get into

our third-party risk management approach and of course those of us who operate software and by the way this is everyone uh we need to have a vulnerability management approach s-bomb doesn't solve these but it helps each of these roles in a critical fashion and i'll try to walk through that but i want you to appreciate that this is something that really is important on everything from the application developer to the ot implementer all the way down to just your standard blue team vulnerability management approach uh s-bomb is really going to help across the board so alan if it's so useful why aren't we doing this already well uh first supporter knowledge that some people already tried

now i don't want to get too much into the weeds in the history of politics but six or seven years ago there was actually a bill in congress that would have required everything a certain part of the us government bought to have an s-bot and to be frank the i.t industry nuked it from orbit uh and we can you know you could find me some time and ask me a little privately about some of the politics behind that but i think there were some reasons why uh first is open source right i don't know even until quite recently how many organizations could honestly say that they had all their software licenses in order i'd put it to you

today that it's a much better understood risk that's something that they're now commercial off-the-shelf tools for there are projects like the linux foundation's open chain to help companies better manage their open source licenses uh if you have a startup you know that you're gonna go through an open source audit on exit so i think we understand that risk better but we also have to acknowledge that this is hard if it were easy we'd already be doing it uh and we probably shouldn't put things in regulation until we know how to do things what i'd put it to you is this is actually a little bit of a chicken and egg problem where uh on one hand no one's asking for

it so no one's supplying it and on the other no one's supplying it so no one's asking for it and that is what those of us who have some economics training call a market failure now a market failure is fun for a couple reasons first of all you get some interesting math if you like the economics of it but also it's a role for the government to come in we're from the government and we're here to help you uh so there are a couple of ways that government traditionally solves problems we can either force you to do something through regulation and you know congress and their wisdom didn't see fit to empower yours truly to force anyone to do

anything and we can also reward you we can give you certain kinds of incentives or we can pay you and unfortunately no one gave me a budget so i can't personally pay you to do anything so what is our solution our solution is to try to bring the entire community together to bring both the chicken and the egg together and say how can we make this work what's a good solution so here's your basic process slide and if you've never seen one of these congratulations you've managed to avoid politics well done uh the vision here is to create a very broad approach we wanted to make sure first and foremost that this we weren't we were avoiding sector specific

solutions so what we really didn't want is to say this is the healthcare way of doing things and this is the military way of doing things and this is how just the standard enterprise i.t world does things because now we have a fragmented ecosystem and guess what we all use the same software so we have to have a solution that works across all of these sectors even though they're very different ways that software is made and used whether it's in the automotive sector or banks similarly we needed to capture not just the entire cross-sector approach but the entire supply chain we wanted to make sure that this is something that included the open source perspective

the commercial software perspective uh those who deal with embedded software iot or ot and of course perhaps most importantly the customers the people who are using this stuff we need to have them at the table so this is a very broad approach we're trying to get every sector the entire supply chain that's why we framed it very specifically to only look at the set of software dependencies now the way we've done this is in a open transparent multi-stakeholder process if you kind of roll your eyes at hearing the term multi-stakeholder process i'm the guy who's to say it like 20 times a day so have a little sympathy okay don't be so smug what we're not doing so i also want to

be clear about this i mentioned we're not this is not about regulation we're not a regulator this is not source code disclosure that's something that i often have to be very careful of when i talk about lobbyists especially in the international stage this is not a formal standards development process in fact i'm going to talk about how there are already standards out there doing this and perhaps most importantly we're not trying to solve all of the issues around software supply chain and software assurance i'm sure you're working on some issues that are really important you're providing solutions for your problems that's wonderful what we want to do is take this s-bom layer right it's very broad

we're trying to keep it as narrow as possible to help it slot in to however you're working on security so we've been doing this for two years now uh and i'm pretty happy with the progress we've made uh because what we've done is we've managed to bring together all of these different sectors from around the world and to create a shared vision of what is an s bomb we didn't have that before uh and not only that but to focus on some aspects it's got to be machine readable so it can scale and it's got to be modular so it can dock with all these other efforts and we want to follow a crawl walk run

model we don't want to try to solve everything all at once we're not trying to build something gorgeous in a cathedral and then bring it out to the world our focus is to coin a completely original phrase rough consensus and running code so as i mentioned i'm going to walk through what an s-bomb is why we should do it and then how we can do it and then i'm going to talk about what the path to deployment is so first alan you've been talking about ask bomb for a while you've heard of a wallet text what the heck's an s-bomb other than something that you shouldn't say a lot back when you're traveling in airports

so an s-bomb is really just a dependency graph uh if you follow the math it's a directed acyclic graph here's a toy example where we have our acme appliance and the acme appliance in turn depends on bingo buffer and bob's browser bob's browser in turn depends on carol's compression engine that's all it is with one other key layer of data which is we try to be explicit about known unknowns so for example in this graph we know that acme appliance has exactly two direct dependencies bingo buffer and bob's browser we have no idea what's in bingo buffer we know that carol's compression engine is a root of our tree uh or a leaf depending on which way you talk about

your trees uh which is to say it has no further dependencies and in this case we know that bob's browser at least contains carol's compression engine but we have no idea whether it contains further things now those details allow us to focus it and i'll talk about that in a moment for each of these components we don't need that much data the goal here is to say who's the supplier what's the component name what version is it so that i know if there's a vulnerability i know if it's up to date and by the way what's the hash so that i know that you and i are talking about the same component and we may want to make sure for example

uh that the version that i'm talking about isn't something that i just downloaded off of a backdoor github repo or a pirate github retail or a typo squad github repo there are lots of right this is about putting some assurance in the supply chain so in our graph how do we want to go ideally i'd love to go as deep as possible the minimum you can have is you need to have all of your top level includes each of those should in turn ask for their includes and ideally we'll make a best faith effort for all known components right the vision here is to use the power of recursion this is one of those areas

where we don't want to let the perfect be the enemy of the good there are going to be some folks who will start asking for a complete s-bomb the full graph but we wanted to make sure that we weren't requiring that at the beginning after all any information is better than no information so that's the basics there's some more information on this website that i keep popping up ntia.gov s-bomb but alan you've talked a little bit about the vulnerability management case why should we do this so it depends on what role you occupy in the ecosystem so for example if you produce software here's some benefits you choose software you operate software there can be different values

i'm not going to walk through all of these but i want to flag some things first of all this really helps if you're building software right you can't really claim to have a secure development process if you're not tracking the components right how else are you going to enable uh allow lists or deny lists and moreover there's value to your customers you're a potential customer first thing you want to know is am i about to buy something that's broken out of the box but it also allows you to do things like compliance policies thinking about end of life or orphan components or identifying hey this is really dependent on this single open source project that only has one maintainer so now you

can ask the vendor hey um if this maintainer gets hit by a bus what happens to the future of your product uh this is these are questions that you simply can't ask if you can't visualize if you don't have information into the supply chain of that and of course licensing is an important issue and lastly for operating software i talked about the value of needing to find vulnerabilities but there's also the importance of administration folks are starting to implement this into their asset management their seam products and perhaps most importantly when you find out a potential vulnerability right now without an s bomb the only way you know about it is if you get the

patch that you may have to wait a little bit for the patch independent mitigations are really valuable here so let's take a look at remediation with and without s-bomb at the top of this graph we find our vulnerability way upstream in a part of this piece of software and it now has to percolate downstream i find the vulnerability i build the patch i send it downstream to the compound part who sends it downstream to the final good which in turn then has to send it down to the operator who has to patch at the bottom of this chart we have a different world where there is everyone knows about it as soon as the vulnerability is discovered

and so even though the patch doesn't magically appear s bombs alas don't solve that what they do do is allow people to make a certain decision when i know that there's a potential vulnerability i can say well if i don't have a patch i even if i don't want to yank it off i can segment my network i can tune my ibs i can ask my threat intel company to keep an eye out for any type of exploit in the wild because as soon as i have that then i can take this other risk-based information the other value here is it really is going to be able to push natural selection of the software ecosystem so

we got the what we've got the y how do we do it allen well we did not want to be a standard development process the good news is that there's at least one standard out there that can do it there's slightly less good news of their multiple standards but that's okay we've got spdx which comes linux foundation there's swig tags which is an iso standard who doesn't love an iso standard and there's a newer standard that comes out of the os world called cyclone dx all of these are being used today our vision here isn't to say this standard winds it's not the government's job we don't think that that's what anyone should be doing

the vision here is to identify what are the common elements and to focus on translation so that we can have maximum interoperability and that's what we've managed to do so far those core fields that i talked about before here's how you can reference them in each of these three standards so now we've collecting tools that are already available to help you make your s-bomb and use your s-bomb today and then finally i want to briefly touch on some work that's happening because we didn't just want to say let's put this idea out there we wanted to show that could work and the healthcare community in fact the community focuses on medical devices has really come forward and said uh

we want to show this is possible and so over 2019 they did a first proof of concept in 2020 they've done a second much more sophisticated concept in the middle of the world's most critical public health crisis we have the best hospitals in america partnering with some of the most sophisticated medical suppliers in the country to generate s-bombs share them and use them against pre-defined security use cases that's how important this issue is for the community so what are we working on now we want to refine and extend the model we're tackling things like how to share s-bom data thinking about cloud we're focusing on tooling to make sure that we can do this today

what tools exist and what tools do we need we have a whole working group focusing on awareness and adoption how do we get this out to the community what does draft contract language look like so you can ask for s-bond by name and uh further demonstrations in other sectors we're talking to folks in energy we're talking to folks in finance uh we're talking to the broader health it sector and we're focusing on playbooks and how-to guides we're also tackling a fun little challenge which is hey not all vulnerables are critical how do we think about vulnerability versus exploitability but to sum up transparency is a big issue that we need it's not going to solve

all of our problems in security but a lot of what we need to do is you know this entire s-bomb is part of this complete breakfast a lot of what we need to do starts with transparency so to recap here tracking third-party components is critical for a range of risks in the ecosystem right you can think of this as the next step asset management is number one on all of our security lists this is the next step down there the solution for getting deeper into the supply chain is going to have to be cross-sector it's going to have to be international and that's what we've done we've pulled together this community focusing on what it is why it is and how

to implement it sectors and organizations can shape their own future through proof of concept exercise so if you're interested in this please don't hesitate to get in touch uh happy to talk about how you can ask for this from your suppliers how you can offer it to your customers and ideally how you can get involved in the conversation website is nti.gov slash sbam you'll find all the information you need to know uh don't hesitate to reach out i'm happy to set up a briefing for you and your team and if you really like and you ever send me a note that you saw this talk and you liked it let me know and i will give you this

handy-dandy s-bomb sticker that we have we might even make some more uh and of course reach out on twitter hashtag sbom to join the conversation so thanks so much and uh looking forward to your questions and hopefully you'll stay in touch and we can chat