WEBVTT 00:00:01.140 --> 00:00:02.460 Okay, let's get started. 00:00:04.440 --> 00:00:07.340 Now, we see various commands here, scan an image, 00:00:07.350 --> 00:00:10.720 scan the local file system, scan remote repository. 00:00:10.730 --> 00:00:14.300 Trivy has a lot of options, but for the purposes of this course, 00:00:14.310 --> 00:00:16.860 we're going to hyper focus on the image command. 00:00:18.040 --> 00:00:20.650 Let's go ahead and scan an image within Docker Hub. 00:00:23.440 --> 00:00:24.460 Let's scroll to the top. 00:00:26.240 --> 00:00:30.040 First off, we see Trivy complaining that we're leveraging the latest tag. 00:00:30.540 --> 00:00:34.530 Right now it's okay because we are not changing the underlying Docker image. 00:00:34.530 --> 00:00:39.440 Into the future, we are going to clear the cache during the docker build process. 00:00:39.450 --> 00:00:42.320 We'll see this into the future, don't worry about this now. 00:00:42.320 --> 00:00:47.460 As we inspect the vulnerabilities, oh my goodness, 711 vulnerabilities. 00:00:48.040 --> 00:00:48.510 Wow! 00:00:48.520 --> 00:00:49.060 Okay. 00:00:49.740 --> 00:00:53.550 If I was an engineer and I was getting this report, 00:00:54.040 --> 00:00:56.050 I would be somewhat overwhelmed. 00:00:56.440 --> 00:01:00.500 We need to take an iterative approach and prioritize these vulnerabilities. 00:01:00.500 --> 00:01:03.660 To do this, let's explore more command line flags. 00:01:04.840 --> 00:01:08.460 Okay, let's hop into the help text for the trivy image command. 00:01:09.540 --> 00:01:13.190 Okay, as you can tell, Trivy has a lot of different flags here. 00:01:13.190 --> 00:01:14.990 For the purposes of this course, 00:01:15.000 --> 00:01:19.050 we're going to focus on the ‑‑severity and ‑‑ignore‑unfixed flags. 00:01:19.440 --> 00:01:22.270 I highly recommend you check out this help text on your own and 00:01:22.270 --> 00:01:24.710 familiarize yourself with all of the Trivy options. 00:01:24.720 --> 00:01:26.730 First off is the ‑‑severity flag. 00:01:26.730 --> 00:01:30.280 You might be wondering, where does this severity come from? 00:01:30.370 --> 00:01:33.160 And the answer, as always, is it depends. 00:01:33.160 --> 00:01:37.750 It depends on the vulnerability feed in which Trivy uses. For a 00:01:37.750 --> 00:01:41.060 given vulnerability, severities can be defined within the National 00:01:41.060 --> 00:01:46.020 Vulnerability Database, or NVD, and by the vendor themselves. For 00:01:46.020 --> 00:01:50.630 example, for Ubuntu packages, Trivy leverages Ubuntu vulnerability 00:01:50.630 --> 00:01:51.950 feed. In other words, 00:01:51.960 --> 00:01:56.540 Ubuntu is the vendor. As Ubuntu can publish its own severities, Trivy will 00:01:56.540 --> 00:02:00.380 favor these ratings over the ratings in the National Vulnerability Database. 00:02:00.590 --> 00:02:05.270 And next off is ‑‑ignore‑unfixed. Right now, we just want to prioritize 00:02:05.270 --> 00:02:07.360 vulnerabilities that have a fix available. 00:02:07.940 --> 00:02:08.300 Okay, 00:02:08.300 --> 00:02:12.570 so we see we are filtering on a severity of critical, high, and 00:02:12.570 --> 00:02:15.380 medium, and we're leveraging ‑‑ignore‑unfixed. 00:02:15.650 --> 00:02:16.860 Let's check this out. 00:02:17.640 --> 00:02:18.110 Okay, 00:02:18.120 --> 00:02:21.750 I'm going to scroll to the top. Phew! We went from 00:02:21.750 --> 00:02:25.760 roughly 700 vulnerabilities to about 167. 00:02:26.240 --> 00:02:28.530 It's still a lot, but you know what, it's a little bit 00:02:28.530 --> 00:02:31.250 easier to sift through compared to the 700. 00:02:32.240 --> 00:02:32.430 Now, 00:02:32.430 --> 00:02:36.200 the one in front of us looks pretty critical. In libssl, 00:02:36.200 --> 00:02:41.060 we see the installed version 1.0.1e‑2. 00:02:41.940 --> 00:02:44.650 All right, we also see the fixed version as well. 00:02:44.860 --> 00:02:48.750 Let's scroll down a little bit and see some of the other libssl vulnerabilities. 00:02:49.640 --> 00:02:50.600 Uh‑oh, 00:02:50.610 --> 00:02:53.810 this looks like the Heartbleed vulnerability that allows 00:02:53.820 --> 00:02:56.670 unauthenticated attackers, in certain cases, 00:02:56.680 --> 00:03:00.890 to view the memory of a machine. Phew! We need to fix this, 00:03:01.160 --> 00:03:03.720 and we'll do this in the next demo. Before we move on to the 00:03:03.720 --> 00:03:05.760 next demo, let's do a recap. 00:03:06.940 --> 00:03:09.460 We reviewed a reactive Trivy workflow. 00:03:10.140 --> 00:03:12.750 We explored Trivy's various command line flags, 00:03:13.540 --> 00:03:16.660 including ‑‑severity and ‑‑ignore‑unfixed. 00:03:17.440 --> 00:03:21.570 We also leveraged Trivy to scan a Docker image and saw a nasty Heartbleed 00:03:21.570 --> 00:03:25.270 vulnerability. Now as far as the workflow cons, in my view, 00:03:25.270 --> 00:03:27.250 this was kind of a reactive measure. 00:03:27.840 --> 00:03:28.520 In other words, 00:03:28.530 --> 00:03:33.170 Trivy was scanning these Docker images after they had been released. 00:03:33.170 --> 00:03:36.990 Ideally, we would want to take a more preventative approach. 00:03:37.000 --> 00:03:42.130 In other words, there would be a Trivy scan within the release process. 00:03:42.140 --> 00:03:44.290 And if the Trivy scan failed, 00:03:44.300 --> 00:03:47.490 we would prevent the Docker images from being uploaded to 00:03:47.490 --> 00:03:49.950 the Docker registry. In the next section, 00:03:49.950 --> 00:03:53.260 we'll explore more preventative or proactive approach.