GitLab Secure Stage, 12 Aug 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Webinar - Secure - Implementing Security Scans and Dashboards

Description

Webinar for Commercial customers interested in using more of GitLab Secure stage, focused on implement the various scans and managing vulnerabilities in the dashboards and MRs. Hosted by Maxwell Power and the Commercial TAM group, this webinar covers what customers need to know to implement secure testing quickly.

A

Hi, I'm maxwell power technical account manager here at gitlab, for today's webinar we're going to explore how to implement secure scanning and we'll talk about how to build a basic security scanning pipeline using gitlab ci.

A

So we'll review what is gitlab secure, we'll talk about how secure scanning works, then we'll get into a quick project scanning demo and talk about the configuration and, lastly, we'll answer any questions.

A

So what is git lab secure? Well, our security scanning is comprised of eight different tools.

A

First, we have sas or our static application security testing, which scans your application's source code and binaries checking for weaknesses and vulnerabilities dependency scanning, where we analyze external dependencies for known vulnerabilities on each commit secret detection will be checked for credentials and secrets stored in your code commits and project history license compliance will be checked for project dependencies against approved and unapproved licenses defined by custom policies.

A

You set per project das, or a dynamic application security testing analyzes your running web application for known runtime, vulnerabilities, vulnerability, management to view triage trend track and resolve vulnerabilities detected in your applications.

A

Fuzz testing, where we input unexpected and malformed data into your application measuring response to stability, and this has the goal of finding unknown vulnerabilities, then container scanning, where we analyze your containers for known security, vulnerabilities in your application, environment.

A

Gitlab works to bring security scanning as close to the developer as possible. We believe that the earlier you can detect vulnerabilities, the quicker you can remediate them, and this brings maximum visibility all the way from the initial developer, through the merge and review process.

A

Once you commit your code, changes to a branch in gitlab a pipeline is automatically created and we start with detecting the language of your project, and then we run specific scans based on that language scanning for vulnerabilities in each commit allows developers to address concerns before changes are merged into your protected branches.

A

You can see what's changed from the last scan, the protected branch and compare which allows for faster remediation.

A

The findings are displayed in the vulnerability report. This provides a quick and simple way to review all the scanners findings. This vulnerability report is also available at the group level, where you can aggregate all your projects into one group and see all the vulnerabilities in one place for more advanced requirements.

A

We also provide numerous options for customizing your sas and seeker detection rules, and many of these customizations can be applied using a variety of environment variables which you can set at the instance group project or ci yml file level and we'll review some of these later on and how to find those environment variables.

A

Then, once you configure in the gitlab ui, you can also run on-demand dashcads, and this allows you to test your running applications anytime. You like on demand.

A

Gitlab also includes a security dashboard which currently displays project vulnerability trends over time, and this dashboard is also available at the group level, showing vulnerabilities over time and project security status for all the projects in your group.

A

And now, let's jump into a project demo and see how this is all configured.

A

So here I have my gitlab ci yaml file and we start right at the top. With our defined stages, we need to define which stages are going to run in our ci pipeline, we'll start with the build stage and then test and then dast and fuzz.

A

The easiest way to get started using gitlab security scanners is to include the templates we provide and gitlab updates these on every release, so you can just copy and paste them into your jobs to have all the functionality you need, and these templates can be configured at the job level in your yaml file and using the environment variables like we have above so here we have a basic node.js project.

A

It doesn't do anything fancy, except for a run-on web interface that allows us to scan it for this project, but first we need to build that into a docker image and to do that we run our docker commands, but we need to ensure that we push up a tag with the ci commit sha, and this allows our container scanning engine to find the right container to scan next we're going to configure some of our jobs, like our fuzz scanning job, for example, and all of this is available in the documentation on how to configure the jobs to run in your environment.

A

But in our case we just need to tell the file scanner. What file it's going to use to run. The fuzz scanning, in this case we have source fuzz.js, which we add at the end of this command, and our fuzz.js file is a really simple file that just throws some random strings. Looking for the words fuzz at the end, if it does, it finds success and it leaves, and if it doesn't, it throws an exception.

A

Next, we're going to configure some of our other scanners, our api, fuzzer, dast and dast api for this project, we're not going to scan a live running web application, we're going to run the built image above in a service and services. Allow you to add additional containers into your ci jobs and we're just going to pull the ci image that we built and alias this with app, so that when our jobs run, there'll be an app container, also available that we can use for scanning.

A

So now that we've included all of our templates, we've set up all of our stages and we configured our our build job and all of the scanner settings that we may need. We can add some variables and these variables configure the scanners and tell them how to work.

A

In this case, we have a dashed website, our dashed api target url and our fuzz api target url, and these three are set to app 8080, which is the service that's running in the containers we set up below next we're configuring. Our das browser scan, which is a new feature in git, lab that scans using a browser for dast, then we're going to move on to our dashed api scanner, where we set up our profile, which is quick and we give it a har file.

A

A hard file is an http archive. It's an industry standard for exchanging information, about http requests and responses. It's generally json formatted and contains browser interactions with a website. There's a few options for providing this data to gitlab. A hard file is probably the easiest, and we use this for doused api and for our fuzz api scanning.

A

We need to set a fuzz mode for our fuzz testing, and this is just looking for the word success as we put in the source above here.

A

We need to set a fuzz api profile which in our case, is quick, 10 and then we're going to set a secure log level, and this secure log level allows you to output more verbose information from your security scanning jobs. This is useful when you're, initially configuring, your jobs and you want to find out what's going wrong or dig into any details, once you move into production for your scanning, you can remove the secure log-level debug.

A

Lastly, we set ff network per build and this allows us to run a network within our ci jobs. So we can talk with our containers.

A

So once we commit the ci file up to gitlab, it will start running our pipelines, and that looks like this, so we can dig into the latest pipeline that was run on master and we can see that after we sent up this ci file, it created a whole bunch of jobs.

A

So first we have our build job and then code, quality, container scanning, eslint, sast, gymnasium dependency scanning license scanning node.js scan retire.js, scan secret detection, stem grabs asked and, as I mentioned earlier, gitlab detected the language we were using, which is node.js and ran scans specific to node.js.

A

But if your project is written in some other language, you'll notice, those scanners will run on that project. Then we run our dast and our dashed api and also our api, fuzzer and fuzz testing.

A

So let's jump into a job and just see what that looks like our fuzz test, for example, you can see that the fuzz tester threw a whole bunch of characters at our test at our application.

A

Finally, at the very end, it runs into the word fuzz and it exits so there's the word fuzz and it's leaving, and we can also see that this job uploads artifacts into gitlab- and we can browse these artifacts and pull out anything. We may need job logs or even the fuzzing report itself.

A

So what? If something goes wrong in your job? How do you debug it? So we can come into pipelines and we can find the job, let's say in our case semgrepstast, and this will load the job logs, so in here you'll be able to see any errors or anything that broke while running your job, which will allow you to debug it a little more. Sometimes you may need to add some variables or tell the gitlab scanner where to find your files to scan, and all of these are configured in environment variables.

A

You can see, there's no artifacts for this job because it uploads them into the gitlab vulnerability report.

A

So where can you find all of these templates?

A

We can start by going into the ci cd and editor, and here we have a quick link that will allow us to browse templates, and this brings us into the repository template in gitlab, where we store all of the templates that you can use in your jobs and you can copy and paste anything you need from these into your own jobs.

A

We can look at security and we can see how to configure the security scanners.

A

So we can open the dash job and we can review everything that this dash job is doing and if we have to, we can pull out or expand any of these into our ci yaml file.

A

Most of these never need to be changed and it's recommended to use the included templates in your jobs, as sometimes they can change between releases.

A

If you want to see all of the templates available, we can use our auto devops. So we come back into our project, go back to the main page and we can go new file.

A

And once we bring up our new file, we can select template and ci yaml.

A

This adds another template where we can then choose auto devops, and here this loads, the auto devops, and we can just scroll all the way down to the bottom to find all the templates that are included and their formats.

A

In this case, we have our code quality code intelligence. We have some deploy jobs that we wouldn't need. We also have some dallas configuration scanner, dependency scanning, license scanning sas and secret detection, and we also have links to where these templates are. So you can click on them, really quick and jump into that template repo to find the details of this job. So if you ever need a quick way just to include these in your job, you can load up this template and paste them right out of here.

A

So now, let's talk about what our security dashboard looks like, as you can see over time. This is showing us what vulnerabilities in our project in this case my project is new, and so most of this data is from the last little. While we can also review our vulnerability report- and this is where everything the scanners pick out- will be stored and displayed in gitlab- we can choose our severities.

A

We can choose the status, we can even choose the scanner that detected the vulnerability and if there's any activity like issues so for this demo, I chose to fix this server leaks information via so I created an issue based on this and then a merge request in gitlab.

A

Once I did that I pushed up my fix in a commit.

A

Gitlab then ran ci on that new branch and that commit and compared it to the master branch in my project, in your case, any protected branch, but the primary default branch is what gitlab is going to compare all the security find results to. So you want to make sure you set your default branch in gitlab to the branch that you want. All of your merge requests compared against for your security scanning and then you're going to want to make sure that you run a scanning job on the primary branch first.

A

So, in our case, we've done that and now this fix has detected that it's actually changed in the security scanner. So we can see here that it detected no vulnerabilities that are new and two of them that we've actually fixed.

A

This information is really awesome in the merge request, as it allows you to ensure that things have been addressed.

A

Next, we have our dependency scanning, which pulls out all the dependencies that this project has in my case, because it's a node.js project, it's using the packagelock.json file to grab the dependencies.

A

We also have the license compliance where we're pulling out which license and which dependencies have those license.

A

Lastly, let's talk about how you can find all the custom variables you may need for your jobs. In this particular case. This is the staff job and if we scroll up a little bit here, we can see our logging level that we talked about earlier and we can set these to fatal error. Warn info or depug, which info is the default.

A

So when you're first setting it up, like, I recommend, add the debug here, you can get some more logs out and find out if you have to configure anything in your project.

A

So in the docs underneath secure your application, we have our dependency scanning static application, security scanning secret detection, dynamic application, security, counting api fuzzing. All the docks are here for everything you will need to configure in these scanners and inside of all of these docs you'll find this available, ci cd variables heading and under here. It lists all of the variables that you can configure for this scanner.

A

Some of you may have java projects java tends to need a version set, and here we can set the version with a variable sas java version same with java path, and maybe any java options you might need, as well as all sorts of other variables that you can use to configure the scanners thanks. So much for watching our webinar today and happy to answer any questions you might have.