GitLab Secure Stage, 21 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Vulnerability Management feature and workflow walkthrough

Description

This walkthrough will show off some of GitLab's Vulnerability Management features. You will see how both a developer and security team member can use them in their workflows while collaborating entirely inside GitLab.

0:00 Vulnerability management intro
1:09 Merge request security approvals setup
5:26 Security Dashboards
6:24 Vulnerability Report
9:02 Merge request security results
11:28 Security Center
14:37 Vulnerability details
15:30 Fixing vulnerabilities, no security approvals needed
16:53 Collaboration by creating issues from vulnerabilities
19:53 Using issue boards for vulnerability tracking

A

Hey everyone matt wilson senior product manager at git lab.

A

I am going to show you some of the features of vulnerability management, I'm going to do kind of a quick overview of how you might see an interaction between a developer and somebody on the security team, all outside of the same tool and I'll call out some of the highlights of the features as we go through.

A

So one thing to note here, as the developer: I'm going to be in this dark mode here and get my little evil monkey up there and on the security persona side I'll have the light mode. So that's what we're looking at here.

A

So let me start with this project as a person on the security team, I want to make sure that I'm maintaining the integrity from the security perspective of perspective on my project.

A

I don't want new vulnerabilities being introduced without me, knowing about it so a good way to help prevent that is by using one of our merch request approvals. So this is something I'm going to set up on my project. So I'm not going to go into the details here, but I've already got some security scanners configured to run on my pipelines.

A

What this vulnerability check rule is going to, let me do is for I'm going to set this on my main branch here. It's my default branch, I'm going to require one approval from somebody on the security team. In this case, it's me as my security user persona.

A

Now any new feature branch for this project that targets the main branch is that introduces or would introduce a new high, critical or unknown vulnerability is going to require my approval as the security user before it can merge. So this is a great way to help keep the health of my security health of my project intact, while not slowing down the developer workflow, if they're not introducing any serious security issues so now back over to the developer side.

A

So I have this project here. This is just a python. It's a django example project and let's say that I know that I'm going to add something to the project and in my requirements for the fi or for the project, I need to update one of the dependencies.

A

So I'm going to actually do this all inside of git labs. The first thing I'm going to do is I'm going to create a new branch for my to hold my change.

A

So I'm going to call this pigments update. I've done this a few times so we'll call this pigments update three, creating it from my main branch.

A

And there we go so I am now in my new pigments update 3 branch, and here is my repository. So let's open up that requirements file.

A

If I use the web ide, I can make this change still in the browser.

A

It the web id doesn't actually support dark mode yet completely, so I am still on the developer side. Just it looks light. So just ignore that part. So, let's say for my purposes, I need at least version two of this particular library, so I'm gonna go ahead and make that change. You can see my diff right here, great we'll, say, update pigments to 2.0 plus and I'm going to commit that to the same branch. I'm also going to start a new merge request.

A

This is where I'm going to see my pipeline and changes oops. Sometimes it does this it targeted a previous branch or in the wrong project. So I'm going to make sure that I go to the right project here. Let's do that again and there we go.

A

Okay, so I'll leave a little note and I will create that merge request. So this is still me as the developer. So now I've checked in my changes, and this has kicked off a new pipeline, simple pipeline. It just has a build stage to make sure that everything looks okay in the actual project itself, followed by a security check phase.

A

So you can see I'm running a number of the gitlab analyzers, including some dependency checks and static analyzers we're going to wait for that to finish now, you'll notice, down here that vulnerability check rule the merge request, approval that I just set up as the security person.

A

I can see right here. These are all the approvals that I'm going to need. So I didn't set up any of these optional approvals say for a code review, but I do have this required one here from this is me as the security personas he's got my face: not the monkey so zero one right now we're going to come back to this, whatever the pipelines are finished running because right now, I can't even merge this because I'm I am waiting for that pipeline.

A

So we're going to flip back over to the security percentage side and show off a few of the features we've got available. So the first thing is the security dashboard. So at a project level the security dashboard is going to give me a really quick, high level overview of the vulnerabilities in that project over time. This is great for spotting trends or zooming in on a particular area that you want to see. You know why something went up or down.

A

I can stretch it back here through time notice, I'm kind of going back and I think, as long as you have enough history, you can go up to 365 days here and then I can see, for instance, between the eighth and the ninth. I actually had an uptick in my critical and highs, so this may be something I want to drill into.

A

It's also a good way to quickly see. Am I going up, or am I going down in vulnerabilities for a particular project?

A

If I want, I can do things also like toggle off some of these other priorities here, so I can just focus on highs and criticals. For instance, but if I really want to get into it most of my time is probably going to be spent on the vulnerability report.

A

The vulnerability report shows all of the vulnerabilities that are present on the main branch or the default branch of your project. In my case, the main branch I can see. This is the last pipeline that ran. If there's any errors with the pipeline, I can easily click to see what might have gone wrong.

A

This could be an indicator that maybe you know something that's a broken in a ci config and I'm not getting my scans properly. That'd be something to investigate, and then here is a list of everything currently in that default branch. So I have a number of options and filters.

A

These are really handy to quickly be able to look at just what I want. So by default, I'm seeing only the open things. These are detected and confirmed items I can filter by severity.

A

All scanners- this is actually a dynamic list of every scanner configured and that has ever produced any result for this project is pretty handy. In fact, if I've integrated any third-party scanners say from one of our technology partners, their name and scanner will appear here as well.

A

I've also got this handy activity filter, which is a great way to tell me if I've got things that might need my attention because, let's say no activity.

A

These actually are all the vulnerabilities that don't have either an issue created from them or and are are still identified by our scanners.

A

Another common use is this no longer detected feature here, so this is pretty handy, so sometimes a simple dependency upgrade, for instance, might resolve multiple vulnerabilities or you may have many same type vulnerabilities, and you know the fix to take those out could resolve a lot of a lot of existing vulnerabilities at once. So when a subsequent scan of the default branch doesn't find a vulnerability anymore, it marks it as no longer detected. So this means that the you know the code or the dependency has actually been removed.

A

Now you may want to double check still. That depends on your process if it is trust but verify that's fine, but in some cases it may just be easier to filter by everything that has this no longer detected indicator, and then you can use our bulk selection feature and I can easily set the status to resolved for all of those items. If I wanted to I'm not going to do that right now, but we'll just go ahead and cancel that out.

A

So that's just a handy way to get exactly the kind of information that I need. So let me flip back over to the developer side. Give this page a quick refresh. I bet that pipeline is long since finished and it has so everything is passed all the analysis completed successfully.

A

So we now see a new section here, so I have security scanning and I see that it's detected one potential vulnerability and it's high. So let me expand it to see what is in here. Well we'll notice. The sas scans didn't pick up anything, but the dependency scanning did now. Remember I upgraded the version of pigments, so it seems that the version that I have selected it actually still has vulnerabilities inside of it. In fact, it has this cpe right here and apparently there's something that can lead to a denial of service attack.

A

That's not good! Well, our analyzer has actually provided us a recommendation. I can actually just upgrade to 2.7.4 or above well, that's great. So normally I might be stuck here waiting for somebody on the security team, where I may not know that I was introducing a high high severity vulnerability into the code base.

A

If I didn't have this kind of visibility right here in my merge request, so what I can do is I'm going to go directly into my change file, and this is another handy feature, so I can actually make a suggestion that edits this line. So I'm just going to change this to 2.7.4, since that was the minimum non-vulnerable vulnerable version, and I will add that comment.

A

Non-Vulnerable version we'll go ahead and apply my suggestion here, and this has actually made the change right here directly as a new commit inside of that. Mr.

A

Whoops, we'll just give that a refresh it picks up there we go, and so it kicked off a new pipeline, so we're gonna have to wait for this to run again. So while we do that we're going to go back to the security side and show off a few more features over there, while we wait so one thing that is available, this is actually available to any git lab user. That has access to any of the security features.

A

For any project is this: we call this the security center, so this is a personalized space where I can actually see any combination of projects that I have access to see. The vulnerabilities for this is different from like a group level dashboard, because I can mix and match between projects from different groups and, if I'm using gitlab sas actually from different namespaces.

A

So let me go to the settings right here and I'll show you, so I could actually add any project that I have access to. I've got two already so one. This is in gitlab examples. So this is not a project that I own. I just happen to be a developer. On this particular project, and then this is the one that I actually own right here so because I've added both these projects you'll see, I have a very similar vulnerability report.

A

This looks really just like the one on the project level, except I have this handy project selection filter so that I can actually toggle see. That's just my gitlab examples, one and then the customer portal is is right over here. So I can actually make this like really customized view of things. So maybe I've got let's say five really highest priority projects that are spread out through different groups in my company, and I want to make sure that I keep on top of those. This is a great way to do that.

A

We've also got the security dashboard here. This is actually what you'll see at the group level, so we have a very similar vulnerability trendlines chart. So I get a quick 30 60 90, so I can keep an eye on any trends, but I've also got this project security status scorecard over here. So this is going to assign a letter grade based on how many so we've got low. C's or mediums highs or critical, so if there's one or more open vulnerabilities in a particular project, that's what grade it gets.

A

So I can see that this example project that I belong to actually has two high vulnerabilities. So that's why it's got a grade d and then I've got a critical two critical vulnerabilities on that customer portal. One the project we've been looking at the whole time. It's a really really quick way to go see. Is there anything that's going to need my attention across really anything that I have configured here so pretty pretty powerful ability?

A

Let's flip back to the developer again and see what that pipeline is. We should be all done by now.

A

Oh almost done so we got two more we'll give this just one more minute, we'll come back over here.

A

And we'll go back to the vulnerability report so while we're waiting.

A

We'll show off the vulnerability details, so this is very similar to the modal. You saw me click on earlier from the developer side. It's a full list of information that is output by our scanner. So you see any particular links that are provided. We've got the actual file location; these are the identifiers that came out of the scanner. So if I want, for instance, this is going to take me down to mitre's website information about that particular cve.

A

And then, of course, any actions that may have been taken on this before too so I have basically a change tracker of who has done what. So in this case, you know, I was actually changing things around in this particular project layer go back over here, one more time.

A

Great okay, so the pipeline is passed. Everything is all done now we're going to look over here and see what we've got and you'll notice. If you remember before this had zero of one approvals because it was, there was a high vulnerability, so the approval check had actually gone into effect. Well now it says that I don't need it, because I fix that vulnerability.

A

Security scanning is now detecting, no vulnerabilities, so you'll notice on that dependency scanning.

A

There was that high vulnerability, but it looks like there was actually a critical vulnerability that was already in that 1.2.2 where we started so in the main branch, there was already an open vulnerability.

A

See so this one was created a month ago and I actually created an issue off of it. So just by doing that update, I actually fixed two vulnerabilities that were in there and so now I've got a clean branch and I can go ahead and I could merge it myself.

A

In fact, we'll just go ahead and do that so quickly and easily. I was able to really unblock myself. I can continue forward with any work that I needed to do and I can kind of repeat the cycle now to show off a little bit of the collaboration side of things. Let me go back over to the um security engineering side, so let me start with something that we don't have identified yet so there's no issue for this one. Yet it's not part of that requirements file.

A

So let's say that I've done my investigation of this I've looked in the file here and I've realized yep. This is a vulnerability that definitely needs to be fixed. I can confirm the status on this one.

A

Confirm by me just now, so we have that nice little history record there and I'm going to send this to my developer self and say.

A

This needs to be fixed.

A

Let's take a look, we'll go ahead and save my comment and because I've at mentioned myself.

A

I'm gonna give that a second here there we go, so I have a comment and if you're familiar with get lab to do's you'll notice, they go to my to-do list.

A

I have one and there it is so you'll see that I've actually got this adventure and if I need to, I can click right through to that vulnerability, and I can see exactly what the person on my security team just sent over to me now either. One of us could go and create an issue from that. So let's say I want to create an issue to actually address the work, so it's copied over the title of the vulnerability.

A

What the vulnerability name is, and that description is so. This is a we've got a backlink right here, which is nice to the vulnerability itself, and then the description is everything that was just in that vulnerability description itself. So I'm getting all the same information, it's creating it as a confidential issue by default, because security tends to be. You know it's very sensitive and you may want to restrict that so that's going to default on, you can always uncheck it.

A

If you want- and in this case I've got some labels set up- I may say you know what, since this was a high severity, I'm going to put this scoped label on there and I'm going to create an issue out of it and again this could have just as easily been done from the security side. That may actually make more sense to do it that way, but I've just done it myself.

A

Since I was tagged on the issue so now I've got this high security issue and, of course, the time stamp on this I could use for slas. You know I might even set milestones or a due date based on. Let's say, I've got a 30-day sla.

A

I might go with you know june the 30th, for that. So we'll do that now. Another thing that may be helpful, too is you, can set up issue board so now that you've got this in issue format, what if I've actually got so this is my development board.

A

I might want to see my security issue, so I set this up ahead of time and I've got a column for each of the severity labels that I've got each of these scope labels. So now I can easily say that I have this high high severity vulnerability. That's due on june, the 30th I have one over here, that's a low. I didn't put an sla on that. Maybe that's not part of my process, but this is something that I can easily get to.

A

If I flip back over to the security person persona, I'm gonna have access since we're both part of the project. I have access to that same board, so you've got both the security team member and the developer. We both have this nice shared view, and we can, you know, set up our workflow processes. However, it makes sense for us, so I think that's pretty much it.

A

I know there was a lot of ground to cover, but hopefully that really highlighted a lot of the functionality that we have available inside of gitlab for security and vulnerability management and provide some good examples of how you might get your security team and your engineering teams working inside and collaboratively to really, you know, manage the vulnerabilities but improve that security health. Your projects, thanks, hope you enjoyed.