[0:00]Hi, and welcome back to the third video about our DevSecOps pipeline, which we build up with GitLab. In this video, we will have a look at the first security check which we will introduce, it's the Software Composition Analysis.
[0:24]And we start with a creating our demo project. Our demo project will be a simple Java Spring Boot application. It features a web service that simply returns 'Spring is here'. We also have a unit test calling the web service and comparing the return result with said 'Spring is here'. We will also introduce a very simple pipeline that actually builds this Spring Boot application and that executes the unit tests. So, I've opened for us now GitLab in the my project's view. We will add a new project, created from template, use the Spring template, use a reasonable name called VideoDemo, and assign it to our group that the two of us have access to. Then we create the project. Okay, let me introduce what GitLab created for us. We have at our disposal a very simple Spring Boot application that features a Maven build, that's why we have this Maven files and the pom.xml here. We also have in the source tree a main application called DemoApplication that is a very simple Spring Boot application just returning Spring is here from its root context. The other thing we have in the source tree is we have a test that actually tests our web service. It's a very simple test just executing this a call to the root of the web service and comparing the results for demo purposes. So, what do we do next, Romano? As we have seen in the last video, we, of course, now need to create that pipeline file, this YAML file in the root of our repository. Okay, let me do that.
[3:09]I'll click on the plus sign here, add a new file. You may select a template, but we just need to name it gitlab-ci.yml as we saw. And we're add the following pipeline definition. So, what did we prepare here, Romano? Yeah, what we can see, um we already copied in some YAML code. Um, we have two jobs in there, one build job, which builds the Java web application, and one test job, which executes the tests of the Java application.
[4:17]What we also see is that we have a stage, which is build, um, this is a default stage that we have in GitLab. The default stages are build and test, and you can see that we are using them. They define the order how the jobs are executed. Next, we have the script, which is executed, so you see that there, uh, this script will be executed and the output of this execution of that script will be stored in this pass, in the target jar file. And the same is true when we look at the test job, which we have down there. There we also execute the script for the test and then also the artifacts are stored. And what we also generate is a test report. Great, so let's save everything and commit. And with this we have the pipeline definition within the repository, and Git already started a pipeline run for us. So let's take a look at the jobs that are started in the pipeline. We have the build job and we have the test job, as expected. So, things look good, let's continue from here on. We have now basically set up our demo project. So, Patty, um, what is this Software Composition Analysis? Why do I need to have that? And why is that important? Good question, Romano. So, that's basically the first tool we're adding right now. Software Composition Analysis is all about finding vulnerabilities in dependencies, so within libraries and stuff you actually use within your application. It's also known often as dependency scanning. In GitLab, SCA is implemented like this. SCA scans all dependencies in your project and searches for known vulnerabilities in public directories such as public CVE repositories. Whatever vulnerabilities are found then are listed by risk within the GitLab tool. GitLab, by the way, also allows you to kind of manage vulnerabilities, which we'll see in another session then. Managing vulnerabilities is, by the way, GitLab Ultimate features, as is Software Composition Analysis on its own tool. GitLab uses the Gmnasium open-source tool, that's Gmnasium now is owned by GitLab, too, that is used to scan these dependencies and finds such vulnerabilities within dependencies of your code. So, Patty, um, okay, I see that this is quite a good thing, but, um, we have just introduced a Java application. Some small source code has been added. Why do I need to dependency scan that? Well, it question actually. Well, with Spring Boot, we actually pull in a lot of external libraries that together build our application. So, in the end, our application consists of the small piece of code we write on our own, plus all the other libraries and code that comes from third parties or from external dependencies. And the thing here is that we want to make sure we find the vulnerabilities within third-party code. So, just to illustrate this, we're back in GitLab and take a look at the build log. And here you see what it's all downloading from. So, there's a bunch of jars we actually need to run this Spring Boot application. See, quite a huge list actually. So now, let's enable Software Composition Analysis within GitLab. It's actually very easy to do that. You just have to include a template that's found at security/dependency-scanning-.gitlab-ci.yml. Let's see how we do that. So, let's add this to our pipeline.
[9:37]Already prepared this, so what we do here is we actually include another YAML file that contains all the definition that actually executes this dependency scan. So, I'll commit that to the repository. GitLab will then start executing and doing a dependency scan for us. And as you've seen, this file that we kind of reference here, it's actually open source and available by GitLab. And this is also quite a good thing because with that you also have the possibility to copy that file into your own repository if you need more control over that. So now we're back in GitLab and we'll take a look at our newest pipeline run here.
[10:44]What we immediately see is that we have one additional job here that's executed. That's basically the reason is that we added this dependency scan template. So, let's see what this actually did. We see here that we had again a Docker image downloaded. This time for Gemnasium, which is actually the vulnerability scanner that GitLab uses. After downloading it, it basically executes the analyzer here, and it finds all the vulnerabilities that are in our dependencies and uploads them to the GitLab artifacts. Cool. Um, but where are the results now stored? I'll show you in a minute. One place to go to is go to pipelines and then for your pipeline run click on artifacts and there you can download the Gemnasium Maven repositories, these two files. Can do that. So, this is how this vulnerability scanning results file looks like. It's just a JSON file that you can use to feed into your vulnerability management software if you have such a thing. If you do not have a vulnerability management software, you can also use GitLab's built-in vulnerability solution. For this, head to Security and Compliance and then to vulnerability report. As you can see, GitLab populated already its findings here. So, what you see here is an Ultimate-only feature, and we will introduce the capabilities in a distinct video session. So, wow, that's pretty cool, and I see that we have quite a lot of vulnerabilities found, so 28 critical and 61 high. Do I need to fix all of them? Well, it depends. Generally, yes. My usual recommendation here is try to upgrade all your dependencies to a fixed version. Do not invest any time to figure out in detail whether it affects you or not. If you figure out that some vulnerabilities you can't get rid of because you can't upgrade or because there is no upgrade, only then try and analyze in-depth whether it affects you and whether you have to do compensating measures or whether it's acceptable for you to run like this anyway in production. So, what we have introduced now is our demo application, which is Java Spring Boot. And what we also introduced is the first jobs which are executed, the build job and the test job. After that, we have included the software composition analysis, which is nothing else than the dependency analysis. As you could see, we have already a lot of vulnerabilities in this small demo application, which we have, and we could see them all in our vulnerability report. So, Paddy, are we now done? Not yet, there's still a lot to do. In our next video session, we'll introduce you to license compliance for example.
