[0:00]Hi, and welcome back to the fifth session about our Dev Sec Ops pipeline which we are implementing with GitLab.
[0:14]In this session, we will have a look at static application security testing. Static application security testing is actually a very important first step to introduce, but where do we add that in the pipeline? That's a very good question. Let's have a look. So, here you can see our Dev Sec Ops pipeline, which we are implementing with GitLab. In this pipeline, we have the continuous integration and the continuous delivery. And in the continuous integration, we have already implemented the static analysis with the software composition analysis, where we have already a video, which you can see up there and the license compliance, which we already have covered with another video, which you can see up there. And in this video, we are going now to implement the static application security testing. But, Patty, what is static application security testing? Good question, let's see. So, Static Application Security Testing, often pronounced as SAST, is about finding vulnerabilities in your own code. This includes scanning all your source code files and searching for such vulnerabilities or security issues. Okay, so Patty, do you have an example of such a vulnerability? Sure. One good example would be if you're using cryptography and you use weak ciphers in there. So, to search for such vulnerabilities, GitLab uses primarily the Semgrep open-source tool. Besides Semgrep, it might also use other tools, but this then depends on the actual language you're using where you write your code in. So Paddy, that sounds great. How do we do that? Well, that's quite easy as seen before in the other videos. So similar to the other tools, we just have to include a GitLab provided template sast.gitlab-ci.yaml into our GitLab pipeline definition file. And that's what we're going to do right now. So here, we're back in our DevSecOps pipeline project. We've added some code so that SAST can provide us with issues. Let's see what we've changed.
[3:09]Basically, we kind of simplified the Spring Boot main application by removing the controller part of it. As a replacement, we've added a new controller that includes some security issues like insecure usage of cryptography. So one thing we expect that Dust reports is line 47 here, where we use an insecure random to generate random numbers. Now, let's see where we add SAST to our GitLab pipeline. For this, I just go back to our pipeline definition file. GitLab-ci.yaml and edit it in the web browser. I just add the import statement here for the SAST template that GitLab provides and then commit the file to the repository. So, commit to the master branch and add SAST as a comment. With this commit, the pipeline already started running. Wow, Paddy, that's that's really great. With just one line, we added SAST to our pipeline, but um can you show me what's behind that file? Sure. Actually, there's quite a lot behind that file. So, when I open this sast.gitlab-ci.yaml file in the browser, here, then we will see when I search for for Java files that we're actually using two tools to investigate the source code. The first is uh Semgrep, as presented, that's the main tool in GitLab. And for Java, they use another tool called SpotBugs to that also provides input regarding security issues or vulnerabilities within your code. Wow, that's quite cool. Why do they use two tools? Actually, good question. Well, each of these tools has its own strength and weaknesses, and by combining multiple tools, this kind of makes sure that the coverage is better and hopefully also the results with that. So, let's see what the pipeline did in the meantime. So, let's open the pipeline and then see what tests we have now. And yes, as we saw in the template file, we have two additional test steps here. Semgrep SAST and SpotBugs SAST. Wow, this is uh quite cool. Can you show me what's behind these uh two jobs which we have in there? Sure. So, I just click on the job, Semgrep SAST in this case. And what we see here is that we download a Docker image, and then Semgrep is actually executing its testing and uploads the files and reports to the vulnerability system of GitLab. Wow, this is quite cool. But Patty, um I only see some strange lock statements in there. Where do I see the actual vulnerabilities? Well, to see the vulnerabilities, we head back to our pipeline.
[7:21]And here we have a tab called Security. If I click on that, I'll see all the vulnerabilities found in this pipeline. If I select here SAST, then we get a list of all our SAST found vulnerabilities. And sure enough, we have the one we expected. And here we have the culprit. Predictable pseudo random generator. It allows me to jump directly to the file and location where the issue is.
[8:08]And here online 47, we use the insecure regular random number generator instead of its secure twin. The other place where we actually see this vulnerabilities is in the governance part of GitLab. So I go to Security and Compliance and Vulnerability Dashboard. And here again, we have all the findings. As I said before, we'll have a dedicated session to this module. Remember that using this governance view of vulnerabilities requires you to have the ultimate edition of GitLab. In contrast, just scanning for vulnerabilities using the SAST tooling is included in the free license. Wow, that was quite cool. With just adding one line of code, we included in our pipeline the SAST, which is the static application security testing. And with that, we're at the end of this video, and in the next video, we will have a look at container scanning.
