 Hey, my name is Fernando and I'm a technical marketing manager here at GitLab and today I'm going to go over custom scripts on security reports. Now, let's get started. So let's take a look at the security reports. These reports are present in each of the scanners. They can be parsed and custom functions can be done with them, which I'll show later on in this video. Here's an example of what a SAS report looks like. There's the different vulnerabilities with lots of identifiers for these vulnerabilities, including the name, message, description, and severity, as well as which scanner detected it. There's also information on the location of the actual vulnerability and different links such as the CVE and other ways showing what the vulnerability causes. There's also more identifiers and links such as the CVE and more. Each vulnerability is present as part of a list. Here you can see another vulnerability that was detected, which is a probable insecure usage of a temp file slash directory. Now let's take a look at how this works. We have a GitLab CI.yaml, which we can see is running the SAS scanner. Then we add some additional variables to the SAS scanner, in this case Bandit, since we are scanning Python, and we enable the artifacts, paths, and we add the glsasthreport.json, and we add the reports key with SAS and the glsasthreport.json. Then we're going to add a custom action. In this custom action we define a stage called block, which requires the Bandit SAS drop with artifacts present, and what we're going to do in this script is we're going to check how many vulnerabilities are present by parsing that report, and then if there's greater than one vulnerability, we're going to exit with an error. If there isn't, we're going to continue on, and we're not going to allow failure on this job, so meaning that if this job fails, we won't proceed in the pipeline. So let's see that in action. So now when looking at the pipeline, you can see build, test, where we run our Bandit SAS, and then there's the block stage, which passed, and you can see that one vulnerability was detected, so we passed successfully, and when we go back, you can see that it was deployed to staging. Now let's look at the same thing on a merge request. So I'm going to lax the permissions, so by this, I'm going to make the database file readable to everyone, readable, writable, executable by everybody, and now you can see within the pipeline that our job actually failed, and we did not proceed to deploying to staging. So when examining the job, you can see that since two vulnerabilities were detected, then we're going to exit with an error, causing the job to fail. Now this can be done in a variety of ways. This is just a simple example, but you can pretty much call anything here. You can alert page or duty, you can report, you can go ahead and send text out to your employees, you can go ahead and report this with any reporting tools that you'd like, possibly send emails. There's just endless possibilities with these tools and just multiple custom actions can be done. Thanks for watching and I hope you enjoyed. For more information on security reports, please see the links in the description, and be sure to hit that subscribe button.