 Hi, everyone. Hope you're enjoying GitLab Commit. Thanks for joining me today. We're going to talk pretty quickly here about how GitLab works with Anchor Enterprise to protect your containerized workloads. So my name is Paul Noverice. I'm a solutions architect here at Anchor. And this is a pretty quick session, so I'm just going to jump right in. So the agenda today, we're going to talk about CVE scanning, pretty much table stakes at this point for any security tool, kind of the bare minimum, really. We'll talk about GitLab's security dashboard and how we send our results to that. So you're probably already familiar with the security dashboard to some degree. We integrate seamlessly with that. Then we'll talk about policy evaluation, which is how we extend and make your images even more secure go beyond just the basic CVE scans and really take your security to the next level. And then finally, we'll talk about remediation, so once you've identified these problems with your containers, how do you fix them? So just as a real quick recap here, software supply chain attacks have been in the news a lot lately. I think that's kind of an understatement. Everyone's heard about SolarWinds, but there's been several other pretty large supply chain attacks recently. And these are a big problem mostly because of how widespread they can become. A single attack can affect, you know, thousands of companies downstream from the original compromise point. So this changes the game quite a bit. Even if you think your company is maybe not interesting enough to be an attack target, it doesn't really matter anymore because the game is not anymore finding juicy targets to attack. It's more setting traps and just seeing who wanders into them. So we did a survey of a lot of large enterprises just recently here, and one of the biggest results that came out of that was just the number of organizations that have had impacts from these supply chain attacks, right? It was a lot bigger than I had anticipated. Approximately two thirds of companies here had reported some impact from the, you know, supply chain attacks in the last year. So it's definitely a widespread problem. The other thing to keep in mind is simple CVE scans will not protect you, in most cases, from these problems, right? There's a lot of other things upstream that you can look at to really make sure you're protected against these. So real quick, before we get into the demo, just a couple of recap points here. One, Anchor does offer templates for basic CVE scans with our open source tooling. We have a tool called GRIP, so there's a native integration with the GitLab CI CD tooling that you can use. We'll show that really quickly, but we also have a more in-depth integration with our Anchor Enterprise tool for policy evaluation. So this would go beyond the CVEs and look at how your images are put together to really find some other problems that simple CVE scans won't turn up. Also, for a lot of cases, you might need to prove compliance with various industry standards, and Anchor Enterprise can help you there as well. And then finally, as I mentioned, we like to flow all this data, the results from these scans into just your standard GitLab reporting that you're probably already using, so like the security dashboard, the vulnerability report, et cetera. All right, so let's get into the demo. So I've got a repository here, pretty simple. I've just got a little readme here, and I've got a Docker file. And this Docker image is pretty simple. I'm just gonna use Alpine Latest. I'm gonna expose a port, and I'm gonna install some packages in here, Perl and Pseudo, right, pretty simple. So let's see here. I'll go ahead and make a CI file here. And let me just paste in my pipeline tool, and I'll explain what's going on here. So we're gonna make a GitLab CI.aml file. And what I'm gonna do in here is I'm gonna build my image, and then I am going to use Anchor Scanner here, the Enterprise Scanner. And what the Enterprise Scanner is gonna do is, first it's gonna check to make sure the scanner is actually available, and then it runs the script to scan the image, and it will put the results into this JSON file, and then we'll do a policy evaluation as well. So let me commit that, and we'll give it a second here, and we'll go look at our pipelines, and it should be building. All right, so we'll give this a second to build. Okay, our build is complete. We can see that the scan has failed, even though the build succeeded. If we take a look at the scan result, we'll see two things. One, the policy evaluation returned a fail result, but we did upload our artifacts to the security dashboard. So just real quick, I'm gonna pop over to Anchor Enterprise Web UI, and let me refresh the image analysis here, and we should see, there it is, the image we just built. So just take a peek at it real quick here and see what's wrong with it. Why did it fail the evaluation? We can see there's a few things wrong with it. One, I've got some packages that I've blocked. Curl and pseudo are not allowed in my policy evaluation. I've also got an exposed port here, the SSH port 22 that's not allowed, and a couple of minor violations here. I didn't define a health check, and I don't, oh, I have the root is the default user for the image, which is not allowed as well. So a couple of things here, we can fix these problems. Let's just pop back over to our repo and I'll fix the Dockerfile. So you can see here, this is kind of a weird Dockerfile, so I'll just paste in some fixes here. Now I'm gonna expose a different port where my app is actually running instead of letting people SSH in. Not gonna install those forbidden packages anymore, I'm just gonna install something kind of mundane like them instead. I'll define a user, and I'm gonna put a health check in. So let's go ahead and commit that and see if it builds. Change is committed, and we'll just pop over. While we're waiting for that to build, though, I'll just go ahead and take a peek at like our vulnerability report, right? And just see that, yep, sure enough, you can see that was a pretty clean image. It's based on Alpine latest, but you can see we are detecting some vulnerabilities and they're flowing into the vulnerability report as expected. Okay, so let's pop back over to the pipeline and make sure that's building. And yep, our new one is building. Okay, it's done, so let's take a look. This time it passed. So we can see both the build and the scan stages passed, and sure enough, our evaluation did return a pass rating. You can see it also still uploaded the results of the JSON file for the security dashboard to consume. So if we hop back over to the anchor enterprise UI, let's take a look and see. We'll refresh here, and there's the new image. So here's the original one that failed and here's the new one that just got built. We'll take a look and sure enough, everything passes. All of those violations are gone and I even gave myself a cookie for including a health check this time. So it's a little positive reinforcement. So just to recap here, policy-wise, what we can do, as I mentioned, we wanna go beyond the bare vulnerabilities and look at the things that go into how the images put together. That can be things like, like we mentioned, vulnerability checks are one thing, but things like image typo squatting, just as an example. We wanna make sure, in this case, I'm not pulling images from Docker Hub instead, we're gonna pull images from this internal repository. That would be one example to prevent someone from doing, getting like a fat finger and saying engine Z when they meant engine X, again pulling a compromised image. Or we could do things like look at dependency confusion, right, where you're installing Python packages with pip and I might tell, put a rule in to say, hey, you can only cannot use public repositories and we're gonna instead have a internal repository of vetted packages as well. So things like that that just can prevent you from getting unvetted content into your images. A lot of different things we can do there. And this is all made possible by the way we scan images, we build a software build of materials that kind of enumerates everything that's in the image. And once we have that, we can build policy rules around anything that we can measure about the image. Just to recap a little bit, just to show some more of the integrations with GitLab, vulnerability report, this is a more comprehensive view here. You can see in this case, I've built an image that has a lot of problems. And all of the normal ways of filtering in the vulnerability report are available to you. Documentation-wise, it's pretty easy. You saw the CI file that I had built. There's really only a couple of things you need. You have to define the variables in your settings for the repository and off you go. And if you do wanna use the open source scanner called gripe, there's a link to the documentation there. And again, this is just for CVE scans. It won't get you the policy evaluations. Couple other things here, links to the documentation on the vulnerability report that's pretty standard and how we integrate in with the security dashboard itself. Just to show that real quick as well, so the security dashboard, if you're not familiar with it, is just a way we can kind of track over time how many problems you have in your images. You can see this is all coming from our scanner and everything's flowing in there just as easily as you would expect. All right, appreciate everyone's time. Here's just real quick. This will be available for download but I just wanted to put it on the screen so you have those links as well. And I hope everyone enjoys the rest of the conference. Thanks a lot.