Okay, so, yeah, welcome everyone. Good morning, good afternoon, or good evening from wherever you are. And this talk is going to be about software composition analysis 101, knowing what's inside your apps. So just to give you a little bit of overview about me, as jobing said, I'm an information security specialist. I've been doing apps back and also devsecops lately for at least over ten years now in Upsec and Devsecops, like five years, I've deployed multiple SaaS dust software composition analysis solutions, right. Currently I work as a cloud security research and kind of integrating my application security skills with cloud technologies such as different cloud services, kubernetes, Docker and all that stuff. I also have a blog where I try to share my articles at least once a month and also there is all my contact information and my previous talks. So videos or slides, talks that I've given since 2011, it's all there. So the agenda for this talk, right, we don't have a lot of time. We have a little bit, 30 minutes, right. So we'll try to cover what's an SCA, what's a bomb, like a buff materials, right? And what's an ass bomb. Before we dive deep into what is software composition analysis and how it works, I'll show you some numbers, right. Why should you, as a developer, right, as this event is targeted for developers, why should you worry about that? Right. Why should be your problem and should be your concern as well. And then we're going to talk about supply chain attacks. And one of the main reasons that they happen is because of open sources, libraries and dependencies that can be compromised. And then we talk about best practices and some software composition analysis tools. If we have time. I'll do a quick demo here. So, yeah, what is SCA, right. So if you work in apps, you probably have heard about SCA by now, but it's kind of a new term. At least when I joined UpseC over ten years ago, people didn't talk about software composition analysis, right? So we talk about has and dust and that was it, right? And I think over, I don't know, five years ago a little bit more that we started talking more about it. But it's not a new thing, it's not a new term. It's been around for a while with different names around like library analysis, open source security, third party dependency. Right? So there's different names, but now kind of these term, I think was coined by Gartner is software composition analysis, right. To analyze what components are part of your software, your application and checking if they have any public known vulnerabilities, if they are outdated, if there is any risks for these business, even legal risks regarding license purposes, right? So SCA is aimed at providing the open source software with governance, security and, and what does that mean? Provenance, right. You need to understand whats sometimes you're using libraries and code on your applications from people that you don't even know that they can be on the other side of the globe and sometimes they might not be trustworthy, right. You might not be able to trust them and inject or import that code into your application, especially on enterprise applications, right. So one of the things that software composition analysis tries to address is understanding the software bill of materials, right. And we're going to talk about whats in the next few slides. So what does it mean? What do you need to perform a software composition analysis, right. So mainly these things that you need to do and that's kind of given across the board on major SCA tools. You need an application manifest, right. Giving trucks on how the software should work. You need a dependence metadata which shows what are the dependencies that you have in your software and the versions of those dependencies, right. And the last thing that you also need is the vulnerability data source, how you're going to compare. If the library that you have in your code is outdated or vulnerable, you need to compare with something, right? And so that is the vulnerability data source, which is a database of vulnerability information. It can be private or public, right? The most common public one is NVD or the national vulnerability Database. But we're going to see that usually that's not enough. So yeah, I talked about software bill of materials, right. But let's back up a little bit. What is the bill of materials? Right. If you've done any kind of research on engineering or product design, you know that a bill of materials is a list of materials that creates a product, right? So let's say if I have my chair, right, whats do I need to make that chair? Like, okay, I need my wood, I need my kind of these seat, right? So I need foam, I need some kind of thing to cover the foam and stuff like that, right? So you know what you need, you know the quantities and how much they cost usually. So that you know whats is the price of making that chair so that you can add to that for like, okay, what is the price that I'm going to sell it, right. So it's kind of like that. So this is an example of a bill of materials and with software, we have the same thing, so we call them has bombs or software bill of materials. And with s bombs they are not very different from bill of materials in real life. They're a list of components in a piece of software, right. It's usually okay. Mostly the dependence is the libraries that I import or I use in my code, right. So nowadays nobody code from scratch. You usually have frameworks and libraries that are made of open source and sometimes commercial components, right. So SBom is very similar to the components in a product, right. So when you buy a processed product on your supermarket, you're going to have the ingredients. So it's kind of the list of ingredients in a packaged food, right. So that's the main thing that software composition analysis tries to analyze and understand and make sure whats those components are up to date are not vulnerable and are according to the licensing that you need and you want on your software. So there are some major resources, these for SBom. There are some standards as well, with everything. There's different standards right now, but I think they are kind of the most common ones that I tried to show you here. One of the most famous ones is Cyclone DX, which is a lightweight software built material standard and it just became a flagship, a WaSp flagship product last month. Right. So that's very interesting and I think it's going to be very helpful for OWASP and the developers who use the OASP resources. There is another standard called SPDX which is an open standard for communicating software buff material information and it belongs to the Linux foundation. Right. So that's another common standard that's being used as well. And we have dependency track. So you probably have heard about OAS Dependency Check, which is a famous OAS project for checking vulnerabilities in your libraries. But dependency track, it might not be as famous as dependency check. Right. So dependency track allows organizations to identify and reduce the risk of these software in the supply chain. So it helps you track your s bomb and track any kind of dependencies on your software. Okay, so why you're telling me this, right? Why me as a developer, if I'm talking in a developer event, why you should worry about it, right. So here I brought some numbers for you. 84% of the code bases had at least one vulnerability with an average of 158 per code base according to the open source risk analysis report done by synopsis, I think last year. Yeah, last year. And another thing before they compared in 2016, can average of 84 open source components per application was found on the software that they tested. Right, and nowadays, like last year, 2020, there is an average of 528 open source components, right? So it's a huge increase and it's very hard for you to track and validate and analyze all those things manually. Right? So you need a solution, you need something to automate that for you and at least try to cover outdated and vulnerable libraries in your code. There is also a great study, and I think was presented by earlier in this event from snake talking about the state of open source security report, which is really good, and I recommend you taking a look and it shows the number of new packaged biochem per year. You can see right away here that of course Javascript or NPM packages are very high compared to the other ones, but there's been an increase on packages and libraries and it's hard to keep track of those, right. And you don't know the provenance. So that's the problem here, because anyone can submit a new package. So just like kind of like the App Store or the Google Play, you can submit a new application here, you can submit a package as well. And people will start using if they like it, right? And they will start importing their project, right? So if they don't know you, if you want to do something malicious with that package, once it starts propagating to many different applications, that's possible to happen. Right? So that's why you need to keep track of those. Okay, so I don't know if you heard about this and just one more data for you to understand and probably try to just kind of worry a little bit more about this problem, right. This was presented by Mark Curfe, which is one of the founders of OASP, and he's also the creators of a company called Sourceclear, which is now port of Veracode. And he presented this code cocktail, right? So there is many studies around that kind of the open source security space on how much is open source part of my code, right? And so there are some studies showing that between 70 and 90% of your code are made of open source, starting from libraries, frameworks and everything. So kind of like ten to 30% is your custom code, whats your developers make. So you can see right away that the attack surface of your application, it's much higher on the open source and on the third party code than on your custom code. So that's one more reason that although yeah, you should worry about SAS and Dast, but software composition analysis can be really important sometimes and can coverage maybe a larger attack surface depending on your software, on your application, your code base. So that's why I presented these numbers for you to be aware of that. And there is another issue, and I think was mentioned earlier in this conference as well, right? You have the direct dependencies, which is the libraries and the dependencies that you import, right, in your code, but there are some indirect or transient dependencies and that's even a bigger problem, right? So I have a library whats imports another library from a third party code. And that library that was imported is the one that's vulnerable or is outdated, right? I can't update whats library until my library that I imported directly gets updated and calls the new version of that library. So that creates a major problem here as well. And that's what I think is these biggest risk in kind of the software composition analysis space. And what more important than to worry about web application vulnerabilities than to looking at the wasp top ten, right? We're probably going to have a new versions of the top ten this year, but still the latest version of the top ten and the previous one, they all talked about using components with non vulnerabilities, right? So this is a major thing. Whats software compositional analysis tries to address is avoiding using those components with non vulnerabilities. If you all remember these Xfax hack in 2017, it was because a library was vulnerable. The Apache threats two library has vulnerable and it got hacked through that library, right? So it's very important issue and you need to be aware of here is just to show you that there is some similarities and of course some differences between the software supply chain and the traditional supply chain, right? And that's the reason why not just your libraries and your dependencies, but your whole pipeline, you need to be aware of and protect it properly. So you have your open sources repositories, your source code repositories, sorry, your build systems, right? Your application repository like for your binaries and where you deploy your applications as well. And all that can be entry points for attacks and for compromises, right? We all seen the recent SolarWinds attack, right? So it was attacking in these build system of the SolarWinds of the SolarWinds application. So that's also an issue that you need to be aware of as well. Here I have a catalog that we've done through the CNCF, as it was mentioned in the beginning, I'm part of the CNCF security tag team, which means technical advisory group. So we provide volunteer services as well, just like for OASP, but we focus on cloud native applications. So like Kubernetes, whats CD and helm and all that, OPA as well. So all those applications, we try to provide them with guidance and documentation and also doing some security audit for those applications. And in this kind of group we have done some catalog of supply chain compromises. So in this GitHub repo from the CNCF, we have a list of all the major supply chain compromises that affected either the source code or developer tools or publishing infrastructure in the past like ten years, right? So we have a lot of them there listed and I updated this list recently. So I think it's pretty much up to date with kind of just a few recent events. But it's very important for you to understand that this is a major thing. Your developer and your infrastructure, your pipeline can be a target of those attacks. There is also the software supply chain white paper which we wrote recently and published this year. It talks about not just securing the source code and your libraries, but also the build pipelines, your artifacts and your deployments. So it's very interesting for you to take a look and it's available for free on the CNCF GitHub repository. One last thing, whats I like to mention here is our supply chain attacks are migrating to the cloud, right? Since almost every company are migrating to the cloud and even now during the pandemic, everyone's starting using the cloud more often, either SaaS services or infrastructure as a service, right? We need to be aware of that. So recently our team at Trend Micro did a research on the supply chain attacks in the age of cloud computing, right? So here you have an example of on the top there, the developer using the IDE in their own device, in their own house or their own company office, right? Yeah. These install the required program, they set up the environment, they interact via these ide. But there's many organizations where the developers don't run their ide in their local devices, right? So it's kind of the evolution approach of the VDI, right, the virtual desktop. So you have AWS, cloud nine, I think now there is one for GitHub as well and Azure has one. So you have their online ides, right? So these are some risks on using those as well. And you need to be aware of that because you're communicating and you're hosting your code in a separate location and there can be other flaws where attackers can compromise that system and get access to your sources code. One last thing that you need to be aware of, and I think it's very important for supply chain attacks is the US executive order, right. I know it's just happening in the US, but it might affect other organizations that either have customers in these US or supply software to the US. Right? So it was published in May twelveth this year. And one of the sections it talks a lot about enhancing the software supply chain security. So it talks about maintaining accurate and update provenance of software code and components, right. So it's basically talking about software composition, analysis and software supply chain security to understand that. So if you're an organization that sells software or intends to sell software to us government, you need to be aware of that executive order. You need to focus on supply chain as well. Okay, so there are many different tools and I mentioned some of them here already. The has dependency check which is a free one. It focus on NVD. It's mostly for Java and net. If I'm not mistaken you have the retired js for Javascript code and dependencies. There is Nic which is free from open source and it's the sponsor of this event. Right. And there's also many different ones, commercial ones, one that we have fraternity and Michael we call open source security, which is basically a partnership with sneak to provide their features in our platform. Let's see how we're doing on time. Are we good on time? Let me see. Okay, I think we can do some demos, right? Let me try to share my screen quickly here. Okay, so basically what I'm going to do here is show you a quick demo of sneak inside the trend micro cloud one platform. It's basically the same UI that you're going to see if you want to use Nic as a platform for you to analyze your. Yeah, and it's free for open source, right? Nick is free for open source. You can add your projects directly from GitHub. So basically when you log in, what you need to worry about is configuring your integrations, right. How sneak is going to look at your code and check your code repositories to understand and to collect that data to analyze the libraries. So let me just close this, I'll do just a quick demo before we move on. So I'm going to add a project from GitHub and I have here all my public repositories from GitHub and I know I have a lot of repositories but it's mostly forks. But yeah, I have here the OASP juice shop, right? If you're familiar with OASP Juice shop, it's a platform for you to learn about web application security has different vulnerabilities and it's very user friendly for you to learn. And it's developed in I think code and angular. Right. So basically I select a project from my GitHub or from any other repository, I can change some settings here, pointing these, the dependency is the files for checking the libraries and these versions, that's not necessary. These basically, okay, add selected repositories. So it's going to add and it's going to start scanning, it's going to find, depending on the language and the project is going to try to find where is that located. Right. So where are the dependencies, are they vulnerable? So it's checking with the SNC database, which is even public, the database of intelligence of vulnerabilities from SNC, it's public and you can see that. So it quickly showed me the results here and we can see that here. It analyzed, since it's a JavaScript or a node project, it analyzed the packet JSON file. Right. And if we check here we can quickly see oh, there is a critical vulnerability here, prototype pollution, which has a cvss of 9.8, right. So that's very critical and we need to be aware of that. And that's in the package called low dash. And so there is even proper sneak id here and I think you can go to the sneak database here to read more about it. Right. So yeah, you can take a look here, there is a CVE, there is a CWe, right. And there's the description of the vulnerability here. So that's very interesting for the developer to know right away what they need to do. Right. And also here it shows when the vulnerability was added to this project, to which version of the package and what you need to do. You can also ignore here if you want, right. And there's a risk code and all that stuff. So it's very important for you to analyze those libraries and see what can you do there if there is a new version. Updating is the most common thing to do. But you also need to be aware of not breaking your application, right. So you need to have proper testing, especially regression testing, to make sure that once you update whats library, you don't break the application. Yeah, basically here the dependencies, and as I said, the dependencies can be direct dependencies or indirect dependencies, right. So it shows these, that there are some indirect ones that are vulnerable as well and can be even harder for me to fix because I need to rely on that one, the top one for me to update that. Right. So yeah, you need to understand that as well. Yeah, basically that's the demo that I had to share. Just a quick overview on how you can use a software composition analysis tool and sneak is the one that I most recommend using. And yeah, I hope you enjoyed this talk and I'm available for questions later. Ah.