WEBVTT 00:00:01.140 --> 00:00:03.230 Sweet, onto our first demo. 00:00:03.390 --> 00:00:06.560 In this demo, we're going to review a reactive Trivy workflow. 00:00:07.740 --> 00:00:09.750 We're going to explore Trivy's command line flags. 00:00:10.340 --> 00:00:13.250 Then, we're going to use Trivy to scan a Docker image. 00:00:13.940 --> 00:00:15.790 First off is the reactive workflow. 00:00:15.790 --> 00:00:19.160 We'll get into why this is called reactive within a second. 00:00:20.140 --> 00:00:21.200 Within the slide, 00:00:21.210 --> 00:00:23.360 we're going to discuss how Trivy can be leveraged 00:00:23.360 --> 00:00:25.460 within a typical Docker build process. 00:00:25.470 --> 00:00:29.490 It all starts with the Dockerfile housed in the Git repo. 00:00:29.490 --> 00:00:31.890 In this course, we're going to be leveraging GitHub. 00:00:31.890 --> 00:00:35.450 The Dockerfile contains various Docker configurations, 00:00:35.450 --> 00:00:38.320 such as what version of Apache is going to be installed. 00:00:38.320 --> 00:00:39.020 In this case, 00:00:39.020 --> 00:00:43.120 we can assume that there is an engineer on the updates branch who 00:00:43.120 --> 00:00:46.170 is trying to make an update to the Dockerfile. 00:00:46.170 --> 00:00:48.690 When they proceed, they're going to raise a pull request, 00:00:48.690 --> 00:00:53.790 which is basically an area where people can collaborate on the changes. 00:00:53.790 --> 00:00:57.160 Once everyone has come to a consensus on the pull request, 00:00:57.170 --> 00:01:00.680 the updates are then placed into the main branch. 00:01:00.680 --> 00:01:04.580 We can think of the main branch as what is released into production. 00:01:04.580 --> 00:01:08.140 This process goes ahead and kicks off a build process, 00:01:08.140 --> 00:01:11.380 in this case the Docker image creation process. 00:01:11.380 --> 00:01:14.130 So let's dive a little bit more into this process. 00:01:14.130 --> 00:01:18.000 The Dockerfile is used to build the Docker image, 00:01:18.000 --> 00:01:22.070 and we can think of the Docker image as a lean virtual machine image. 00:01:22.070 --> 00:01:25.920 And the Docker image creation process occurs on a build server. 00:01:25.920 --> 00:01:26.850 In our demo, 00:01:26.850 --> 00:01:29.840 this build server is going to be hosted by GitHub and is a part 00:01:29.840 --> 00:01:33.940 of a GitHub feature called GitHub Actions. Our GitHub Actions 00:01:33.940 --> 00:01:36.870 build server will be Ubuntu 2004. 00:01:37.000 --> 00:01:41.530 Once everything is built, it is then uploaded to the Docker image registry. 00:01:41.530 --> 00:01:45.240 In our course, we're going to be leveraging Docker Hub. 00:01:45.280 --> 00:01:45.540 Then, 00:01:45.540 --> 00:01:49.340 the server pulls down the new version of the Docker image and uses 00:01:49.340 --> 00:01:53.540 that Docker image to instantiate a Docker container, 00:01:53.540 --> 00:01:59.040 in other words a running application, similar to a running virtual machine. 00:01:59.040 --> 00:02:02.640 Now Docker containers and virtual machines are somewhat different, 00:02:02.640 --> 00:02:06.950 but for the purposes of this course, we can think they are roughly similar. 00:02:06.950 --> 00:02:09.300 I just wanted to take a quick aside. 00:02:09.300 --> 00:02:13.280 As a blue teamer, you might not be involved with building this workflow. 00:02:13.280 --> 00:02:13.720 However, 00:02:13.720 --> 00:02:16.870 it is vital to understand this process so you can 00:02:16.880 --> 00:02:20.040 introduce security tooling and just be a general security 00:02:20.050 --> 00:02:22.510 advocate within the build process. 00:02:22.510 --> 00:02:27.070 And then we see Trivy, similar to a previous slide, that audits 00:02:27.070 --> 00:02:30.490 directly the Docker images within the Docker registry. 00:02:30.490 --> 00:02:33.650 In our first demo, we'll assume this workflow is in place, 00:02:33.650 --> 00:02:37.120 and, in particular, we'll focus on Trivy's ability to scan 00:02:37.120 --> 00:02:38.650 Docker images from the registry.