Navigating The SBOM Landscape: Formats, Relevance, And Tooling In 2024

good everybody first talk of the day amazing um I am going to speak about s problems today it's what everybody is talking about these apparent these days apparently and I'm going to hopefully provide some more Saye overview of what it is and why it matters and hopefully you're going to come away from this with the reason why you should adopting it so first of all I'm just going to go into who I am um so my name is Victor I've done a few startups and the reason why I got excited about s bombs was because in my last company screenly we do secure digital signage and we work with a lot of like high compliance Industries we

have like Nas as a customer and like 14 to 15 companies in the world in the US and I started to see more and more requests for ES bombs from our customers asking for that so that's why it started to flag up my radar and that's why I started company around the ESP space called spoify I'm not going to do too much of a vendor pitch but there's a reason why it exists and that is because of the demand I saw when working in screenly and I've also joined ciser which is a US Government body that advises other US government agencies on how to do cyber security well esom falls under their Authority so I'm working

with them on a working group where we basically try to take the applied approach to esums and show you how you can actually use them and what the state of the current tooling is so that's kind of like a bit of background on me and why I'm doing es bombs I also got a podcast called ner Victor check it out it's on all the podcast platform I bring on all interesting guests from all works of life in Tech around Tech topics all right this is what you here what are what are es bombs well I presume a lot of people have heard the terminology s bombs es bombs stands for software bill of materials and it comes from the same

concept of a build material in manufacturing so in manufacturing you have build of material which is a list of component that goes into a product and it's used in all parts of manufacturing software build material takes the same comp concept but for software so you can think of it as a recipe list for your software that takes into account all your dependencies that you are using in your software but Al your libraries it can even incorporate things like your build environment how they actually build the software but we dive into that a bit more later on the talk about what that actually means generally speaking this is usually delivered as a Json file but it can be

also be an XML file it could be an artifact in in a doc container in oci format but most commonly you will run across them as adjacent file right but why now this is the real question because sure we can talk about es bombs is an interesting technology but why is there all the Souther a recent urge for ESP bombs and it really started off with a push from the US government so there something was issued 2021 called the US executive order 1428 and that mandated that anybody who sells software to the US government must provide an es bomb as part of that delivery now the reason why now is really a momentum kind of a Tipping

Point in es is because that mandate was postponed and it was only taken into effect this past summer so now all the big vendors that are selling softare with the US government are scrabbling to get their es bomb game together because otherwise they will lose all those contract and won't be able to sell to the US government but we've had kind of a so that was kind of a Tipping Point event but we also had like a cascading impact of that so as part of that we've also seen a pickup of just shy of a mandate of es bombs in compliance so the N cyber security framework the 2.0 was released earlier this year it's stop

just shy of mandating as boms but it's kind of hints at it and then you have the upcoming US EU cyber resilience act CRA for short is also s of mandate uh it's likely to mandate esoms in there as well at least hint at that so what are s boms used for so esums are largely used for two things so are two buckets of use cases fors the first one is security audits so if you know what goes into a piece of software you can Chuck that against a security audit tool that gives you exactly what vulnerabilities are in that software which is obviously super important for anybody who does security so that's one of the big buckets of use

cases for esbo the other one is for license compliance so if you're a big buyer of software if you're big software a big company buying from software vendors most likely or not more likely or not you will have policies for what kind of open licenses your product that you're using are allowed to be using so it's pretty common that you would not be able to allow products that using gal 3 for instance that's pretty common because it's considered uh risk risky in the business so those are two buckets that esoms a lar used for it's for compliance for license compliance and for security procedure but if you look a bit on the life cycles of ESP bombs I tend to draw

up this diagram of like the three faces of es bomb so you have the generation phase when you actually build Asom and we dive into the details on that we have the collaboration so it's like what do you do when you actually have this ESO what do you actually do with it and then well I would rather how do you share it with your stakeholders and then you have a third piece which is analysis piece so I've structured the talk around these three faces and I will be walking through each of these faces and how that works so let's start with the generation part and there are a lot of tools for generation of s bombs and the most

simplistic case is to use something like Docker Scout so if you're run Docker on your desktop you most likely have uh well if you have a Docker desktop as well you have Docker Scout Docker Scout can generate an Asom so you do Docker Docker Scout es bomb you specify the format that you want thatp put in and then voila now you have an s bomb okay that was pretty straightforward and easy well we're done right not really it's a good start but you know when they're ready for the compliance requirements for nest bomb you have a first step but it's a long way there and part of the reason why esoms is complicated to implement it's easy in

theory as you can see here D dumping for from a do container the reality is that it's a lot more complicated one of the reasons is that we're kind of in this format or about es bombs right now where are two competing formats there were third one but that's been kind of abandoned but are two competing formats in s bombs right now the first one is from the Linux foundation called spdx and spdx stems from the original from more license compliance than the security compliance and when you Analyze This format you can tell that it's very much driven from a compliance with license more so than anything else so that's the format that Linux Foundation is backing

and are trying to become trying to push for becoming a standard on the other side the other cam you have Cyclone DX which was developed initially from service now which is a big software company and they developed an in-house to create a inventory of what goes into their software they then donate at to OAS the OAS foundation and that is the alternative to spdx if you are assessing kind of state of is right now I would say cycl DX has a lot more momentum than spdx in part because the tooling is a lot better so they have a lot of tools for generating s SPD CX s bombs but also it's a lot more readable format so if you reading

adjacent file it's a lot more easily understandable and digestible than SP spdx so who will win this race well my guess is that neither win and that we will see kind of a third type of like meta formats where you can store the data and then you can output it to either of these as whatever you need for because there are some benefit one or the other and there are some formats like Proto bomb which is an early kind of metal layer for S bombs that is emerging and the benefit with that is that there are some data you can capture in SP spdx and that you can't capture in cycl DX and vice versa so more likely

than not we will start storing things in proto bombs or the likes off and then people can export and convert out to whatever format they need based on what they need to use Asom for all right let's dive into into the tools cuz let talk about like what's state of landscape today in 2024 so let's talk a bit about the tools well as you remember from that screenshot I can build s bombs using Docker natively well under the hood docker's actually using this call called sift to actually generate the S bombs and sift along with trivy from Aqua are generally considered some of the probably the best tools right now for generic tooling and genic tool means that they can do most

both these can do dock containers both them can do like application specific containers uh so they are kind of good tool kits I also need to add dependabot from from uh GitHub on this slide it's it can generate s bombs using the dependency tree GitHub but the quality of those es bombs are not great and generally in the es bomb Community it's not really really consider a serious play and there are reasons why you need to do your CCD pipeline rather than using a tool like uh dependabot you also I need to add sneak to this sneak does have a tool it's not really spoken about a lot in the es bomb communities but they they are a pretty

big player in this security space so I felt like I need to add that as well so let's dive into domain specific tools and whilst Docker can generate s bomb for dock container once you get more serious about s bombs and get more maturing your use case rest bombs more likely not you're going to end up with specific tools so I guess they fall in both two buckets around uh formats so the different format spdx versus ion DX they both have a large set of tools in their reposter so they're like that's one way to slice it but then also language specific so depending what program language you use you might find better Tooling in one camp or other um some

most popular languages like python or whatever they have good support on both sides but if you're using something more Niche you might find more specific Tooling in one camp or the other all right so you've generated your es bomb using one of these tools cool you have an es bomb well this is where it gets really complicated so recall that we mentioned the executive order in the US which the government one of the things they mandate in your espon is something called nti's minimal elements none of these tools will actually include that and that requires things like who are you as a vendor what how can I get in touch with you where are you based what are like a lot of

metadata that need to be appendant to your spom that is not included any of these tools so you what you tend to do is that you need to merge in metadata into your SP bomb to have a complete s bomb but it gets even more complicated because you're probably going to end up with more than one s bomb for a single project I'll dive into that in a second what I mean by that then there's another thing that makes it even more complicated which is transitive versus primary dependencies so the MTI minimum guidelines stat that you need to include all your transitive dependencies meaning that not only your dependency but your dependencies dependency dependencies and

that street structure get really complicated and there are not that many great tools for that right now there are some tools you can do it like depending on how you're using it but I'll show you exactly why this gets complicated so in that size of working group that I part of one of the deliverable we set out to do was to contribute Upstream to two open source project for the esom generation one of them we select was Jango so the python framework and the other one was key clo well when we dove into Jango we realize that we can't actually do this it's impossible to do this and here's the reason if you look here you can see the dependencies of

Jango and it says uh well you can see here equal or greater than of these dependencies well if I ship an Esa I can impossibly guarantee that that is actually the result you'll get as Customer because it just it's not possible because you could pin that dependency to something other than that and get a different result than I do in my cicd pipeline so whil I can make a binary release of Django which you can't really do but in theory I could make a binary release of Django ship that s because I know what I Ed when I build a binary but if you do pip install on your local desktop you'll get a different

result or the good chance you get a different result depending on how you use it so it gets really complicated so in the case of python or any of these other languages only way you could do this for something like Jango or a library is that if you have pin your all your dependen to a precise version and all your dependen PIN all their dependen of precise versions which is not going to happen so that's where it gets really complicated and this is when we get to the face of an esom there are really three ways to do an esom what we talked about here on the Django side is a source esom so you look

at the source code and then based on the requirements definition in that source code you say okay I know these are your dependencies and I could generate nestum for that but the reality is that unless again all your dependencies all your dependen dependen of pin that is not going to be an accurate spom so the more common way to SPS is to do it at build in your CCD pipeline because then I can say I install Jango and it pulled in all these dependencies and therefore I can snapshot that and say my release has the these dependencies so that's the more common way to do it during your CCD pipeline run you generate this and

therefore you can capture exactly what's running in that and then there is obviously the container side of things and the application side I I philosophically I like to divide the container dependencies for application from the application just for clarity but there's more so you now have your application dependencies for your python project so that might include Django and now we know all the dependencies we build right so we know all the dependencies that's also running a dock container that has its own set of dependen so it might require I don't know you might be running some some wsgi server in there and which has some system packages on now you have two s bombs one for the container and one for

the application and now you need to stitch them all together because you need to represent both sides and ideally without squashing them together because in in es bombs you have different types of you have container ESP bombs you have application you don't want to squash them together because then you lose a lot of the context so if we going for a relatively simple example here let's say we are a manufacturer of smart thermostats sorry smart thermometer well the product I'm selling is a smart thermometer that has a piece of firmware that runs on the device that might be a rust firmware that runs there so I can build spom for my firmware which is the

firmware for the device then I probably a back end too right so that back end probably have a dock contain is running inside you has some py dependencies maybe have no dependencies he probably has some front end but as you can see here on the lower level even in the very very very basic example you now have four S bombs that you need to represent in the tree structure and this is where it gets really complicated when you actually apply real world s bombs so and the other thing to bear in mind is that every cicd run this tree structure changes right so that project we have here that points towards uh one of these

comp that need to repoint on every deploy you do so it's a very much Dynamic object and when you start like emerging yourself the es people tend to treat them as static object but in reality they're really a lot more dynamic because you need to regenerate and every time something changes in the entire structure well then we come to the whole point of security right it's like how can I trust what's at in my esom like you generator right well this is where attestation gets in into the equation and there are a lot of ways to do this a lot of way it's complicated to do it GitHub has fortunately made our life a lot easier because they now have sting

story integration inside of giab actions so you can actually generate a cryptographic s say my machine my build ran on this machine with these specifications at this hour in this data center and you can cryptographically sign that and assign that to youron so that's how you can do it and then in the tree structure mention you then use hashes to point towards a version so you can't just swap out a version because you know the hash of that so you can kind of prevent men Mill attacks and this comes me to the other problem that I quickly realize which is collaboration around s boms because if we assume that s boms are Dynamic and they can change I mean if you're a

modern tech shop like your cicd pipeline you might deploy 20 times a day right every time you deploy that's new so so emailing these as bombs is completely unrealistic right that's just you dealing with outdated data you can't do anything with that and CA published a primary on sharing primary they called on esom of the State of Affairs how do people actually share with as boms and when you speak to the people out there I I did some survey and I spoke to people in C it's like the reality most es I'm sharing today is done over email so they just like oh here's a new release and I email it to my other guy

and that sits in some SharePoint somewhere and it's poorly automated and that is rest of disaster because you don't work with up toate data so the sharing Prime from size are really calls for Automation in this sharing part but those tools are not there yet there are really no good tools for that that's that's why we built spoify right so spify is one way to do this we integrate directly in the cicd pipeline you ship your s bomb there you can Define the structure we saw and then you can share that with stakeholders but we don't be a proprietary like lock in for this so we are working with a cycl DX project called project koala which is

a they call the transparency exchange API and it's basically setting out a standard for sharing es bombs so you can map a physical product against an es bomb so like if I buy a piece of Hardware I can scan the Q QR code and you can get that uh map to anom quick going go into analysis this is a Minefield where there are so many tools very quickly emerging but real quick guac is one of the most popular open source tool for S analysis dependency track is one of the other ones so those are two tools that are really worth checking out if you want to do it but again depends on what you're analyzing

for if it's compliance or security so this is why I get even more exciting because we talk about the structure with s bombs and you build this Dynamic structure and you have an estim for a product but this is really just the first starting point there is a move towards something called OB bombs which is an higher level abstraction where you not only describe the product s bomb because that's only one of these pieces that we spoke about here but you also have an s bomb for your Vex file so the varability exchange you have a spomb defining your Cloud environment so s bomb your cryptographic algorithms like even your m so there are a lot of tools

out there to like this is still very early days like it's got to be years before this actually really viable but there's an really interesting push towards this I think so over the last eight months or so I've emerged myself in eson World join the size of working groups and kind of trying to understand what the State of Affairs are with ESP bombs generate one is super easy as we know but it's not trivial to get to a point where these are actually compliant with the requirements set out by these guidelines and one of the biggest problems is actually unknown unknowns so I showed you this in the earlier screenshot of like this is how

you can generate ason with with uh Docker Scout but in reality it looks more like this so I build my Asom using one of these tools like that could be dark Scout and then I use some kind of enrichment tool like merging that metadata and you're probably going to end up with some really crazy like end Subs here and then you got have a JQ to suck it all together but this is literally like how people build that spons today so it's it's far from like Plug and Play we're still very early days in Desa world and then I hinted at this before this is one of the output we have from the working group so we ran a

benchmark essentially against various tools we sift and trivy some the popular ones but take a look here at unique packages look at cycl DX and unique packages discovered between uh spdx and cyc DX depending what output I specify I find different packages different amount of packages which is crazy we have a 10% over duplication in packages when we scan it with sift so these tools are still very early days like can you do SS absolutely but it's still a very fast evolving landscape so if somebody says s is a done thing they have an actually done as bombs in real world so all right so that's that uh I think we basically have five minutes left for Q&A um so uh

any questions by as boms yes so tools like trivia for example are also uh container security scanners correct ey on the use of the es correct do you think that there's a flaw or an issue with that is therey carry on it yes no because this is the one of the biggest problems in the esom world is because you're relying that esom is complete but if that esom didn't pick up a dependency or like if I copy the binary into my dock container that's not got picked up by triy so it's only as go to data so garbage and garbage out right so that's that's really what it comes down to like I think if we can assume that the es is

complete then absolutely but I think that's a flawed thinking that we can there's there's still too early like there too issues here uh I think Jo you have your hand for I think uh it seems to me like the way we're do is we're just realizing that trying to post generate spawn is essentially a pointless task and I say that because um if you look at that look at the way we're constructing for example's say you go and get your packages from two you're going to get all of the packages are going to have slightly different version you get them from something like the same thing because you have their own tag on the versiones reality the one thing that is

fundamentally missed why you trying to generate once you have received the artifact is what is the environment that thing was buil in what happens if the version of GC was linked by GCC compilation process was po further up screen you've got absolutely no idea what happened if you generate that so really what I haven't seen yet is a really clear way to define like here is here's here's a format which encapsulates here's a set of things that I'm shipping to you in this artifact the set of passes but actually here is something that describes in some sort of forensically verifiable way the build system that was used and the set of liaries and tools that we used to that

and you can't get that fact you have to be you need build yeah so so there are depending what Lounge you're doing so rust and go you can bake those artifacts into the actual uh Esa and that's done by some of the tools but you're absolutely right like it's the hard thing is trying to work out how to distinguish that way so half the if you go and look on Dr you look on um people are SL for example start shs half the S boms so if you look at it some of them are like three times the size and it's because there's this lack of understanding some of the basically encapsulates everything the system may

not but that's that's the thing like is is a build AR relevant or not because you can't binarily say that it is or not isn't right yeah exactly so but yeah like that's these are the nuances when you get into like actual imp the ESP boms you're like actually I can't fully trust that because it may or may not be relevant and that's I guess the point I was trying to make was do you see any there be lots of people running around at the moment saying oh my goodness for my things I guess the I'm trying to make bit of a waste of time at the end the day you agree with that I don't think

it's a waste of time because you're still racing the bar like yeah you you still might capture everything but you at least capture maybe 80% or 90% right you're you're rather buing more infantry of what you've got in your environment rather than necessarily generating correct yeah so I think I think it's still I agree that toolings are not there but that's a tool chain problem more so than eson problem I have one question here could there be an issue where in countries where it's not legal standard companies with this software not wanting to produce an because they don't want to reveal what technologies went into the software so that's the million dollar question because that's

the reason why the executive order was such a big Tipping Point in their spumps because all these big vendors were like all the sudden like oh we need to do this it is not like an optional thing and that's there executive order doesn't mandate you need to make them public accessible and that's a big debate in espa community should we make all esos public right and I don't think it's realistic that ever going to happen anytime soon but it's going to be on like on a need to no basis almost and if I'm what I'm anticipate to happen is it's going to become part of compliance and bigger buyers we say well either you ship an ESO with your product or I'm not

buying from you so that's how I see that's kind of playing out but yeah I I think it's going to be compliance driven and or biod driven but kind of related yes so I do work for a company that sells to US Government big Tel got loads of old software yeah so yeah we had no moments um but um where do you see the bigger players you talk about um sneak most people but this BL du been for Don years there's men sour quite some time where do you see them playing in this space so I think it's very industry specific so like for instance one thing that I wasn't aware of going before I dove into the ESP was like how

sophisticated the US medical spaces for instance they are the one that actually driving a lot of the Innovation and like standardization bodies around their boms so they're actually doing a lot of interesting work around there uh but they have a play like black duck yeah they they're a big player no doubt um but I think they they have a different audience than what I tend to see uh because I mean m&a is a big thing for black duck for instance to do like due diligence for for um software uh that's one of the big things they do but I I don't think these tools will be like the mainstream tools like they will be Niche for like very

big buyers whereas the tools that I'm sharing here are more the tools that would be more generally adopted I would think yes questions what do you see um software manufacturers moving to SAS to avoid s boms and is the standard looking at SAS SAS bombs so so SAS bombs is for the runtime not for your software so regardless of how you deliver your software to the government it doesn't doesn't matter if that's if that's an on Prem service or delivered as a service you still sh an ESB so it doesn't actually change the equation do you have time for one more question or we didn't no we had of time oh sorry all right thanks oh

yeah slides will be up there are some there are some good resource here so slides will up on vp.com there is a QR code to scan if you have time for a a deep with the father rest bombs uh that I did on my podcast