PG - Demystifying SBOMs: Strengthening cybersecurity defenses

hello everyone I hope you're having a good time since morning ATT ending talks there's another one from us it's on as bombs and I'm har oh I'm kti I work as an application security engineer she's my co-speaker harini hi everyone um I'm Harin Prasad uh I work as a product security engineer um we just thought as bombs are a cool topic and hence hope you agree with us at the end of this um yeah um just a disclaimer that any opinions uh expressed here are purely our own um not related to anything U any views of our employer uh but yeah with that said let's get started so I want to start off by asking you all a question do you

really know yourself yes no maybe so don't worry I'm not going to the philosophical side here probably worth another time but uh yeah knowing yourself in the context of uh the software you build and the software you use so for example um do you really know what programming languages are being used what third party dependencies are being leveraged what risk do they carry um does your use of those dependencies really meet compliance requirements and so on so this is also being emphasized by the CIS controls yes one and two and um they're about inventory and control of Enterprise and software assets so why is this reflection exercise more than important today so this has become really

important in the light of software supply chain attacks now these are attacks where B actors are targeting legitimate thirdparty software vendors um software that is widely being used in the supply chain so take for example maybe like a popular JavaScript library which is used by 100 hundreds if not thousands of organizations now if you think what would happen if such a library is compromised the blast radius and or the impact of it is going to be massive it's not just going to be limited to just one organization so software supply chain attacks have become truly a pain to deal with unfortunately there are many examples of this in recent times uh the biggest one I guess you all may recall is log forj

this is a popular uh Java Library used for logging and attackers discovered a vulnerability through which they could execute code on your servers uh the most one of the most difficult parts of remediating a vulnerability like this was actually identifying all such usage of that vulnerable version of that library and making sure you patch all usage and do not leave anything out and if you think about doing this in a huge code base if you don't have the right tools to do it it's going to be really uh pain taking the other example um is the xie Library you know had it not been for a curious developer was looking to debug a performance issue right a

malicious very stealthily written code would have been shipped to so many Linux systems essentially enabling attackers to have a back door on those systems so we can see how devastating that could have turned out so all just to say that it has become incredibly important to record and track information about what our systems and software is made up of so jumping to what is espon right I mean to State simply it stands for software bill of materials and that's an example is Bomb um there but what is it really right so it basically does what we talked about before which is it lists all the component parts and software dependencies used so names of components

the version information the supplier information if that's available essentially you can think of it like the ingredient list U so let's say you're going to the supermarket to check out that new snack that your friends recommended more often than not you're going to look at the ingredient list and see if there's anything funny out there that you may want to avoid and overall make a decision whether it's good for you or not so as bombs are kind of like that if if you want to think of it that way it's not it's not merely just an inventory list but it goes a lot more than that and and it can help you assess whether a particular software

component really aligns with the level of risk you're willing to take so it has become an essential tool in software supply chain security remediating vulnerabilities and in compliance efforts as well and essentially it's a huge step towards transparency right uh now you have a a better idea about what a software component is made up of so this is really huge step for both producers as well as consumers of software so let's talk a bit more about why do we need s bombs so firstly open source software is everywhere um to quote a recent study that showed that U an average software project has more than 200 dependencies now when you think about tracking vulnerability information

which may be present in those dependencies fixing all of those and um making sure you still meet like compliance requirements you can see how it can get complicated really fast I hope your project doesn't look like that but it's kind of the reality for most so like we talked about before s bombs can help you comply with your business risk appetite it also helps a lot with mitigation efforts because now many new vulnerabilities out there you can identify what parts of your software make use of that vulnerable version and you can Target your efforts accordingly so it definitely helps in fostered adoption of any mitigating controls or measures available so that you can lower risk as soon as you

can and it's been largely supported by the government as well so in 2021 the US government came up uh released an executive order uh for nist to come up with a set of best practices on using S bombs the cesa or which is the cyber security and infrastructure security agency has also released a lot of educational resources for organizations to understand as bombs and adopt them in their software development life cycle so basically we want to avoid the shock of discovering the ton of vulnerabilities that came with the dependencies you used and taking a more proactive approach on that so that was a fair bit of talking from me now I'll hand over to kti uh to

talk more about how can we get started with generating asps okay so we talked about what are as bombs why do we need them now let's get to what like how do we actually generate these as bombs so there are various tools in the market there are some open source tools provided by trivy Anor oasp and uh there are some vendor based tools and Frameworks but how do these tools actually work so they scan the application and when I say they scan the application by that I mean they are actually examining the artifacts and any Associated sources such as the manifests metadata lock files source files your binary files and uh we can have this

generated in three different formats like there are three different formats available which we can use to generate this document uh we're going to be talking about the two formats but before that we're going to talk about what these formats basically are these formats are basically the composition of data you're looking for you choose a format format based on your needs and what is more acceptable with your current environment like what is already like the tools that you're using how what would be more compatible so there are two tools which we're going to talk about today spdx and Cyclone DX uh spdx basically focuses more on the software packages and your package level licensing wherever whereas uh if we see

the Cyclone DX it focuses more on the software components the authorization and external API now what we're going to do is we have a pre-recorded demo for you we're going to go by the demo we we will see how we actually generate it generator s bomb and we will be using U anor's open source tool called sift that screen

okay so that's the demo basically give me a minute yeah it paed is it working yeah it's clean the screen are not working this is not working but I want so sorry uh okay sorry uh yes and play that again now okay so that's where we'll begin the demo and what we're doing here is we're going to generate thebomb and now we and after that we'll see how we can use that s bomb to actually manage the vulnerabilities we're going to pick up uh commonly used image inine X image and use Swift as I mentioned so that's the command that we're going to run and uh we are going to produce it in the cyclon

DX format that we defined and uh write it to a Json file so when we run this command a file gets generated you'll see it come up yeah so that's the file on the left side you see that's that's actually the s bomb that got created and uh it's the cyclon DX format that's how it looks and it has three major sections the metadata uh the components and dependencies metad data is actually what contains the information about the image and uh component is the one that contains the information about the licensing and the packages and the dependencies is all the package all the dependencies of the image like the package dependencies there's a whole list of it that you'll

see here now what we want to do is as I said that we'll use this sbom for vulnerability management we'll run this sbor through a vulnerability scanner and uh for that we're going to use a another open-source tool which is also available by Anor that's called gripe that's the one that we're going to use and uh when we run this uh gripe command we're going to get a list of vulnerabilities as you see there and uh it'll have like what's the severity what's the vulnerability and uh if that could be fixed and the once which says won't fix it's either they have reached the end of life or uh there's no fix available for those ones

so we have to look for alternative Solutions so this was like a table format but what if we want just one comprehensive document so what we do is we again run the gripe command and create a new as bomb that will contain in the uh vulnerabilities section now and uh to do that we run the another command and write it to another Json file which will basically create a new as bomb that would be like the same as bomb that we created but will have another section we'll just see it now so we see another file got created and uh it has exactly same data as the previous one just one section got added the

vulnerability section and and uh it's the same that we saw in the table but in the Json format like it it it becomes like a one document more readable and easy to access so grip PA is just one example that we used but there are different vulnerability scanning tools as well outside that you can use and uh integrate your sbom so yeah that was the demo and now we'll move ahead to the use cases so how do we actually use that file that we created right now that can be used in many ways because an es bomb is a file that can be used for managing vulnerabilities that we saw and handling licensing compliance issues swiftly

pinpointing to the dependencies and supply chain threats in the software or its components you can make it a part of your sdlc life cycle integrate it with your vulnerability scanner just as we saw which will help improve improve the sdlc posture improve perform a better security analysis more targeted security analysis to be more precise and uh give more transparency to the stakeholders and verify the sourcing now if we talk in the terms of supply chain like securing the supply chain so the sbom gives us an ability to be proactive with the supply chain to identify and Implement alternative Solutions uh or remediations if there's a threat or as we saw like an end of life is nearing so these are the use

cases and uh this all looks good but now what we're going to do is we're going to come up with like a small example like we have a small example it's a very very basic example I would say just to provide an idea if we have a production running and we want to include a third party component to it so we want to assess that we cannot just integrate to our production we want to assess that so to assess that and ease out that process we generate an sbom and we get a comprehensive document we can make it a comprehensive document just like in the demo we added the vulnerabilities we can add the data as we want and we can have

it produced in the format that we're looking for so um let's say we generate a s bomb here which will help us plan the risk management strategy and going forward we do the implementation integration and testing and finally we are at the deployment stage we are at the stage where we have successfully deployed it uh so we can say like a post- production stage at this stage if we create like if we generate an s bomb that will actually help us manage the vulnerabilities like like that will help us stay up toate and perform like timely updates and thus reducing the risk of potential uh threats it could be anything like normal upgrades tocade XYZ vulnerabilities or

uh look for different Alternatives could be like a warning or like a severity is low so just before it reaches to a critical level eradicating it and um so what was the main point of this example was what I was trying to say in the use cases that these as bombs can help us identify and address the severity of security vulnerability or patches related to the software components and not just help us comply with the licensing or the Frameworks that n offers CIS offers that is one thing but it could also help us in a different way so you can generate this as bomb using the source code during the bill time during the run time or during

the foreign sing on the software over to you harini so yes uh to summarize with some thoughts um we saw how s bombs can be really helpful to know your assets better uh to understand your software's components we saw how making s bombs and vulnerability scans as part of your cicd pipeline can really help shift security left uh but not to say that it's going to be a very easy ride ahead in your as bomb Journey uh there are some challenges we anticipate so firstly identifying all components accurately in itself could be a big challenge if you run different sbom tools they may give you different results depending on how that esom tool works so for example a

tool may just look at the Manifest files but that may not give you a really accurate picture of whether the library was actually used in code so you may have to try out different tools to see what fits your software profile the best second is integrating vulnerability information now once a product is released and you know it's up there in production the sbom which has the component information can be considered like fairly stable but the vulnerability information about the components the dependencies used that is dynamic because as in when new risk is being discovered uh you would have to make sure you're updating that vulnerability information and tracking it accordingly so that could be a significant step and

uh last last but not the least is exploitability of the vulnerabilities now when you have a huge list of vulnerabilities to fix uh how do you go about prioritizing right so exploitability becomes a big factor there and hence you know tracking uh vulnerability information along with exploitability uh exploitability tag would be really helpful when you actually go about uh looking at the list of vulnerabilities and fixing them in this regard uh I think the vulnerability exploitability exchange a document we didn't go about it in this presentation but it does seem like an interesting uh solution available right now uh for companies to track this information better so uh I would encourage you all as well to look into it if you haven't

uh with that I think we're at the end thank you so much for listening to us uh we hope you learned something new connect with us on LinkedIn you can reach out to us after for any questions that you have we taking questions offline and a big shout out to our Mentor vade Wells so thank you for helping us you guys