WEBVTT 00:00:01.040 --> 00:00:05.060 In this demo, we're going to review a proactive Trivy integration. 00:00:05.640 --> 00:00:07.870 We're also going to use GitHub Actions to integrate 00:00:07.870 --> 00:00:10.460 Trivy into the code review process. 00:00:10.940 --> 00:00:12.810 We're also going to look at a consumer view. 00:00:12.810 --> 00:00:16.430 In other words, when an engineer is submitting code changes, 00:00:16.440 --> 00:00:18.970 what does this process look like to him or her? 00:00:19.050 --> 00:00:22.390 We're also going to look at this from a technical viewpoint, in other words, 00:00:22.400 --> 00:00:25.100 look at the underlying configurations and scripts that 00:00:25.100 --> 00:00:27.150 are powering the proactive integration. 00:00:27.150 --> 00:00:30.210 In the previous diagram, or in other words, 00:00:30.270 --> 00:00:32.390 the reactive workflow diagram, 00:00:32.390 --> 00:00:36.550 we witnessed Trivy auditing Docker images within the Docker Registry. 00:00:37.240 --> 00:00:39.490 We started with this approach for simplicity, 00:00:39.490 --> 00:00:42.820 but now it's time to up our game and move from a 00:00:42.830 --> 00:00:45.660 reactive to a proactive approach. 00:00:46.240 --> 00:00:48.960 Trivy can audit Docker images in other places too. 00:00:49.340 --> 00:00:51.450 For example on my personal machine, 00:00:51.530 --> 00:00:54.080 I can build a Docker image and store it locally. 00:00:54.080 --> 00:00:56.960 Then I can use Trivy to audit that local image. 00:00:57.440 --> 00:01:01.550 By extension, we can use GitHub Actions to perform this task as well. 00:01:02.140 --> 00:01:03.230 Behind the scenes, 00:01:03.290 --> 00:01:06.360 GitHub Actions can create an Ubuntu server that is 00:01:06.360 --> 00:01:08.430 hosted within GitHub's infrastructure. 00:01:08.520 --> 00:01:11.980 We can then use that server to audit for changes before 00:01:11.990 --> 00:01:15.060 uploading the Docker image to the Docker Registry. 00:01:15.540 --> 00:01:20.250 Even better, we can see the results of this Trivy scan within the pull request. 00:01:20.840 --> 00:01:25.660 This allows an informed discussion to occur before incorporating the changes. 00:01:26.540 --> 00:01:31.690 Remember, GitHub Actions as an isolated environment where we can run custom code, 00:01:31.690 --> 00:01:34.090 and it's awesome that we can take advantage of all of 00:01:34.090 --> 00:01:36.150 this from a security perspective. 00:01:36.150 --> 00:01:40.410 As we previously stated, we'll start with the consumer view. 00:01:40.550 --> 00:01:43.850 In other words, when an engineer is submitting some code changes, 00:01:43.860 --> 00:01:45.360 what does this process look like? 00:01:45.840 --> 00:01:48.110 Let's assume that we are an engineer trying to 00:01:48.110 --> 00:01:50.250 propose new changes for a Dockerfile. 00:01:50.250 --> 00:01:51.300 In this command, 00:01:51.300 --> 00:01:55.560 we go ahead and switch to an updates branch so we can isolate our changes. 00:01:56.040 --> 00:02:00.650 This updates branch correlates to the updates branch in the previous diagram. 00:02:00.650 --> 00:02:03.860 Let's go into the Dockerfile and make some changes. 00:02:05.540 --> 00:02:08.960 First off, we're going to add some additional apt‑get installs, 00:02:09.440 --> 00:02:13.160 for example, Apache and wget and build‑essential. 00:02:14.540 --> 00:02:18.050 We also are going to install a version of libSSL. 00:02:18.050 --> 00:02:22.350 Remember, this can be basically anything that you are installing. 00:02:22.840 --> 00:02:24.970 I'm going to go ahead and save the changes. 00:02:24.970 --> 00:02:26.470 At this point, 00:02:26.480 --> 00:02:29.820 I'm going to go ahead and commit the changes and push them up to GitHub. 00:02:29.830 --> 00:02:31.450 So we are in the GitHub UI. 00:02:32.040 --> 00:02:35.270 We see the updates branch recently had some changes. 00:02:35.270 --> 00:02:36.710 As an engineer, 00:02:36.720 --> 00:02:39.100 I want to create a pull request so my teammates can 00:02:39.100 --> 00:02:40.560 discuss these changes with me. 00:02:42.040 --> 00:02:42.520 Perfect. 00:02:42.530 --> 00:02:44.710 It looks like we are trying to merge our changes from the 00:02:44.720 --> 00:02:47.050 updates branch into the main branch. 00:02:49.640 --> 00:02:52.670 I'm going to create a pull request. 00:02:52.670 --> 00:02:56.050 Now we see the GitHub Actions running. 00:02:56.050 --> 00:02:59.350 While we wait, let's go ahead and look at some of our differences. 00:03:04.640 --> 00:03:07.600 So the first item I actually changed outside of this course 00:03:07.600 --> 00:03:09.350 just to make things a little bit more clear. 00:03:11.640 --> 00:03:13.860 Perfect,w e see the Dockerfile being updated. 00:03:14.340 --> 00:03:17.960 Notice the new versions of libSSL that are being added. 00:03:19.140 --> 00:03:20.760 We'll check this out in the Trivy output. 00:03:28.140 --> 00:03:30.490 I'm going to go ahead and click on Details. 00:03:30.490 --> 00:03:33.660 Interesting, this red here doesn't look good. 00:03:34.140 --> 00:03:39.630 Let's expand the Trivy execution step. 00:03:39.630 --> 00:03:46.400 At the end of the output, we see This Docker image contains a vulnerability! 00:03:46.480 --> 00:03:47.340 Please fix! 00:03:47.600 --> 00:03:50.660 Okay, let's see what vulnerabilities were introduced. 00:03:53.040 --> 00:03:56.310 There's 148 vulnerabilities in this image. 00:03:56.310 --> 00:04:00.550 Interesting, so we see the libSSL library has a bunch of vulnerabilities. 00:04:00.550 --> 00:04:02.730 And you see the installed version? 00:04:02.730 --> 00:04:05.040 That correlates to the installed version that we 00:04:05.040 --> 00:04:06.850 were adding within the Dockerfile. 00:04:07.240 --> 00:04:09.160 We also see the fixed version as well. 00:04:09.540 --> 00:04:11.450 This would give us, the engineer, 00:04:11.460 --> 00:04:14.460 actionable insight into how we can fix this vulnerability. 00:04:15.840 --> 00:04:18.750 And once again, we see the Heartbeat extension packets. 00:04:19.140 --> 00:04:23.250 This correlates to the Heartbleed vulnerability that we saw in our first demo. 00:04:25.440 --> 00:04:27.750 Let's go back into the main pull request view. 00:04:30.540 --> 00:04:31.940 Let's go ahead and refresh. 00:04:33.440 --> 00:04:35.460 So we see the status checks have failed. 00:04:35.460 --> 00:04:38.040 While it's not overly evident right now, 00:04:38.120 --> 00:04:41.150 this will actually prevent the changes from being accepted. 00:04:42.040 --> 00:04:46.900 Let's look at the configurations that are driving this blocking behavior. 00:04:46.900 --> 00:04:51.330 Going to click on Settings. 00:04:51.330 --> 00:04:55.900 Then I'm going to click on Branches. 00:04:55.900 --> 00:04:59.810 Check this out, Branch protection rules. 00:04:59.810 --> 00:05:03.020 Define branch protection rules to disable force pushing, 00:05:03.020 --> 00:05:05.390 preventing branches from being deleted and, 00:05:05.390 --> 00:05:09.470 most importantly, optionally require status checks before merging. 00:05:09.470 --> 00:05:11.760 Here, let's dive into this a little bit deeper. 00:05:17.540 --> 00:05:20.480 So the first rule enforces that another member of 00:05:20.480 --> 00:05:22.460 the team must approve the changes. 00:05:24.340 --> 00:05:28.960 Also we see that we require status checks to pass before merging. 00:05:28.960 --> 00:05:34.700 The Scan Docker images workflow that we define actually is a status check. 00:05:34.730 --> 00:05:39.460 In other words, this workflow must pass in order for us to merge the changes. 00:05:40.440 --> 00:05:42.610 By us activating the security control, 00:05:42.610 --> 00:05:46.760 we can block vulnerable Docker images from going into our environment. 00:05:47.340 --> 00:05:49.050 Let's go back to the main UI. 00:05:51.040 --> 00:05:53.450 So at this point it says merging is blocked. 00:05:53.450 --> 00:05:57.250 Merging can be performed automatically with one approving review. 00:05:57.840 --> 00:05:59.360 Now this is a little confusing. 00:05:59.740 --> 00:06:04.050 If we had another approver on the team that approved this pull request, 00:06:04.220 --> 00:06:08.710 it would then still block because the Trivy status check has failed. 00:06:08.710 --> 00:06:11.600 Since I'm an administrator on this repository, 00:06:11.610 --> 00:06:14.130 I can override these settings, but obviously, 00:06:14.130 --> 00:06:17.460 normal users are not going to have these elevated permissions. 00:06:17.740 --> 00:06:21.660 Okay, now let's simulate how an engineer would fix this issue. 00:06:22.140 --> 00:06:24.060 Okay, let's go back into the Dockerfile. 00:06:24.640 --> 00:06:29.340 First off, in the Trivy output we saw that this version of libSSL is vulnerable. 00:06:29.520 --> 00:06:30.960 Let's go ahead and comment this out. 00:06:31.740 --> 00:06:33.480 And actually behind the scenes, 00:06:33.490 --> 00:06:37.760 this Docker image has the correct version of OpenSSL that is not vulnerable. 00:06:37.850 --> 00:06:39.140 So as an engineer, 00:06:39.150 --> 00:06:43.040 we clearly just made a mistake and just added in a library that wasn't needed. 00:06:43.130 --> 00:06:44.960 I'm going to go ahead and save the changes. 00:06:47.240 --> 00:06:50.290 Then after this we simply commit our changes and push it 00:06:50.290 --> 00:06:53.480 back up to GitHub. So we're back in the GitHub UI. Let's 00:06:53.480 --> 00:06:55.250 check out our Dockerfile updates. 00:06:55.740 --> 00:06:57.130 Well, whoa, check this out. 00:06:57.130 --> 00:07:00.160 We also see a green checkmark. That looks promising. 00:07:01.540 --> 00:07:02.190 Okay, great. 00:07:02.190 --> 00:07:04.560 So we see that all status checks have passed. 00:07:05.140 --> 00:07:06.070 Now, at this point, 00:07:06.070 --> 00:07:09.280 the only thing that is blocking us is the additional 00:07:09.290 --> 00:07:11.440 approver that we are requiring. 00:07:11.460 --> 00:07:13.140 And you might be wondering, well, 00:07:13.150 --> 00:07:17.860 why do we need this additional approver if Trivy has given us the thumbs up? 00:07:18.640 --> 00:07:23.430 Well, it's kind of complicated. So Trivy has strengths in certain areas, 00:07:23.440 --> 00:07:27.830 but it cannot detect all vulnerabilities that can be introduced into a 00:07:27.830 --> 00:07:32.100 Docker image, and for that, we'll actually need an additional human 00:07:32.110 --> 00:07:34.660 approver to glance over the pull request. 00:07:35.140 --> 00:07:39.520 Now, as far as what types of vulnerabilities Trivy cannot detect, 00:07:39.530 --> 00:07:42.350 we're going to see an example of this later on in the course. 00:07:42.460 --> 00:07:45.600 Now before we go ahead and merge this pull request. 00:07:45.690 --> 00:07:48.810 It'd be great to look at this from a technical viewpoint and see what 00:07:48.810 --> 00:07:52.060 scripts and configurations are powering this workflow.