 Welcome to improving the security and licensing of your software using OSS Review Toolkit. My name is Sankalpa Menon and doing this talk together with Thomas Steen-Bergen. In this presentation, we will show you how we answer the question, which software do you rely on? This question is important as we see more and more supply chain attacks that exploit high impact vulnerabilities. Besides supply chain attacks, we also see sustainability issues, where a single person is the maintainer for a package used by thousands of others. One of the solutions we adopted is to create software bill of material for our software, which you can think of it as an ingredient list on your Coca-Cola bottle. Software bill of materials are awesome. As an ingredient list for your software, they provide you with a lot of things you need for compliance. They can also help you draft the unified approach to security in your software supply chain. And if you're buying software, they can help you know which vulnerabilities are in the software that you're right to buy. That said, it may be difficult to draft an S-bomb, as software is often complex and not all the package method is available. You might also see several false alarms for vulnerabilities if we're included of source dependencies that you may not even be using. It may also be very time intensive to trace down all the components and to train your developers. Also opponents of S-bombs have raised questions about the effectiveness of S-bombs in preventing cybersecurity attacks. That said, we believe S-bombs are a step towards transparency and fidgets and can help anyone identify and address risks. One of the tools that you can use to generate a second DX or SBX S-bomb for your software is OZSV Toolkit, or Oort for short, which is an open source project on the Linux foundation. Besides being able to generate S-bombs, it has many other useful features, which is why we use it and contribute to it. For example, it has a very powerful policy engine that allows you to write licensing security or engineering standards checks on your software. Say, for example, if there's a particular license that you don't like to see included in your software, you can have Oort flagged for you. You can also use it to check for security vulnerabilities. Or to comply with your license obligations, it has built-in support for multiple scanners that you can use to scan the source code of your project or its dependencies for copyrights and licenses. One of those obligations may be that you have to provide a source code bundle. Well, you can use Oort to generate one for you. Overall, Oort has a modular design that makes it easy to integrate and customize it to your needs. Let's now see Oort in action with a little demo. In this demo, we'll show you how you can mainly trigger analysis of your toolkit scan in GitLab and how you can integrate it into a GitLab pipeline file. So that whenever you make a code chain to your project, an Oort scan will get executed. For those who are new to OSS review toolkit, this is the main code repository. The readme of the project shows what does the various Oort components do and how you can install it on your machine. To use Oort in GitLab, we recommend you to use this repository. Following the Oort for GitLab installation instructions, we mirror the GitHub repository in our GitLab account. And it looks like this. For this demo, we are going to scan the fork of a MIME type repository. Once you have Oort for GitLab set up in your local mirror, click Pipelines under CICD and click the button Run Pipeline. Once you click it, you would see a page like this. To save some time for this demo, I already prefilled the values. To do an Oort scan, you have to fill first five values. Others are optional. The first value is software name, software version, code repository type, code repository URL, and code revision that you would like to scan. Once the values are filled in, scroll all the way down and click on Run Pipeline. I already did this and here you see what you get when your scan is completed. To see the scan results, click on the Oort scan. Here you see the logs of the scan and scan results can be found under job artifacts. Click on Oort results and here you would see the various reports generated by Oort scan. For example, the web app report. This report contains all the necessary SBOM information. The first tab contains the license and the package information. The revision and all the files that have been scanned. The second tab contains the packages, the version and the license information. You can view it in the Tree tab as well. And when you expand it, it would look like this. If you like Oort to be executed whenever you make a code change to your GitLab code repository, simply add Oort to your GitLab CI demo file as the include statement as shown here. Be sure to update the value for project to the location where you have mirrored the Oort for GitLab code repository in your GitLab account. Next add an Oort scan job as shown here. In this case, we've configured the Oort scan to be executed in the test stage and this pipeline defines three stages, build, test and lint. Next we've configured it to do two retries. This is a generic option that GitLab has for every old job. We do this so basically in case there is a network issue, when trying to retrieve a code repository for a dependency, it will do another run of Oort scan. So this will help us hopefully to get more successful pipelines. Next we'll define some variables. You can actually omit these and Oort for GitLab will use default values, but in this case we added them for demo purposes just to show what you can do. So here we set the software name for the project in case it's a useful option, in case the software name of the project is different than what is defined in the code. Next we can define the software version and here we define the code repository to be scanned. Finally we set the option that Oort has to allow dynamic versions to true. Basically what it does is it allows scanning of projects even if the package manager requires a log file and the log file is missing. Next we set the license scanning reports. For people familiar with GitLab, this is exactly the same how GitLab's own license scanning mechanism works, but in this case instead of using GitLab's built-in license scanner, we're basically using the results from an Oort scan. So let's look how such a pipeline looks like when it's executed. So here you see it, the build test, so dependencies get installed, then they can test it and here you see an Oort scan being executed. Next you can open this file by right clicking it, you'll see the logs and for the results you can click the browse button and then click on Oort results and then you see the various results files. Now this might seem like a lot of clicks, we did this. If you run Oort for GitLab in a merge request, actually it will automatically add a code command to the top of the merge request window and then you have a simple link directly to the Oort's results. Now we will show you how you can use Oort's VToolkit to generate a CycloDX or SPDX S-Bomb in GitLab. Oort for GitLab generates by default various reports including CycloDX and SPDX-Bomb for your software. Here it can be found bomb.cyclondx.xml, bomb.spdx.json and bomb.spdx.yaml. The report bomb.cyclondx.xml looks like this and the report bomb.spdx.json looks like this. Thank you for listening to our talk. If you have any questions or are interested in contributing feel free to chat with us on the Oort Slack channel or reach out to us directly.