2:03 Introduction

2:03 Hello, and welcome to today's episode. This is Rawkode Academy. I am Rawkode. And today we are taking a look at Trivy, an open source vulnerability scanner amongst other things from the team over at Aqua Security. So say hello in the chat. We wanna know who's here. We wanna get your questions and have some fun today. And to guide us on our journey of Trivy, are going to be joined from Rory McEwan. Hey, mate. How's it going? Fantastic. Going well. Alright. I'm I'm I'm curious because we're both from Scotland if my accent is gonna change throughout the session back to my normal original

2:34 ramekin

2:47 voice or not. I was thinking that exact thing. The more I talk to people from Glasgow especially, my accent becomes more Glaswegian and harder for anyone else to understand. Exactly. I I don't know if you're the same as me, but, like, during my day job, I spend a lot of my time just trying to enunciate more and, like, speak normal English. So it's gonna be a complete regression today, I I think. And avoid putting Britishisms into chat. I had to explain to my Israeli colleagues that ta is thanks so many times. It's like, when I say

3:15 ta, I mean thanks. Hope you're wondering what I'm doing. Yeah. I don't think I've I've ever really said task. I think I'm gonna be alright there. Yeah. Just pop a few hellos up in the top corner. While I do that, Rory, do you wanna give yourself a wee introduction and let everyone know who you are? Sure. Yep. So hi, Rory. I work for Aqua Security as a cloud native security advocate. My background is security. I've been doing IT security for about over twenty years now. And vulnerability scanning, which is one of the reasons that I'm interested in doing this, is

3:31 rory

3:47 I've been doing vulnerability scanning for most of those twenty years. So it's something I've kinda had the pain of and the and the interest in for a long time now. So, yeah, I did pen testing, did a lot of technical stuff, did a lot of container hacking. And I also get involved with the community, things like CIS benchmarks, help maintain those for Docker and Kubernetes, and also participation in Kubernetes security and CNCF tag security. If you're interested in security in general and cloud native, those are two great places to get involved with. The meetings are open, anyone

4:19 can come along. Just listen. Or if you wanna participate and help out, then you can do that as well. Awesome. I thought containers couldn't be hacked. Right? Is that not why we just Well, my pen testing did say, well, we can have lots of fun hacking containers. That was that was great and still is great fun. Alright. Okay. Well, thank you for for sharing all that with us. It's a pleasure to have you here today, and I'm I'm looking forward to playing with Trivy. So for anyone watching who hasn't tried out Trivy, has never heard the

4:41 What is Trivy?

4:47 name Trivy, what is it that we are looking at today? Yeah. So what we're looking at Trivy is actually a project. It was I've been using this well before I worked for Aqua. And because back in pen testing days and if you're in security, one of the things you need to do is scan things for missing patches. Right? You look at our container image. You could look at a virtual machine. You could look at anywhere and say, is this missing security fixes? Is this being patched? And Trivy essentially is the best tool, in my opinion,

4:51 What is Trivy

5:16 for for scanning containers. And the reason is it's it's easy. Well, what we'll see is it's easy to use. It works well, and it covers a lot of ground. Vulnerability scanning in general is kind of this this you do it anywhere. You might want to do it on on VMs. You might want to do it against images. Anything that has, like, potentially missing security patches, you need to have some way of scanning them and checking them. And it's the kind of thing that gets seen a lot as a black box. Right? You know, you you run a scanner,

5:45 it puts out some results. But there's surprisingly amount of nuance and, like, things that can go wrong or things that you need to understand. So, hopefully, we can cover some of that today. Awesome. You're gonna I I I think I've got a I've got a couple of questions. Right? But Yeah. Go for What kind of things is Trivy looking for? What what what's the low hanging fruit here when we talk about scanning container images and other things? So there's a couple of sets of low hanging fruit because Trivy's got two main angles. First one is just literally saying, okay. Ah,

6:08 Lowhanging fruit

6:15 you're using an image. You're basing it on a base image like an Ubuntu image, and, you know, you haven't updated your your your base image in the last month. Right? You're now missing 20 patches. So what does it gives you that quick warning of, hey. You know, you're missing 20 things. Super simple. You need to update your base image, rebuild it. Those will go away. That's the first thing. But then also, you get the same thing at your programming language level. So you're using Ruby. You're using NPM. And the same deal. Right? You've not updated

6:42 your dependencies. It's not something people want to do. It's a bit of a chore. I mean, you see it in GitHub. Right? You see chore update dependencies. It is a chore, but this reminds you and says, hey. Something critical's come out. So this actually no. You might want to do this right now. If it's just mediums and lows, you might say, you know, next next month, next sprint, whatever. There's that side of things. And then there's other thing which Trivy is getting more into now, which is super useful, which is scanning all your infrastructure's code stuff.

7:09 So scanning your Terraform, also scanning things like Kubernetes manifests and Docker files and saying, hey. There are good practices that you could be doing here. For example, you should not be running your Docker images route, and you are. Right? Let's let's let's remind you, hey. You know, you can change this, and you get rid of that. Start running as a non root user. So that kind of thing as well. So it's kind of combo of different types of things that you can cover with it. Okay. Thank you for that. I I love the root conversation because I'm gonna throw a question

7:38 that, you know, is not directly related to Trivy, but I know that you've got the the knowledge to maybe guide me on this. Yeah. Is it okay for me to have my process and my container run as root if I'm using username space mapping on the host? That's an interesting question. The if you're using user namespace mapping, which is fun because it doesn't work super well in Kubernetes but does in Docker, then yes. Because your root user inside the container isn't actually root. Your root user inside the container is some high UID. So it's it's it's only as far as the container

7:53 Usernamespace mapping

8:10 is concerned. And I'm gonna give one small caveat to that, which is that usernamespaces in Linux have a bit of a mixed security history. There was a great example of this, like, two or three weeks ago. It was a CVE twenty twenty two or 185. How do you know the number of these things? Oh, I have a weird memory. CVE numbers stick and other stuff like, what I had to eat yesterday? No idea. CVE numbers were stuff I wrote about a while ago? Yeah. Easy. I can do that one. There you go. But so that CV was

8:41 really interesting because what it was was it was a local privilege escalation. So it's gonna let you get root on the host, but it needed Linux capability called Capsys admin. Now usually Capsys admin is like, you're you're already root. Right? So this isn't super important. However, Capsus admin inside the username space also got you access to this vulnerability. So if you're using username spaces, it it made this capability available. The code path that was exploited was visible, and you could suddenly compromise the host. So the thing about username spaces is they've got a bit of a

9:12 mixed history. They're a nice idea, but there are some extra tax or things that pop up if you use them. So in an ideal world, the best thing to do is probably run instead of using this space and don't use and don't use root users. Right? That's the ultimate. But then, like, I'm giving the security person's view, and I know that that's not always practical. So I I probably the easiest way to do it is try not to run a route in general. It's all it's it's the best option. Or just to run software. I

9:39 mean, that's another option. Right? Yeah. Kelsey Hightower's no code is actually the perfect solution. If you have no code, you have no vulnerabilities, and that's just, the perfect option. But if you do, unfortunately, have to run some code, then I mean, if you think about, like, the way we used to run apps before containers in the old days, most apps didn't run as root. Right? If you're running an application so so if think if an app would work okay in that environment, it should work okay as a non root container because it's literally the same thing.

10:07 It's just you need to have, like, your Dockerfile that is root for a little while while it does all the root stuff and then it switches. And I know that that's a bit of extra work, but once you've got it going, it's like it should be not too bad. That's the theory anyway. Awesome. Well, thank you for entertaining my little segue there. But let's jump back to the back of the task at hand. Right? So we're talking about Trivy. You mentioned something that I thought was really interesting, and it's that Trivy will prioritize some of the things that are scanned in

10:32 my cluster. And I think that's really important because I'm not sure who's using GitHub, but there's this, like, new feature that I think they bought from some other developer called dependabot. And I I have dependabot fatigue now from the amount of issues and pull request that's opening across all of my repositories. So I've been able to triage them in a way where something can tell me what ones are really important and I can go and look at would be a really cool tool. Yeah. It is cool. And I wanna give you my this is a nontrivy specific, but

11:03 Deep Dive: Vulnerability Scoring (CVSS)

11:05 but vulnerability scanning thing. And this is one of those nuances, like one of those things that I said, hey. This is, like, something you need to know is the way that vulnerability, vulnerabilities are rated. So the the way they get that critical high, medium, low is essentially, there's a a thing called CVSS scoring, and you get a number from zero to 10. But this is done by an analyst who doesn't know anything about your environment, and they don't know anything about how you deploy the software. So CVSS scores, especially in container land, can be a bit you know, you you have

11:34 to you can sometimes apply brain and go, you know what? That's actually not too bad. The the the the canonical example for me, there was one in Alpine, and it basically had a blank password in ETC shadow. So, obviously, on a VM, that's super bad because it means I can just become root. In a container, it only applied if you were using PAM. No one uses PAM in containers. You only have one user usually in containers, so it was totally irrelevant. But if you ran a vulnerability scanner on an image, it said, hey. You've got a 9.8.

12:00 You know, drop everything in patch now. But the reality was it really wasn't drop everything in patch now because in containers, who cares? So that's that's where save vulnerability scanning is one of those things that, like, you get those numbers and you can get that fatigue of, like, 20 criticals, 30 criticals. It can be hard to then to kinda say, have you, you know, make more sense of that? And there's a lot of work going on in the industry, and various different companies are looking at this. How do you make these things more, like, more targeted?

12:27 And Aqua have got stuff, that we do and other companies got stuff they do to try and say, you know, are there live exploits? So you can say, is there a live exploit for this issue? Okay. Now it's more serious. Now you really do want to fix this before bad things happen to your to your environment. So but it's it's one of those things. It's it's a funny one. Okay. So we've kinda covered that Trivy will scan my container images. It will scan my Kubernetes manifest. It can scan my infrastructure's code. It's looking not just for security vulnerabilities with known

12:55 CVEs, but also for best practices and to guide us. Where do I run it? So you can run it in a number of different places. You can run it just on a workstation. That is the one of the reasons I like Trivy a lot is you basically install it and run it. There's not a lot of fancy setup. Some of the container boundary scanners in the old days used to be, like, quite complicated. You had to pretend to be a container registry, which was awkward, but Trivy just works. We'll we'll as we'll see when we get to to running it.

13:01 Where to run Trivy

13:23 You can also run it in CICD pipelines. So, obviously, a lot of people will use GitHub. And one of the things you can do with Trivy and as I I was actually practicing this this morning to make sure I could remember exactly how to do it, was you can set up a GitHub action. And you can say whenever I, you know, push to this repository or whenever I build the container image, run a Trivy scan, and then integrate that with GitHub code scanning and tell me about and it goes in with the depend reports, you know, and you'll get

13:50 this thing saying, here's all your vulnerabilities. So there's a couple of different places you can scan it. You can also integrate it with container registries. So if you're using an on prem registry like Harbor, you can integrate Trivy with Harbor, or you can you know? So you can run it against any container registry as well. So it's it's pretty flexible in where you can actually, like, go and target this stuff. What I like about Trivy is you can give it to developers, and when they're writing the code, they can run scans on their desktops. And then you

14:20 when the same scanner later on, and then you get no surprises. Like, they know what's coming. Because one of the worst things about security is you don't tell people about the problem till it's, like, five steps into the process, like they're about to deploy live. And suddenly, it's like, oh, you failed and you can't deploy. Much better to tell people in stage one. You know, when you're writing the code, please run this thing and remediate these these issues so you don't get surprised when you're trying to push to live. Right? And that that I think that's one of the benefits.

14:48 Awesome. Well, I think we've covered enough ground on what and why. So shall we Yeah. We play with it? Yeah. Let's let's install and have a play and see how it all works. Alright. Let's see. I have my screen share here. I have the Trivy documentation, which I'm sure we will be leveraging today. And I have the GitHub repository here. So if anyone doesn't know how to Google, then you can go to github.com/aquasecurity/trivywith1v. I have been typoing it with two v's all week. But I'm getting better. I really am. Okay. So we've got a nice little

14:54 Hands-on: Installing Trivy

15:26 Yep. Is this like a coverage map of some sort? All the things that? Yeah. It's trying to give you that view I was talking about of the different things you can do and where you can scan. So you've kinda got trivia that the kind of base there, and then it says, you you can scan container images. You can scan the file systems as well, and this is kind of fun. You can actually scan virtual machines with Trivy if you feel like it. So you can use it for scanning your VM images. And I say that because, like,

15:48 there's there's what I'll call traditional vulnerability scanners, like Nessus and Nexpose and, you know, a lot of older tools that are in Qualys, obviously. But you can also use Trivy to do some of that as well. You can scan Git repos, so that's the three boxes across the middle. And then you can see the types of things you can scan them for. So you can scan for vulnerabilities and misconfigurations. Awesome. Alright. I'm gonna click on getting started and hope there's a That's always installed. That's always a good place to start. Yeah. So we've we've got an install link.

16:18 And then it's all down to what type of setup you're using. I am on a Mac. So You're on a Mac. So yeah. Go ahead. The Homebrew one. See. Let's make that a bit bigger. Oh, I've triggered the responsive design. That's that's all good. Alright. So we'll let that install in the background. So it's quite good support here. I love that when I see Next and NextOS support. So Yeah. That's pretty cool. I'm a huge fan of Next. There's a ton of different ways. And, yeah, there has been a lot of work done looking at fleshing these

16:49 out and, like, you know, it is one of the challenges with open source. Right? It's trying to meet everyone where they are per package. There's so many different package install options these days. Like, you know, which one are you gonna be using? It's it's tricky. Well, yeah, I guess so. I mean, it's written in Go, is it? Is that is that I just assumed that because we're, you know, in the cloud native space. But We're in cloud native. It's going to be Go. It is Go. Yes. Absolutely. Alright. I can see there's a whole bunch

17:13 of options for container images, which is great because I get rate limited from Docker Hub all the time. So I know. I actually and this is the thing I was doing this morning was I realized how simple it is to set up a GitHub action to build and push and also check digital signatures and do vulnerability scanning in, one action. So I'm I'm probably gonna move all my images to GitHub container registry now just for ease of use because I'm there. More like code is there anyway. Yeah. I've started moving all of my stuff over to GitHub's container registry as well. It

17:40 it just works really well. It's it's well integrated with GitHub actions. So Yeah. That's basically what I was like. I literally copy pasted this thing and it worked. I was like, oh my god. I was expecting at least an hour of fighting here. Woo hoo. Well, we have the Trivy CLI, a whole bunch of subcommands. But before we dive into that, there is a question from Joseph in the the chat. So I'll pop that on the screen. But Joseph is asking, how does Trivy keep itself updated? Does it get any latest info from any server?

18:08 What Trivy does

18:08 Yes. So what we'll see we'll see this when we run it. Is Trivy will download a database. So, essentially, what Trivy is doing, and they actually have a list of all the sources on the documentation, is it is pulling security databases for lots of different Linux distributions. So it's pulling Alpine, it's pulling Ubuntu, it's pulling Debian, Red Hat, all the all lots of distros. And that's how it finds out vulnerability information. Right? Because these databases online that are maintained that say which package versions of which CVEs. So it has to pull that down. It also pulls down the theme for, like, NPM

18:39 and Ruby gems and things like that. You can run it offline. You know, if you have a look at isolated air gapped environment, we do have instructions for how to do that. It is obviously more manual because you can't do that process, but it is possible. But in general, yeah, there's a database, basically, and it updates itself. So does this mean even if my infrastructure has a relatively old version of Trivy that it can still always get the latest security information to do scanning? Yes. I I wanna say that there will be times when database formats get changed, so it's

19:09 worth kinda keeping up to date. But in general, yeah. Yeah. Yeah. I I I was running a version of, like, at least two or three old before this morning when I updated it. And, yeah, it's still working fine. So, yes, it will do. But but, yeah, my caveat there is I'm sure that we'll get database changes as time goes on. Alright. You got a snarky comment from your colleague, and I speak slower. I made mistakes already. Sorry. So this is this is exactly the problem. Was we do speak people speak quickly. If you come to Glasgow

19:38 and you're not Glaswegian and you go into Glasgow pub, you will not understand what's going on. I'm sorry. This is why. Yeah. When you get that random tall person that just goes up to this. Alright. How you doing? Alright. Yep. Alright, mate. And then Alright. No. How'd you go? Okay. Yeah. No. I was gonna say, yeah, it will just be like that. So Yeah. Is I know it's still their best, but we'll we'll get it under We will our control. Okay. So we got Trivy still alive. We got all these sub commands. Do you want me

19:54 Understanding Image Scan Results & Unfixed Issues

20:06 to go back to the get started guide or should we just Should we do one? Let let let let's do one to to to make sure everything's working. So you can do the the most basic Trivy scan is to scan an image. So we do Trivy. So if we have run Trivy and we then give it the command image, and then we put in, say, Ubuntu colon 20 dot o four as a really standard image. Yeah. That's the And that's like my of Ubuntu, isn't it? Yeah. That's like that's the latest LTS. And you can see that was the thing

20:36 I was talking about at the database. There's it going and getting that database and downloading it. Okay. So I I've got a question. I as far as I know, I don't have the ubuntu image on my machine. In fact, right now, I don't even have a Docker daemon running. So I'm assuming it's Trivy. It's not going through Docker as a proxy or container d or anything like that. It's pulling the image itself. It's pulling image and and checking. So you don't actually necessarily have to have the image down. And and that's why it's using the same

21:02 URL format as Docker, which is it assumes Docker Hub if you don't tell it anything otherwise. If you're using that's why you're using Podman, you might get some funny results, but in general, you should be alright. Okay. Well, my font is a little big, but let's. Yeah. There we go. I could I could send that back in, but why don't we kinda walk through what what we've got here? So this will give you a big long list of it's not too long actually. And what you can see here is this is the basic information you're gonna get out.

21:37 And what you see at the top is you'll get a list of the severity of issues. So we've got 27 mediums, 40 lows, a total of 67 vulnerabilities. And then what it's gonna do is give you the package names, the CVEs, and then the severity rating and and where it came from. So why is it telling you you've got that? And then you'll also see at the right hand side, you get a little bit of a description, you know, what is this CVE. Now let's be honest. I'd say a lot of people probably wouldn't read that

22:09 that detailed information of each vulnerability, but it is there if you want it. And we also have an AVD link, which is a vulnerability database we maintain, which which has some more information. This image looks alright. It's all low, medium. There's nothing. Yeah. But the fun thing is, and this is I picked that image kinda deliberately. We've got 67 vulnerabilities in an image that is as fresh as possible from Docker Hub. So this is a Docker official image. This is one of the maintain supported things. Why do we have 67 vulnerabilities? And this is a weird nuance

22:45 of Debian and Ubuntu. Debian and Ubuntu both maintain a list of what's called unfixed vulnerabilities. So that's things for which there is a CVE, but they have not patched it yet. By default, all the container vulnerability scanners I've seen will tell you about those even though you can't patch them. So even if you got that image and you did apt update, apt up upgrade, it would still come back with 67. Most people don't want that because they can't patch it. So a very useful Trivy tip, this is my first useful Trivy tip of the day,

23:18 is a flag call ignore unfixed. So if you run that again and probably before the image name, just just you might I might work there or you might just put it before the image name. I think probably before the image name. And you run the same thing again. Zero. Perfect score. Because in reality, that's what you should get. Right? Because as far as what Ubuntu can actually do for you, that's zero. There's no you know, you've updated every package, which you'd expect. Right? Because that's the bang bang up to date image out out of Docker Hub.

23:53 Whether you want which way you want to run that will depend on your environment. Old school vuln scanners, like, again, Nessus and Expos, all the other traditional ones, they don't show you unfixed issues. In fact, I don't even think some of them can show you unfixed issues. So it can be a bit weird for people. They're like, oh, I've I've scanned my images and there's all these issues. Basically, I'd say most of the time you probably want ignore unfixed. It's not the default because that's how container scanners tend to work, but it's worth definitely adding that generally for Ubuntu and Debian based

24:20 images. Okay. Cool. Yeah. That works pretty well. We got a a snarky comment from Russell, but I'm gonna scan my clustered image because I'm curious. So Yeah. G c a h c r. Oh, I can't type. Typing hard. Clustered v one. So is it actually pulling down the the layers? Yeah. It's gonna have to pull the layers because it needs to look inside the layers. So it's gonna what what it's basically doing is it it opens up the image and it says, can I identify an and and what Linux is running here? And so you

25:03 can see actually on the on the output from the last time, it said detected OS Ubuntu. So it looks for for essentially files which indicate you're running Ubuntu or anything else. What's it? It's found Debian. Yep. It thinks you're clean, which if you built that image recently, you should be. I haven't built that in a long time. Oh, I wonder why that's come back clean then. By the way, it does say error gets in vulnerability details, failed to get the vulnerability, failed to I wonder why that's I wonder why. I've seen that morning actually recently, but I don't try it without an

25:33 ignore and fix, actually. I'm just curious to see what happens if you take the ignore and fix off. Oh, fine stuff. So it must I haven't did any patches since the last time it was built. And because in order to fix it, it it will still that consistently. I don't remember. I don't think it's been built in a while, but then Yeah. What about scratch images and such? So, yeah, it can do scratch. Now, obviously hold on. It can do no. It can do distroless. Distroless. And it can do scratch, and this is where it gets a bit funky. Obviously, scratch

25:59 Scratch images

26:09 doesn't have any packages, so you're never gonna get any package, you know, any distro level stuff because there aren't any distro packages to check. What it will still do is it can look inside Golang binaries, and this is a fun trick. I'm not sure if I find the right image to test this on. It can look inside Golang binaries because Golang binaries contain, like, package information. They're actually built into the image, and Trivy knows how to unpack that and find what you're looking for and say, here is the stuff, the Golang piece, because that's a problem

26:39 with scratch images in general is how do you scan them. Turns out there is a way of doing it, which which usually works. I think you probably could strip that information, at which point it wouldn't work anymore. But by default, you can scan inside Golang scratch images. Okay. Yeah. Because I can in the Go ecosystem where statically compiled binaries are are pretty much the norm. Like, know, the type those could be bundled with a whole bunch of, like, lib SSH or lib x and lib y, which potentially have vulnerabilities. So you're saying there is some support for pulling those out and understanding

27:12 them, but only if you don't strip all the GC information. I was gonna say, yeah. That that's the thing that in my head, I'm thinking that a security person will probably tell people to strip that information for security purposes, at which point your scanner fails. And there, that comes back to the, like, where do you scan piece? Because you said before, like, where can I scan stuff? Well, if you're doing that, so if you've got, like, a super hardened deploy process, then the place to scan is the repository. So you can scan the GitHub repo before

27:38 Scanning File Systems & Repositories

27:38 the thing gets built to find out. And we can and that's one of the things Trivy will work with. So Trivy will scan a GitHub repository directly if you want to or any did any Git repository. You just point it at the Git repository, and it will go and check. Alright. Well, we can try that in just a moment. We got another question this time from Jeffrey in the chat who is asking, if the image has already been pulled locally, does it still pull the latest version? You know, that's a good question. I think so.

27:59 Latest version

28:07 But it's one of those things that I would need to go and ask someone to be 100 certain. My my thinking is yes, but I would need to check. I'm not sure how how how we would test that. Is there a flag for that? Let's look. There's a clear cache. Clear. Yeah. That that because Trivy does have a cache. So if you rescan an image that hasn't changed, then, for example, if you got a latest image and you scan it twice, it will not it'll it'll it'll actually warn you about that if you do a latest

28:34 image. It'll say, hey. You're doing latest, and I might not know what latest is. But you can clear cache. So I said maybe the way to do it. If you want to be sure it's definitely pulling, you do the clear cache, and then we run the scan. Alright. Thank you for answering that. Should we scan a repository? Yeah. We can scan a repository. We've got lots of different ways we can scan. Fun stuff. So, yeah, if you just pick a a GitHub repo that's got things in it right and I've got the one that I can use. I've got the Pulumi

29:02 Pulumi repository here. Let's see what happens. And what it's doing here What have I got? You can you can scan it either in a file or you can scan it directly on the Internet. So you can just give it the URL of wherever it lives in GitHub. Alright. And it'll happily it'll happily go on to the Internet. So you do a Trivy repo. Is the repo scan? It should be up there. Yeah. I was I was close to that list, isn't it? And I was in a little order. I was getting myself very, very confused. Okay. Yeah.

29:30 I was looking at that as well. I was thinking where is it? Where is This scam fooling me. Why not? And then it's HTTPS or generally do. You could try without it and see what happens. It might complain. Or just gonna assume. No. It seems quite happy. Okay. We're getting it going. So yeah. So it's it's merely cloning away. Where does it clone to? It's like It's it's got cache directory. They've got a cache directory. Here we go. Alright. Let's zoom in a bit more. Unrevelties. Maybe that's getting too small, though. Yeah. So you can see how it's identified, like,

29:59 Identifying files

30:01 specific files inside. So, like, at the top of each table, it's identified a file and said, in this file, here's what I'm seeing. So you've got go some there in method unknown, and it's found some stuff in there. So this is saying that in the JSON web token go package, there's an access restriction bypass vulnerability. So if I want to know what that is, do I just go to this link? Yeah. You can go to that you can go to that URL. See, we've got a nice little kind of a and what that's gonna do is that's

30:34 gonna give you some information about what's affected, and it's gonna give you some some CVSS scoring. So that's that CVSS score I talked about. It's not terrible, but you have to recognize the person who came up with that score had no idea how you were using this package. So depending on how you use it, you know, you may or may not have an accurate rating. Yeah. So it seems to be that on Red Hat v three, it's moderate, but Red Hat v two is nonexistent. What does how does how do I interpret that? Yeah. Here's a fun here's a fun part about

31:05 scoring is different people will rate the same vulnerability differently. So there have been cases where NVD, who is the as an American organization, the national vulnerability database, they'll do an analysis, and they'll say it's rated x. A vendor may also say, well, we use this package, but because we use it in a certain way, we rate it as something different. This is where I said about, like, vulnerability scanning. Everyone thinks it's just a black box, But when you start getting into it, it's like, oh, no. There's a whole lot of weird edge cases to do with how these

31:34 things are rated. And so yeah. That one, I would say that one that it looks to me like is Red Hat v three will be a CVSS v three score. They may not have done it for version. So there's different versions of CVSS scoring. There's v two, which is the older version, and v three, which should be a bit more accurate, but not everything uses it. And typically, what I found just from, like, anecdotal is that v three scores tend to be a bit higher. So they they things rated under v three tend to get rated a bit more seriously,

32:05 and that's just to do with how they classify it. I I and this will give you my my controversial CVSS thing. I hate CVSS because and I'll explain why. There is a there is a good reason. It's not just that I'm a I'm a bad security person. When you see a number like 7.5, right, and you see a big long formula, you set that line where it says CVSS 3.1 slash something slash something and all that. Yep. It sounds scientific. To me, that sounds like it's science, and it's not science. It's opinion. That's an analyst's opinion of how exploitable something

32:36 is and how serious it is. But when you see 7.5, I think people think, oh, it's science. There's there's obviously you know? And no. No. It's it's people's opinions. Alright. Okay. Doesn't mean it's useless. Just means you should take it with with a grain of salt and go, this is just someone's opinion of this vulnerability, not necessarily the ground fact. Yeah. I think I'll just continue to stick my head in the sand when it comes to security. Yeah. You you you if you want my other fun, CVE, fact is that that you might think that

33:05 if there's no CVEs, it means something secure. Possibly not because some vendors refuse to issue them. So for example, IBM for their mainframe line, this is an official policy, so it's not some hack thing I'm saying. Their official policy is they do not issue CVEs for their mainframe line of products. So if anyone says to you, IBM mainframes are secure because there's no vulnerabilities, that's just not true. The only way you get their vulnerability list is by being a paying customer, and then we'll give you it. So another nuance of the vulnerability scanning world. Today, we learn.

33:38 So Russell is in the chat saying, so are not all seven point fives are equal. Yes. And the thing about it is is that that package has a vulnerability. The question is, does my code use the code path that has the vulnerability? So, like, is it exploitable? And that's a really hard question to answer. To be honest, it's so hard to answer that I typically say, you're probably easier just patching. Unless you really can't patch or it's gonna be really bad for you to patch, honestly, the easiest course of action is patch. What you could do is you could, like,

34:11 go and find the relevant code path, and you could go and say, does my does my application actually make use of that? If no, then put an ignore on it and and away you go. For Trivy, actually, I should mention, you can have a file called dot Trivy ignore, and you can put CVEs into that file. So you'd say, for example, I analyze the CVE. This has nothing to do with me. It won't affect my code base, and Trivy will stop reporting it. So you get rid of that noise out of your scanning results. Awesome.

34:40 Okay. Let's close this back down, pop over to our results the scan. So it seems to repeat. Is that the same CV? Oh, because then a different file. Different files. Yeah. So what it's doing is it's basically what it's doing is going opening each file that looks like it's something it knows about, scanning the versions, comparing the versions with what it has in its database, and then just saying, hey. You know, this one's that many versions or older. Therefore, it's got these vulnerabilities. Alright. Cool. So yeah. So scanning scanning repos is is is fun as well.

35:18 You can also scan obviously, you can scan, like, a downloaded Git repository. So you can like if you've got one local and you don't want to have it pull it down again, you can just say I want to scan locally. That's another option as well. So that was a Go project we scanned. You said there was support for other libraries as well. Yeah. Yeah. There's there's there should be I'm gonna find it on the oh, yeah. On that on the on the doc site, there's actually a list of all the things they scan for, and it's getting bigger every version. One of

35:39 Scanning packages

35:45 the things that I think is super important is we're supporting more and more Linux distributions and more and more package formats as time goes by. Okay. Awesome. How do I scan a local one? I tried So it's yeah. It should be Trivy FS. So Trivy space FS and then just a path. So local path that you've got. Sorry. F s Fails this. Foxtrot Foxtrot Sierra. Yeah. Not even I can understand your accent. I know. Well, I I'm up at Argyle, so I probably got the weird kinda like, you know, Argyle twang to it, I guess, now.

36:24 Okay. Something I've noticed between the go one and then this JavaScript one. So Yeah. It's not scanning my code, really. It's scanning the dependencies that my code has. So it's looking Yeah. At look at go mod with the go project. It's looking at the YARN and NPM, the package dot JSON for JavaScript. Guess that's the same across all supported run time. It's it's about the dependencies that you're pulling in and giving you insight into where they are vulnerable. Yeah. That that's a good really great point. Yeah. Trivy is not a static analyzer. So it's not gonna, like, go through your code

36:56 and go, oh, you're doing this thing and you record badly. That's not what it does. That's not its its its purpose. Its purpose, yeah, is to look through all the third party dependencies, that whole supply chain thing. I'm going, right, you've got this massive because if you think about about JavaScript, you know, an NPM project has got this massive pile of libraries, not just, like, the initial dependencies, but the dependencies of the dependencies and all the way down the tree, and you need to keep an eye on all of those. And I think that's it's an ongoing problem

37:22 is that that with a lot of ecosystems, you know, you have to use these these piles of of libraries and, you know, they have their own dependencies and it it can be quite large and quite kind of, like, complex as time goes by. It's a scary world we live in with this stuff for malarkey. It's yeah. It's tricky. Yeah. It's it's well, you saw you see in in in supply chain stuff, we've seen some scary things recently. Like, there was a person who they got angry that they weren't getting paid for their for their for their

37:39 Package maintainers

37:50 efforts. And so they nuked to their NPM libraries, pushed new versions over it. They just printed a lot of garbage text and broke a whole lot of packages, including things like Amazon CDK. But they broke they broke big packages because, obviously, the way NPM tends to work and everyone depends on anything else. And, yeah, that's that's scary. That and that's one malicious maintainer. And you think, well, he did something really obvious and really blatant and everyone could see what he'd done. Someone who's done something more subtle, you probably wouldn't notice if they did it, you know, cleverly.

38:20 Yeah. I think there was some package a call from maintainers a couple of years ago, and then they snuck in some crypto mining into it when they took over the package, and nobody knows for months. Much like months. Because, you know, if you've got a hundred or a thousand dependencies, you know, you don't have time to go through a hundred or a thousand dependencies. No one does. But there's not a lot of I've not seen a lot of take up for services that provide curated. Like, I've thought some people have tried as a business model. We'll curate

38:49 your packages for you. We'll do that work and, like, give you a feed that's only the ones we've checked, but doesn't seem to take off. Okay. Let's jump back on to our Yep. Trivy learning. Trivy, what else we can do? So we have done we've done image scan. We've done the docs. Right? You get the you are the docs. So Yeah. This is where I'm I'm hoping who's the main maintainer. I'm hoping he's not watching, and I wanna get and Teams, get all the things I got wrong afterwards. But hopefully not. So yeah. So we've done

39:09 File system scan

39:22 image scan, and, obviously, we can do file system scan as well. So we scan directories. We can scan root FS. So I don't know if we'll able to do that because it won't work on a Mac. But if you have, like, a whole Linux VM, you can just say scan root FS, and and they just point it at the root of your your virtual machine. And so if you don't have, like, an ordinary vulnerability scanner, like, you don't have one of the kind of traditional scanners, you can use Trivy for that purpose too, which is great.

39:46 Because you'll you'll get good results from that as well. But those all basically do the same thing. Right? They they do what we've just done, which is that they scan operating system and they scan programming language repositories as well. Okay. I think the thing that I'm really interested in that I don't think we've taken a look at yet is you mentioned that it can scan infrastructure as code and Kubernetes manifest. Absolutely. Maybe that's something that we could Yeah. Let's let's talk about that because that's that's fun too. So that's the conf option or config option.

40:20 And and what you can do there is you point to either a directory that has IC and things like that in it, or you point it at a a file. So you point to basically one file, one directory, and it'll and it'll check those. Okay. So if you have any or I can find a repo if we don't. I have some Kubernetes manifest. Awesome. I I don't need to specify the directory specifically. Right? If I just do a dot, it'll do subdirection. I think it will. I wish maybe give it I'll it a directory. Generally, I just give it directories to arms.

40:49 Kubernetes security checks

40:53 Oh, yeah. It's stuff. Yeah. It found them. It found them because there you go. So what it's doing here is it's doing a set of Kubernetes security checks. And these are checks that are essentially based on a thing called Kubernetes pod security standards, which is something the project Kubernetes project has come up with to say, here are things you should do to improve the security of your manifest. Okay. And we can see a variety of ones in there. There's our root user, the top one, your Dockerfile option. Yep. You've not specified a user in your

41:30 Dockerfile. But it but in in my defense, I leave this image wide open for people to intentionally break. Yeah. Oh, yeah. Yeah. Yeah. This is I I mean, I'm gonna honest with you. Most of my most of my images don't do that, typically because I don't do production. You know, my stuff is all just hacks for my purposes. If I I I promise I was a prod developer, I would do these things. Yeah. Yeah. Yeah. But yeah. So the the what it's doing with the Dockerfile is it's checking saying, hey. You haven't checked that. In Kubernetes, it's then

41:58 got a set of checks of things you can add. And this is a you you generally in Kubernetes land, you add these in security context. K. So the first one here is telling me that my cluster deployment should set a low privilege escalation to false. Yeah. I can explain that one. It's a it's a weird one. K. Go for it. Okay. So allow privilege escalation is a Linux primitive. And what it does is, say, I've got a Linux process running, and it runs as an ordinary user. It if you have that flag set to false, it can't get any additional privileges

42:36 once it's launched. So you can't have a container that gets additional privileges over the top of an existing what it's what it what it starts with. So for example, if I had a container and there was a set UID shell in there, if you try and ex you try and use that set UID shell to suddenly become root inside the container, it'll say no. Go away. You can't do that. And that's it's it's one of those things I think it's a it's a it's an easy setting. It will almost never break anything, and it and it's worth so it's worth

43:04 doing. Right? I've never seen a container get broken by setting that, so it's kind of a free hardening setting. And it's one of those ones that I wished Docker and Kubernetes had set by default, but they don't. So I had to switch camera because my room is very hot and I think my camera is overheating. Oh, yeah. I have that because I I have a Sony z v one and I it hasn't overheated so far, but it does does die if I leave it too long. But, yeah, I have seen a couple that do overheat.

43:33 Yeah. Yeah. Okay. We'll stay on this one for now. Okay. Let let them cool down. Open the window. It's too loud. Like, my my office space is an an industrial estate with Arctic lorries driving around big mad. So I'll probably keep the window closed, but I will turn off my camera. Yeah. Let it cool down. Okay. No big deal. We can use the other camera. So this is really cool, and this is showing me a lot of things that, you know, like I said, are best practice. I really should be doing these for my production deployment.

44:04 What I'm curious about is, can I just tell Trivy to make these changes? It doesn't do that. No. That's that's something we could look at. I mean, yeah. Some of these are quite easy to set. Some, I would be careful. Some of them, for example, could break things. A good example there is you got CPU requests not specified and memory requests not specified. So with containers, with Docker or Kubernetes, you can specify max CPU and memory. But if you get those especially memory, if you set it too low, you'll out of memory, kill the process. Because if you say

44:38 to if you say c group limit, you can have 512 megs of memory. You use over that. It'll just even kill the whole thing, which obviously has impact, and your process will die. So it's not something you'd want to set automatically. Nice. Yeah. I'm trying to work out what those resource requests and limits should be is always a trial. That yeah. That is the thing with Kubernetes. I I mean, it's in general problem with containers is like, you see why especially if you have a cluster with maybe ten, fifteen applications, it makes a lot of sense to limit

44:49 Code scanning

45:11 resources. But on the other hand, like, just like you said, how exactly do you make sure because you don't want CPU isn't too bad because it'll just throttle if you go above what you've said. Memory is the one that will it'll kill the process. You don't want to do that. So yeah. Okay. We've got a couple of questions that I'm gonna throw at you, and then maybe we'll take a look at the infrastructure code scanning. Yep. Yep. Okay. So asks or oh, that was the with our live debug. Oh, no. Debug. There we I used Trivy to scan for the log four

45:30 Q&A and Security Nuances

45:51 j vulnerability after fixing the log four j vulnerability. I rescanned it but still got the vulnerability and someone mentioned other Java libraries Yeah. Actually using log four j internally. So with Java, what it's doing is it's opening up each of those package formats and looking inside. And this is the problem with dependencies. If you have a dependency, you don't directly call Log four j, but one of your dependencies calls Log four j or a package you've installed calls Log four j. And then you have that same problem with, you know and tracking it down. I I that's why I can't get, like,

46:25 an instant answer is tracking that down could be difficult. It's really a question of understanding everything you're including in your image or on your VM and saying where is it pulling things from and get access to its manifest. Trivy should tell you what file it looked in, though. So it should tell you where did I find that version of Log four j. And Log four j is a nightmare because there's there's many different versions now. All of them have different horrible set of vulnerabilities. So yeah. Actually, I I believe it's called LogForge. Someone said to me the other day, it's

46:54 LogForge. LogForge. Yeah. Why would you call your logging package LogForge? But I've I've been told that's how it's meant to be pronounced. Alright. Moving on. I'll I'll I'm not sure I believe that. But, yeah, that's just what someone said it back there. I was I was I was dubious as well. Like, am I being pranked here to get me to sit sillyly on stream or something? I mean, I guess it's just a name that they like. I I just assumed it meant log for Java. Yeah. Exactly. That's what I thought. I was thinking it's gotta be that, but apparently not.

47:22 One of those weird ones. Alright. There you go. Again, today, I'm learning lots from you. Some of it useful, some of it not. Yeah. Some of this weird trivia that I store up and then just like, just bring us to mind. Yeah. What's the CVE number for Log four j? Oh, there were too many. I I I wanna excuse myself on the basis that there were literally, like, six or seven in quick succession. Every time they patched one. That's one of the problems with, like, a lot of open source vulnerabilities. What you see is that I I will

47:50 always call it the blood in the water. Once someone's done one thing, all these researchers who are super bright go, oh, that's an interesting one. We've not looked there now. Let's all go and, like, pull that code to pieces. And they did, and they found, like, literally half a dozen things. Yep. I you know, that that's kind of inevitable because there's so much code and, you know, good code reviewers are scarce because it's not an easy skill to learn. So, you know, it tends to be when something gets attention suddenly. Awesome. Alright. One more question, and then we'll we'll

48:22 pop back over to the terminal. I mean, I guess I could just we can pop here for a minute. Oh. Excuse me while I fix myself. No. It's decided to It's just because the seniors did different setup. That's okay. Yeah. So Russell now is asking, I'm guessing there is no easy way to find an exploit of a CVE for you to test your code against to see how susceptible it is. Yeah. Would be too valuable for misuse. You can do it. So there are exploit databases. There's several exploit databases you can search. The thing out a couple of points I

48:29 Exploit databases

48:58 would say about that. One, it doesn't necessarily mean the exploit will work on your code. One of the most important things about exploits and one of the reasons why certain vulnerabilities are more serious than others is ease of exploitation. If you get something where it's, like, universal, Log four g is a great example. Everyone could exploit that because it literally was, I make the application log a string and, boom, I've got an exploit. That's why it was so dangerous. There were so many different ways. Other exploits, you look at them and you go, they're serious, but you'll never even if you get

49:31 some code, try to make it work would be a nightmare. So there's that aspect. The other thing to watch out for and be very careful of is sometimes exploit code does not say what it says it will do. The people who write this either sometimes they are actively malicious and sometimes they just have a funny sense of humor. There's a guy called Andy Gill from Glasgow, and he wrote a thing called Honeypop, which was proof of concept exploit code that didn't do that. It just logged it to him that you'd run his code without reading

49:59 it. And he then wrote a conference talk based on the idea of how many people ran his code without reading what it did before they ran it. So be very careful when you go looking into exploit land is all I'll say. That's quite funny. Alright. Cool. So infrastructure is code scanning then, Rory. Yeah. So, yes, we we can do infrastructure code as well. So this I only have Pulumi code. So I'm assuming it doesn't do that. So we're gonna have to find a TerraForm repository. Right? We are. But, you know, Pulumi is something I think we should definitely be looking

50:29 Terraform

50:33 at adding. Well, I mean, because Pulumi uses, you know, real programming language, like, you can do dependency scan and at least you can be taking a look at the code apps or the typescript apps or the Python apps, etcetera. And I'm guessing the same kind of things as patterns we have in Terraform that that we know are bad, the same thing will apply to Pulumi. Right? Yeah. I think they would. You know, like, you can see someone doing something dangerous, like, I'm configuring an AWS resource, and if I run it this way, it's gonna be open to the world, which is

51:01 the kind of thing you can find in Terraform. Oh, this starter kit might be a good one. Unless you have something I should be cloning there. I'm telling whether I I have an I I probably can find a do we have oh, wait. There's an example link. There is actually in the in the Trivy repository on GitHub Mhmm. There are some examples. So it is a directory called is it called examples or is it called where is it? Yep. Those examples and then missed con. Oh, yeah. That's it. And then there's one called mixed. See the directory in there called mixed. Alright.

51:18 Scanning Infrastructure as Code

51:46 Let's clone this down then. Yeah. We can clone it down. I mean, we can we can do that. That will that will get us some stuff as well. This is, like, one of the things I always say that I really like about the move to cloud native, like, as a security person, is that this is possible. If you think about how people configure their infrastructure, like, go back to the early days or my early days, ten, fifteen years ago, it was manual changes to servers. People would log in to servers SSH style Yeah. And they

51:59 Cloud Native

52:20 would change things. There was no way it was very hard to audit that at scale without physically logging into every server and doing things. With infrastructure's code and with people moving to immutable infrastructure, you have the chance of seeing, I can scan this before I deploy it so that I catch the problems before they're in production, before some bright person finds them and exploits them and puts me on the latest, you know, blast of the day on hacker news or whatever. Yeah. I guess with everything being so declarative these days that we have these descriptions that

52:53 can just be processed and parsed. Yeah. And and and the magic then and this is one of the tough parts for scanners like Trivy and all the other there's like a lot of infrastructures code scanners. The challenge to my mind is keeping up with the rules. Mhmm. So the one I know about is Kubernetes. That's my kind of area. And every time Kubernetes does a release, they add new stuff. And therefore, all the IAC scanning tools have to go back and say, hey. This version is a good example. There was a thing called ephemeral containers that got launched in

53:24 Kubernetes 01/23. And now all your I see scanning tools or your admission controllers have to know about ephemeral containers. Otherwise, they won't, like, find stuff properly. So the the eternal problem of of newness. Alright. And remain making. Which directory in here did you say? There's one called mixed mixed definitely has something in it. I I looked. There was some Terraform files in there. In configs. Yeah. That was it. Yeah. There's a t f files. There's couple t f files there. So Trivy config. I've done yeah. If you're in the directory, you should yay. Page it. Okay. So it

53:50 Reviewing IaC Scan Results

54:03 vendor Docker file. Yep. And there And CloudFormation. So we're doing CloudFormation as well. Oh, there we go. Yeah. Okay. I was trying to work out what that YAML was. I was like, how is this, like, a cross play or something, but it's quite it says right there is Cloud information. Okay. Yeah. Yeah. So it detects different types. And this, again, this is one of the things that the Trivy is expanding over time. So recently, we got a couple of of of great guys into the team who wrote TF sec, which is a Terraform security tool, and that's

54:35 integrated now into Trivy, which is fantastic. So now you can just run Trivy, and it will, you know, do this TFsec stuff as well, which is great. So we can see here Yeah. That it's complaining that our s buckets are public. Yeah. Right. So that that's the kind of thing and this is, again, this is another one where, like, you do have to think about responses from these scanners. You can't take them blind because it may be that your s three bucket's meant to be public. Yep. You might be hosting public documents there, but you might not.

55:06 And so all this the scanning tool can do is it can say this stuff looks you know, here's your investigation. And in general, this is a challenge for security people because sometimes auditors will use these tools, and auditors don't always understand the technical details of what they're scanning. And this but but I don't think there's a good way to get away from that. Apart from if I was doing this work, I would run the scanners myself and have an answer for their questions. So if you know if says, hey. This this s three is public, go, yep. That

55:34 one's allowed. It's holds the stuff here. We know what's in it. It's a static website. It's supposed to be Exactly. It it it's our t's and c's that we give to all our customers or something. You know, it's it's public docs. Yeah. But it's important to get these messages. I actually recorded a video of the Polyvio channel just last week talking about the three major exploits in the last two years, and all of them are related to ACL on a s three bucket. Yep. Hundreds of thousands of private documents in the Ghana government and all the citizens was released to the

56:03 public. Game companies are seem to be bad for this as well. Game companies only can do a left, right, and center via s three buckets. It it doesn't surprise me because I like, a lot of enterprises now, it seems like their entire IT infrastructure is in the cloud. Yeah. And I go back to my old corporate security days when everything was hidden behind the corporate firewall, so at least you couldn't easily see it. I mean, it still was hackable, but you had to get past that firewall. And back then, those I always called the networks warm smarties.

56:11 Broader Security Discussion

56:30 So they're crunchy outside, they're all gooey and soft on the inside. And now everyone's put all that stuff straight on the Internet. If anyone from non UK is watching, warm m and m would be the international equivalent of warm smarty. I call them warm smarty networks. But now everyone puts that stuff straight in in AWS, and then you're right there on the Internet. If you make that same one mistake, you know, you don't understand something. You've got a line in a YAML file wrong, and suddenly it's odd here, some bad person has found your stuff. And Yeah. But this maybe

57:00 I I I said I would say there's just security, but I'm seeing this massive push towards zero trust, but we're still so early in education of zero trust to develop Yep. That that there was weirdly, this is like, you know, they all see what is old is new again. So in literally 02/2002, when I was starting in security, there was a thing called the Jericho Forum in The UK who pushed something called deperemeterization, which is the exact same thing as zero trust. It was removed the firewalls, put everything on the Internet because you have to be able

57:31 to trust things. Smart's not global. I I think they're not global. I think I don't I think Americans don't have smarties. I believe it's horrible to say, but but I believe it's true. So, yeah, zero trust is my my business. Today. Right? Yeah. Zero trust is cool if you're doing it right. Like, if ever I mean, yes. They're right in theory. Right? It's one of those things. In theory, they're right. Every system should stand alone. It shouldn't trust anyone. It shouldn't say I want a trusted network. It should just be in reality. That's not how things work. People make mistakes.

58:03 They stand up demo systems. They stand up test systems. They don't always patch or secure. And putting those all on the Internet sounds like a kind of dangerous idea to me. Luckily, I'm not in that world, so I'm very happy not to be in that world. I I guess that's your option. Because you put everything on the Internet, and you learn how to secure it properly, and you try to keep up with modern trends, or you stick Bastion Box or VPN. And Yep. But then you still got lateral movement beyond those parameters. So, like Yeah. Is

58:30 do you need to do both? I I I would. I I have this I have this concept. I I I did when this talk with a guy from GCHQ, and he had this concept. I won't use the real his the way he called it because it's a bit rude on stream. I call it mess up tolerance. He called it something else to up tolerance. And the idea is, like, you don't want to have a mess up tolerance of one where if one bad thing goes wrong, your entire network's stuffed. And that to my mind, if you put

58:55 things on the Internet, like Kubernetes API servers, there are 900,000 Kubernetes API servers directly connected to the Internet. One bad day, you may lose a set of creds, you make a mistake with your RBAC, and your entire cluster could get compromised, and all the hosts and all the workloads get go down with it. That's a messed up tolerance of one. To my mind, put it behind the bastion box, then at least two things have to go wrong. Someone has access to your bastion, and you have to make a mess up with Kubernetes. And you saw that, like, make your life

59:22 that little bit less painful because everyone makes mistakes. Right? I make mistakes. You make mistakes. We all make mistakes. I've never made a mistake, Rory. No. Me neither. My my my mistake is perfect. And don't go and look at my repositories and look at the ones I've enabled VON scanning on, and you won't see all the hundreds of issues that I haven't patched. Cool. Well, let's go back to the important topic for today. Yeah. Thomas Laff has told us that they have Smarties in Croatia. Oh, well, that's good. However, Russell has done some research. Good to find you there. But the term

59:56 Smarties in The US is used for what we call refreshers. Good grief. That's a terrible one. That you could very badly wrong there. So the question I've got is, Thomas Lav, what is a smarty in Croatia? Because maybe we're making too many assumptions. That's true. We're assuming. So a smarty is is a nice crunchy candy shell with chocolate inside. Good chocolate, not American chocolate. Alright. We we we on an hour. No, Rory. And I'm I'm having fun. I I could just sit here do this all day. But do you want to show us the GitHub

1:00:27 CI/CD Integration Demo (GitHub Actions)

1:00:29 actions workflow or would you rather leave that for another session? You want to? Let let's quickly. I'll show you now because I I'm gonna do a blog on this because I I just looked at this today, and I was like, this worked really well, and I was super happy with it. So I was I'm I but there will be a blog that that goes into this some more detail. I'll try and get out the week or two, and I'll I'll tweet it out. Yeah. Just get a link over to me. I'll drop it in the description as

1:00:49 well for anyone watching after the fact. Yeah. So we'll get that sorted out. I wanna I wanna show you our our let me get my window, and it's this window here. So let's share that. So that should pop up now. And this is a this is a repository I have for a little Ruby on Rails project I wrote, which is a little thing I did for attack trees. It's not super important. But what I've got here let me just make this a bit bigger. Thank you. Is I got the the basic container build GitHub action,

1:01:22 which is this one here. And this actually worked really well. I was super impressed by this just worked when I built it. And what this does is it builds up a a docker image and pushes it to GitHub, put to GitHub container repo. The other really cool thing it did, and I did literally didn't know until this morning, is it uses cosign. And cosign is yeah. I was I was so impressed. So cosign for anyone who's not seen it is a digital signing tool. Essentially, will essentially put digital signature on your container image, and anyone

1:01:55 who used your container image later can verify that signature and make sure that the image has not been tampered with since it was pulled down from the registry. This is a really great thing. And in general, signing has been, like, a awkward to use thing, so it never really gets traction because it's hard. It's painful. You have to manage keys. This just worked. Like, I installed the action, and it worked. It was magic. I was like, wow. So impressed. But so it did all this, and you see it's doing docker build, and it's pushing the image.

1:02:26 And then what I did down the bottom here, you'll see at the very bottom here, I've got run Trivy. So this is from our we have a a trivy action, and you see it just have a users, so it's gonna use the trivy action, and it's gonna tell it what image I really should make this parameters and I will, but right now, just named the image as I was I was doing it quickly. We used an output format called Serif. Now Serif is just a way of, like, marking up your vulnerabilities, gave it a name, and that's just the

1:02:54 default name. Then we did this cool thing here right down the bottom, which is we upload the the results to GitHub security. So GitHub has a security tab on every repo, and you can get scanners to integrate with that. This will work on any public repository. I think if you use a private one, you have to be like an enterprise customer. But if your repo is public, it will work. And it will actually upload it into into GitHub as a result, which is really cool. The only trick, and I will put this in the blog, that I need that I

1:03:25 got wrong, like, three or four times. You can see all my failed runs. You look in this repository. Is you need to give it security events right permission. So there's a little permission to add there into the permission section that wasn't there in the default action that lets upload the SARIF file. Are these permissions things new? I've I've honestly, I've never seen those before to get back And I hadn't either, which is why I was like so I was doing my u the usual thing. Right? I errored out in the action, and I went and googled

1:03:51 that exact error message. And some, like, playing around and where exactly do I put this thing later, I worked it. That's where you put it. So you put it inside the build. These ones were already there. So these ones were part of the base, like, the the one that GitHub gave me. Mhmm. And then I just added that line there, security events. Right? And the end result is is that that it will do that. It will build the image, and then you go into the security tab, and what you'll see is I have 963 code scanning results.

1:04:21 I didn't turn on ignore unfixed yet. I will turn on ignore unfixed, and that will drop that number down. But, basically, what you can see there is you can see all of Trivy's output essentially in there. You can see all the different CVs. Yep. So that's really nice integration. Right? If you are if you wanna use it as part of your CICD, just plop it in an action, have it whenever you push or whenever you build your images, and it'll keep you up to date and let you know, hey. You've got, like you know, you need to go rebuild your base

1:04:48 image or something or you need to go and upgrade your gem file. In my case, it'll be a gem file and or a YARM mock file. There's gonna be stuff in there for all of those. Sweet. Awesome. I like that. That's very cool. I know. I was like it's one of those things where I thought, I'm just gonna try and get this working so I can talk about it. Didn't expect to actually get it working this morning. And I was like, oh, this actually worked. I'm I'm pleasantly surprised. Well, I'm I'm I'm really glad that I

1:05:11 have walked well, I will be walking away from today's session. Understand the Trivy and how to integrate it. But permissions and a workflow. There we go. That's the value add for me today. Because I Yeah. That was that was something I learned today as well. It's like, never a bad day when you learn something new and I learned about permissions and GitHub actions. I'm then motivated to go play with it some more. And everyone should also be cosigning all the things. Right? Yes. Cosign is so cool. And I yeah. Cosign container images. You can cosign binaries as well,

1:05:40 Importance of Cosign

1:05:40 and then you can integrate. So a good thing you can do now, again, come back to Kubernetes, is you can put an admission controller onto your clusters that will check those signatures. So it'll say Right. Am I only getting the same images in my cluster? So if you have a prod cluster, you can start sending your production images, and that stops people, like, using images you're not expecting. Right? Because it's always a problem. Someone might start running an image from Docker Hub. Those things could be anything in large part. So you only want trusted images. So you can start trying

1:06:07 to do that. And I I I think we'll see more support for cosign this year as time goes on. I know that the RubyGems folks are discussing adding it for RubyGems packages. So the the there's an RFC in for, like, actually signing the RubyGems. So, hopefully, we'll see more of that as well. Awesome. If you get anything else to share on your screen share, will pop us back over to the I will pop pop us back over. Yeah. Cool. Alright. Well, thank you for joining me today sharing Trivy with everyone. And not just Trivy, just your general knowledge across the board is

1:06:32 Conclusion & Farewell

1:06:39 always wonderful to have a a conversation. And, I mean, Smarties was pretty important, but there was lots of other good stuff in there too. But we'll focus on the Smarties. I mean, we could tagline for the for the episode there. We talked about Smarties. And I hope Harry is still with us and still understanding most of what we say. I hope he's Oh, I'm I'm probably gonna get my slowdown afterwards in Teams. Alright. We got a great stream from Russell. Thanks, mate. Any last words, Rory, before I let you get back to your day? Nope. Nope. If anyone's got any questions, I

1:07:09 will say, Racine there is on my is my Twitter handle. It's also my GitHub handle. Feel free to just ping me or drop an email. Either way, I'm easy to find online and always happy to try and answer questions. Awesome. Well, thank you again for joining us. Have a great day. I hope to see you soon. Maybe at KubeCon Valencia, and Yeah. Till then, I don't know. Stay healthy. Is that the pandemic? Wait. You're saying things off now? Yeah. Sounds possible. Alright. I'll speak to you later. Thanks. Cool. Cheers.