WEBVTT 00:00:01.040 --> 00:00:03.700 The Trivy scan that we just witnessed is powered by 00:00:03.700 --> 00:00:05.960 a GitHub Actions workflow file. 00:00:06.440 --> 00:00:11.530 Now GitHub Actions expects workflow files to be within the workflows directory. 00:00:11.640 --> 00:00:13.780 The workflow name can be anything you choose. 00:00:14.080 --> 00:00:15.250 Let's go through the workflow. 00:00:15.250 --> 00:00:19.720 As a brief recap, before modifying the code within a GitHub repository, 00:00:19.730 --> 00:00:21.250 a peer review must occur. 00:00:21.740 --> 00:00:24.350 This peer review occurs within a pull request. 00:00:24.740 --> 00:00:26.170 When a pull request occurs, 00:00:26.170 --> 00:00:30.030 this workflow will use Trivy to scan for vulnerabilities. 00:00:30.030 --> 00:00:34.840 If you want more context on GitHub Actions and this workflow file, 00:00:34.850 --> 00:00:37.320 I highly recommend checking out the link on the screen. 00:00:37.600 --> 00:00:39.170 This is also in the course notes. 00:00:39.410 --> 00:00:40.960 And we also see some assumptions. 00:00:40.970 --> 00:00:42.430 We've already gone over these. 00:00:42.430 --> 00:00:46.690 First, we see that we run the workflow when new changes are proposed. 00:00:46.810 --> 00:00:51.020 We also see that the workflow runs within an isolated execution environment, 00:00:51.020 --> 00:00:53.350 in other words Ubuntu 2004. 00:00:53.350 --> 00:00:59.200 The first step is we allow access to the Trivy tutorial Git repo. 00:00:59.200 --> 00:01:03.940 Then, we install Trivy using the installation script that we've already seen. 00:01:03.940 --> 00:01:07.160 Then, we go ahead and execute the docker‑scan script. 00:01:07.160 --> 00:01:11.770 We'll check out that script next. 00:01:11.770 --> 00:01:16.160 So this script checks if a Docker image has vulnerabilities via Trivy. 00:01:16.160 --> 00:01:18.750 This script expects the following convention. 00:01:18.750 --> 00:01:19.640 In particular, 00:01:19.640 --> 00:01:25.100 the repo name corresponds to the repo name within the Docker Registry. 00:01:25.100 --> 00:01:25.600 And also, 00:01:25.600 --> 00:01:29.440 this convention is shared with a docker‑registry‑orchestrator script 00:01:29.440 --> 00:01:32.330 that we're going to see later on in this course. 00:01:32.330 --> 00:01:36.270 This script uploads Docker images to the Docker image registry, 00:01:36.270 --> 00:01:39.670 and that's why we need to have this repo‑named convention. 00:01:39.670 --> 00:01:42.630 The second assumption, script should be triggered on pull requests, 00:01:42.630 --> 00:01:43.830 and the third assumption, 00:01:43.830 --> 00:01:47.320 Docker image changes in Git must be approved by a trusted entity, 00:01:47.320 --> 00:01:50.000 should make sense based on what we've already covered. 00:01:50.000 --> 00:01:52.250 Let's scroll down to the main logic. 00:01:52.250 --> 00:01:54.980 Here, we iterate through the Docker configurations. 00:01:54.980 --> 00:01:58.500 The path convention was outlined in assumption number 1. 00:01:58.500 --> 00:02:02.560 We make sure that we only iterate through directories. 00:02:02.560 --> 00:02:05.940 Then, we get the absolute path for the Docker configurations. 00:02:05.940 --> 00:02:08.900 This will power the Docker build context. 00:02:08.900 --> 00:02:11.300 Next, we see the local Docker image build. 00:02:11.300 --> 00:02:13.460 Now here's something that's really important. 00:02:13.460 --> 00:02:17.390 We ensure that Trivy does not scan a cached image. 00:02:17.390 --> 00:02:20.290 This was a warning that we saw previously in this course. 00:02:20.290 --> 00:02:25.350 And just to be extra paranoid, we make sure that Trivy purges its internal cache. 00:02:25.350 --> 00:02:29.680 We only want to scan the current Docker image, not an older one. 00:02:29.690 --> 00:02:32.220 Next, we see the Trivy scan being executed. 00:02:32.220 --> 00:02:34.950 We are leveraging the severities that we already 00:02:35.440 --> 00:02:38.690 defined and also the ignore‑unfixed. 00:02:38.690 --> 00:02:42.360 Into the future, we will make our blocking behavior more granular. 00:02:42.360 --> 00:02:47.310 And also, if a vulnerability is found, Trivy will emit an exit code of 2. 00:02:47.380 --> 00:02:51.240 You'll see how this is useful really soon. 00:02:51.240 --> 00:02:54.740 In the first if block, if Trivy has an exit code of 0, 00:02:54.740 --> 00:02:57.270 that means that the scan was successful and that Trivy 00:02:57.270 --> 00:03:00.120 did not have any unexpected errors. 00:03:00.120 --> 00:03:03.510 And then we simply continue to the next set of Docker 00:03:03.510 --> 00:03:05.650 configurations that need to be scanned. 00:03:05.660 --> 00:03:05.940 Remember, 00:03:05.940 --> 00:03:10.110 all of this code is within a for loop that iterates through all of the 00:03:10.110 --> 00:03:12.570 Docker configurations that are defined within the repo. 00:03:12.570 --> 00:03:15.120 In the second if block, if there is an exit code of 2, 00:03:15.120 --> 00:03:18.430 we know that this Docker image contains a vulnerability. 00:03:18.430 --> 00:03:21.530 Then, we simply tell the engineer what needs to be fixed. 00:03:21.530 --> 00:03:23.950 And then when we exit with 1, 00:03:23.950 --> 00:03:28.370 that tells GitHub Actions to fail the status check and thus 00:03:28.370 --> 00:03:31.050 block the pull request from being merged. 00:03:31.050 --> 00:03:33.790 Now what happens if there is an unexpected error? 00:03:33.790 --> 00:03:36.700 This else block will then be activated. 00:03:36.710 --> 00:03:37.510 Once again, 00:03:37.510 --> 00:03:41.260 we exit with a status code of 1 so we don't allow any 00:03:41.260 --> 00:03:43.570 vulnerabilities to be potentially introduced. 00:03:43.570 --> 00:03:45.320 So now we're almost at the end of this demo, 00:03:45.320 --> 00:03:49.130 so let's do a little recap on what we've just seen. 00:03:49.140 --> 00:03:52.380 We reviewed a proactive Trivy integration. 00:03:52.380 --> 00:03:57.260 We used GitHub Actions to integrate Trivy into the code review process. 00:03:57.260 --> 00:03:59.740 And then we saw the consumer view. 00:03:59.750 --> 00:04:03.870 We saw Trivy within the pull request within the GitHub UI, 00:04:03.870 --> 00:04:06.590 and we also checked out Trivy's enforcement settings, 00:04:06.590 --> 00:04:09.550 such as the branch protection rules. 00:04:09.550 --> 00:04:13.270 Then we also checked out the technical viewpoint. 00:04:13.270 --> 00:04:16.690 This included the GitHub Actions workflow file and 00:04:16.690 --> 00:04:18.550 also the Docker build and Trivy scan.