Hello, everyone. thank you for joining me at DevSecOps 2024 by CON42. In this talk, we will be discussing about Software Bill of Materials, aka SBOMs. But before we dive into the topic, let us get the introductions out of the way. My name is Safeer. I have been in the SRE and DevOps 19 years. I'm an author, speaker, and an ambassador for the Companies Delivery Foundation. All right. So let us set the stage by recapping our understanding of DevSecOps. The DevSecOps framework improves SDLC by detecting vulnerabilities throughout the software development and delivery process. It merges the security into DevOps practices and shifts the security left. So what are the benefits of DevSecOps? You can catch the software vulnerabilities early, ensure that you have regulatory compliances, and improve performance. So what are the benefits of DevSecOps? build a security aware engineering culture, and develop new features securely. When we are talking about security in SDLC, a key concept we should learn about is software supply chain. Now the term supply chain refers to people and process for making and distributing a product, typically applied to manufacturing. In the context of software supply chain, It includes people, processes, and software components that touch your software development lifecycle, starting from the source code, all the way up to your software deployment. Now, what makes software supply chain special? Almost no modern software products are built from the ground. They are always built on top of existing software, predominantly open source software. Now, it is this that Dependence on open source software that makes it both powerful and work. software supply chain is a complex mix of technology, people, process. And that introduces a large number of touch points. And for threat actors, these touch points become the attack surfaces to infiltrate the software supply chain. Now, a crucial issue with supply chain is that, this chain of open source dependencies are outside the control of the software developers and the organizations that build the final product. Now, this limits their ability to improve the security of these dependencies and the infrastructure that holds these dependencies up to us. The reason why, supply chain security is very critical is that Compromising, even a small component in this ecosystem can have a wider and catastrophic impact. To drive this point home, let us look at a few attacks on software supply chain. So there are some, surface, so these are some software supply chain attacks. there are actually a lot more, I just checked a few of them to show you the variety of attacks. So first one is even stream. In 2018, so an attacker published a new NPM package called FlatMapStream with no malicious code. A month later, it was added as a dependency of the EventStream package. And another month later, a malicious version of the FlatMapStream, which was a dependency, was published. And the issue was detected only after 8 million downloads of the affected software happened, and it infected a large number of systems. in 2020, SolarWinds attacked. what happened was, attackers injected a backdoor into the software update of SolarWinds. Now, SolarWinds is a networking software, that is used by, big companies, as well as government agencies. Now this backdoor allowed attackers remote access to thousands of systems across the world from every client who would have used the SolarWinds software. So the affected organizations included Intel, Microsoft, Cisco, and even a number of U. S. government agencies. The third one is Kaseya. So attackers compromised this platform, infecting with ransomware, which then deployed together with an update of the software. Now this ransomware spread to thousands of customer environments, and, attackers were able to extort more than 70 million from the effect customers code. Code. So an attacker infected the code bash up letter, which is, part of a code coverage testing tool that. automatically sends customer reports. By injecting malicious code into this grid, the attacker was able to eavesdrop on the quad core servers and steal customer data. And the most recent one is exit utils backdoor. So malicious backdoor in the exit linux utility was created, which is giving backdoor access to And that backward actually, gave remote, execution privileges over some versions of OpenACCESS on the target systems. Now, these are like, again, very few number of attacks that I have quoted here, but this should give you, an idea about the variety and the impact of such attacks. So, test points are, these are the test points where the attackers can exploit vulnerable parts of the supply chains. And as you can see, from the list of the left side, it covers the entirety of your SDLC. Now on the right side, what you're seeing the attack vectors and you know how an attacker can exploit some of the vulnerabilities. for example, third party components, so malicious actors can. Target third party components like libraries or frameworks and search for opportunities to insert malware into them. Compromise development tools. Again, tools like compilers, build systems or other development tools. Again, try to, inject malware. Developer accounts. This is quite common. Many users can try to exploit vulnerabilities within developer accounts. Could be in, hosted core platforms like GitHub or GitLab Compromise Software, updating processor. Now, again, actors frequent target, this kind of in, software updating processors to, compromise and insert malware and into software updates. Social engineering, again, attackers can try to, contact employees and, make them in order to, Give up their security credentials using social engineering. So how do we prevent and mitigate this kind of attacks? four phases of it. One is protecting the source code integrity, because that's where everything starts. code signing can protect source code integrity. there are a number of standards for signing and attestation of code and artifacts. Now, mitigating dependencies, requires that you know about the dependencies of your software and continuously monitor for the vulnerabilities. And for, your build and deployment infrastructure, again, improve the security in terms of, whether it's exposed to the internet or is there any opening points which, attackers can exploit. Things like that, securing the entire infrastructure is important. It should always be a high priority for DevSecOps and DevOps. So far from whatever we discussed so far, one key takeaway is that a number of DevOps and DevSecOps responsibilities revolve around the software supply chain. And protecting the supply chain will be a major part of DevSecOps responsibility. And one of the most important steps in protecting supply chain is to understand What is in your software? Because if you don't know what is in your software, you cannot protect your software. So figuring out what are the dependencies that goes into your software is very important. And this is where software bill of material comes into play. So bill of materials is a common thing. it's mostly used, it's used in many industries, even in constructions, manufacturing, and a lot more. Okay. So Bill of Materials is an extensive list of raw materials, components, and even instructions required to construct, manufacture, or repair a protected service. So there are manufacturing BOMs, engineering Bill of Materials, etc. But in the context of software, an SBOM, or a Software Bill of Material, includes all software components that are used to make a final software product. The SBAR will introduce, details of the software version, patches, dependencies, vulnerabilities, licenses, etc. Some of the key, benefits of software build of materials, one is component transparency. once you have an SBAR software, it offers complete transparency into the components used in that application. which helps identify potential security vulnerabilities or licensing issues related to third party dependencies. Vulnerability management. once we know all the components and their versions, and, organizers can quickly identify if any part of the software is affected by non vulnerabilities and take appropriate remediation measures. Think of the log for Shell vulnerability. Any organization that had SBOM at that point in time would have been able to quickly protect them because they would know which all components in their software infrastructure would be impacted by the law of forced vulnerability. Compliance and risk assessment. S1 means in, complying with industrial regulations and standards that mandate transparency and disclosure of third party companies. It also helps in evaluating potential security and legal risks associated with the And again, general supply chain security, it enables organizations to better understand and manage their software supply chain, reduce the risk of, supply chain attacks and ensuring that components and, are sourced from, trusted sources. Again, You don't just manufacture one software, you will have a number of software that are deployed. Some might be open source tools, some might be infrastructure tools. Any company would have a number of softwares and managing all of them And processing them. Obviously, you cannot process them in a using humans. So which means It requires automations, right? So it is imperative that you should have standards for SBOPs And as you can see it helps you with interoperability automation and adopt industry based practices. let us look at some of the standards in S4. So the current industry standards are Cyclone DX and SPDX. we will look into them in a bit more detail in the next slides. so in addition to the this to explore, standards, there are also a few other standards that help in naming and describing softwares. So they are, software IDs. it defines a structural metadata format for describing a software product. Common Platform Enumeration or CPE. There's a standardized method for, for describing and identifying. Class of applications, operating systems, and even hardware devices present in an interface's computing assets. Package your, PURL is, it's a URL string used to identify and locate a software package in a, universal, way across programming languages, package managers, packaging conventions towards a p and database. So, let's say know you have a machine, water softwares are installed on it, whether they are, RPMs, DN packages. For java packages, and anything of the sort, everything can be, represented using a package URL. So let us, come to one of the, SBOM standards, that's SPDX. So SPDX is essentially a software package data exchange. And it was, Linux software, Linux foundation that, developed this in the early 2010s. So it's focused mostly on compliance and licensing. And it's, the latest version is, 3. 0. 1. one thing about SPDX that is very comprehensive. It not only lists packages, or its licenses, it also, lists files used and code snippets sometimes. So this actually helps in, getting a well rounded view of what our components are there in your software ecosystem. And it has been around for a long time, from 2010. And it's already used by many industries and products, including automotive and the healthcare industries. Cyclone DX came from OWASP. Anyone who is into security would know about the OWASP Foundation. And actually their core focus is on vulnerability and security. And it is used quite widely in a lot of software organizations. And the latest version is 1. 6. So SBOM classification, so SBOM can be generated at various stages of your software development lifecycle. And it has different classifications and purposes. CISA, the U. S. Cyber Security Agency, classifies the SBOMs into six categories, as you can see. there's design, source, build, analyze, deployed, and runtime. And, you can see the, description here, it's quite self explanatory. . So again, the software bill of material can be generated all these stages depending on it, whether we are building a software or you just bought a software and, things like that. But there are also other types of classifications for bombs like SaaS, bill of materials, machine learning of materials, hardware, build of materials, et cetera. let's go into a short demo of generating an S om in Cyclone DS format, and then look into the data in sbo. All right. so there are a number of tools which you can use for generating software bill of materials. We are, using a utility called SIFT, which is from the company Anchor, which is a security company. And what we're going to, so there are, again, S1 can be generated from any sort of packages, software, even, just a directory within your patch system. In this particular case, we are going to Directly fetch the alpine docker image and scan it and generate a software build of material out of it. There is no additional software installed. This is the plain vanilla alpine image. And again, if you see the CLI options, we are giving it, the cyclone DX JSON format and save it into a file called alpine. cyclone. json. As you can see, it fetches the image, doing some cataloging of all the softwares. Looking at, file metadata, file digest, et cetera. It looks like it is finished. So let us, start examining the json file. We'll start with the top elements that, this file has. All right, you can see schema, bomb format, components, dependencies, metadata, serial numbers, spec version, version. So if you go to the, actual, cycle only specification, that I had given in the previous slide. There's a lot more, elements within the Cyclone DX format, but, a lot of them are optional. if I remember right, there are only serial number and spec version which are compulsory, and everything else is optional. So this gives a lot of freedom for, people to generate S forms as, as they require. But, again, if you want to know more details about what each of these components mean, you can actually visit the specification. Now, let us look at some of the basic information. schema again, points to the actual schema website. The BOM format, obviously, is cyclone dx. And the spec version is 1. 6. Now, the other things are serial number and version. So, the standard, SBOM standard mandates that there should be a serial number. Which can uniquely identify a particular sbomb file and whenever So let's say, you are right now, we have targeted alpine docker image right now Let's say after where the docker alpine docker image changed And you have the again generation sbomb then it should have a different version It could be you know, it will start from version one and version two and progress like that So you are most important things to remember you have a cl number and a version Now there is a metadata dictionary within the Cyclone DX. If you see here, it, talks about the software itself and how it was generated. So the timestamp is the time at which the S Bomb was generated. And the tools used for generating it. Again, I don't know who's the authors. It's from Anchor. The utility name is SIFT and uses the version 1. 170. And there's a component here. So this component actually displays, what is the software for which this S BOM is generated. And this obviously is Alpine and it's a type container. And what you see here, BOM reference as a string. So in the, in, Cyclone DX, format, a BOM reference is like a unique key or a primary key for any software component within that particular document. Okay. Now, you could use this reference ID to refer to this particular component in any other part of the same document. That is the whole idea of BOM references. You will see more BOM references in the upcoming portions. let us look at components. Components are nothing but these are the actual software components that the SBOM utility detected and added into the SBOM file. So what you can see, sir, now, it actually generated 15 components. remember that is a very lightweight image and it has a very limited number of software changes, and that is you are only seeing 15. If it was a, large, Docker, image with the bunch of files for, code, this would've be totally different. So let us, we know that there are only 15 components, so let us, look at what are the. Components that, this file has. So as you can see, there are again 15 packages. And what I have listed is the package name and the type of the package. So for S BOM, most of the packages are considered as libraries or dependencies. and it also detected Alpine as an operating system. So these are the 15 components within this S BOM. Now we'll take a look at one of the packages called s SR client. So for this package, so there's a lot of information for per package in an S one. So properties is one, element, which is quite long. We will see that in the next session. before that I want to show the rest of the components here. So if you see here, again, there's a bone reference, which is the unique key for this particular package called SSL client. Within this document. So that is what bomb reference is and you can see that it has a particular format The type is library obviously and the publisher is the author of the software and the name version description everything is Gathered here and one of the important thing is it also lists licenses and it is a gpl2 version one thing you have to Know about this structure is that it says licenses not license The reason is for open source software, it might be built from a bunch of other softwares and they might have varying, licenses. And that is why the provision is there for adding a bunch of additional licenses that might be applicable to the software. And if you remember, we had discussed, known SBOM standards, CPE, BURL, et cetera, SWDID, all of them. this system actually uses CPNP URL for, referencing to some of these components. External references, whenever a tool can find some information about where this software came from or, where the documentation site is or whatnot, it will be added as an external reference. Let's look at the properties, property of the, this, particular package. So there's a long list of, items. we will look at a few. So again. How did, how was this package discovered? APK DB cataloger is a component of the SIFTS utility. Nesmo utility will have a bunch of catalogers, for different type of softwares. And this actually found out that, it's an APK. And the package type is APK. And, some of the other important things are, the size of the package, some of the dependency lists, and what it provides, et cetera. And the version, things like that. Moving on, I talked about multiple licenses, right? And, there is, the package that we saw had only one license. Let us see another package. This is special. And I took it from, another S bomb that I, generated earlier for Kubuntu image, the basic Kubuntu image. And the license we are looking for is for the package bash. You see here, bash has a whole bunch of licenses attached to it. PSD, GFDL, GPL, Latex2V, MIT Lite. All of them. So that's why I was talking that is, why, when you are looking at license compliances, not just security, SVM also helps you with license compliances to see whether, you have possible legal issues in terms of license violations or anything like that. So that is why this licensing part is very important. Again, let us, so we looked at components as a top level element now, and there is another top level element, which is dependencies. Dependencies as the name suggests is the dependency between the components that we saw already. Now there are 10 entries for dependencies here. And what we are going to do is pick just one package for the time being and see what are its dependencies. You see here again, there's a reference. So basically we picked the dependencies of the SSL client package and what you can see is it depends on three other packages. And if you see here, all of them are bone references, which means you can find these packages within this SBO file. Now, since you know what packages are in your SBO and what is avers, it's always possible to look up into external vulnerability database and figure out whether this package has well , and that is one of the, of having an . And to do that, we are using under CLA from the ancor com. it's another CLI to which you can feed this, S BOM file and Accur will go online, sorry, GRIBE will go online, talk to a few vulnerability databases and figure out is there any, vulnerability in this S BOM, packages listed in this S BOM. So let us do that. All right. Created a report called alchemy. gribe. json. So all the autoresponse it gave is here. And what we're going to do is, I know that, it has formed a few matches, so I'm just picking one of the matches and some of the information about that vulnerability here. Give me a second. Sorry for that. it looks like there is a slight problem. Give me a second. All right. it looks it didn't work out as I expected. Let me just try to troubleshoot the slide. All right. My bad. I think there was some system was hanging for a bit, but you can see the result now. all the vulnerability we picked is for the package libcrypto3. the vulnerable version is. 3. 3. 2 R0 and the vulnerability is CVE 2024 9143. It has a medium vulnerability category. And this version is basically showing that, This is the fixed version of this particular package without this vulnerability. as you can see, this is only limited information. If you look at this file, actually, if you generate this file, you will see there's detailed information about what is vulnerability, what are the artifacts impacted, et cetera, et cetera. I just, some information to show you what it can do. All right. And again, you could use any tools. You will get, similar results. And this helps you in finding out what packages in your system has what vulnerabilities and mitigate them Now just to show you about the dependency, we'll do one more thing. I am Picking up all the dependencies from this sbomb and plotting it as a graph All right As you can see There's a lot of dependencies, as you can see. If you see, PK2 has a bunch of dependencies, Alpine based layout has two dependencies, SSL client has three dependencies, like that. And the dependencies might be depending on some other different software. So there is going to be a multilevel dependency here. And just to show you that, let me actually pick a package called Alpine based layout from this SBOM and show its dependencies as a graph. All right. So as you can see, Alpine base layout is the package. And it has two dependencies. One is alpine based layout data. sorry that it's not showing the entire package name here, but that is one of the dependencies. And the second dependency is bcbox bin assets, which in turn is a bcbox dependency, which in turn depends on the muscle library. As you can see, this is just to show you that, when you have a package, the dependency is multi legged. And with this dependency information, You can actually put the entire dependency and figure out if your software has some upstream dependency or, in some, by, at the level dependency, which could have vulnerability or other legal issues, right? So that is the power of having an SBOM. Now with this, let me wind up this demo and get back to the presentation. All right. So with this knowledge of SBOMs, what should the DevSecOps do to adopt them? See, SBAP is a new topic for most of the engineering. understand them first and then assess and document the use cases within the organization. And if necessary, evangelize this to the rest of the organization. And to do that, evaluate the tools, for, creating and managing SBAPs. There are a lot of open source as well as vendor tools. Many of them are SaaS products. so once you pick the tools, integrate them into your, software development lifecycle and automate SBOM generation. You should have tools that will help you, save the SBOM data and analyze them. And also remember that this is not a one time task and should be part of your SDLC and the continuous process. So to analyze the data, make reports and share it with the right stakeholders, might be your engineering counterparts, leadership, or security team. And also set alerts and reports on vulnerabilities, license components, et cetera, so that your security posture improves. With that, we are coming to the end of this presentation. If you would like to know more about SBOM, these resources will help you. So the OWASP authority to get SBOMs is extensive and it will give you a good idea of what to do. Cyclone DX format as well as the general information about Sbomb, how to go about that option, etc. And if you want to know about Sbomb tools, Cyclone DX tool center is actually a good starting point. Of course, it is, it doesn't cover all the tools that is out there, but it gives you a good starting point. I hope you were able to get some value out of this and thanks for listening.