WEBVTT

00:00:01.340 --> 00:00:06.210
We opened the pipeline definition file in our favorite editor, Emacs. And the

00:00:06.220 --> 00:00:10.530
only thing we need to do in order to make the pipeline fail if Dockle finds

00:00:10.540 --> 00:00:14.850
issues is adding the parameter ‑‑exit‑code 1.

00:00:15.740 --> 00:00:19.150
This ensures that the pipeline will fail, that it will return

00:00:19.150 --> 00:00:22.250
a non‑zero exit code when it finds issues.

00:00:23.640 --> 00:00:26.160
Let's now add the file to our Git repository.

00:00:27.340 --> 00:00:33.260
Let's commit again with a nice commit message, and push it to our GitLab server.

00:00:35.140 --> 00:00:38.580
Let's switch over to the web interface, and you can see GitLab already

00:00:38.580 --> 00:00:41.460
pushed up the changes in the pipeline configuration file.

00:00:42.340 --> 00:00:45.640
And if we click on the running pipeline, here we can

00:00:45.640 --> 00:00:47.450
see that the linting stage failed.

00:00:47.940 --> 00:00:50.060
If you now drill down to the lint stage,

00:00:50.540 --> 00:00:55.320
you can see that the test itself ran successfully, but the test results

00:00:55.410 --> 00:01:00.160
ensured that the exit code was 1 so that the pipeline stage failed. And

00:01:00.160 --> 00:01:04.840
this is ideally how you set up automatic security pipelines. You'd like the

00:01:04.840 --> 00:01:10.620
pipeline stage to fail when the test result is negative or positive,

00:01:10.630 --> 00:01:11.960
depending on your point of view.

00:01:13.140 --> 00:01:14.450
What about the results?

00:01:14.460 --> 00:01:18.240
How can they help me build more secure images? On the

00:01:18.240 --> 00:01:22.180
goodwithtech Dockle GitHub pages, you can find more information

00:01:22.180 --> 00:01:24.960
about how Dockle implements those checkpoints.

00:01:25.740 --> 00:01:29.460
If you check the page CHECKPOINT.md and scroll down,

00:01:30.440 --> 00:01:33.420
you can find more information about why Dockle flagged

00:01:33.420 --> 00:01:38.030
something, and more importantly, how to mitigate that specific

00:01:38.030 --> 00:01:40.060
point or that specific vulnerability.

00:01:41.540 --> 00:01:44.370
These checkpoints are based on the Center for Internet

00:01:44.370 --> 00:01:48.860
Security's Docker benchmarks, and this is an objective security

00:01:48.860 --> 00:01:53.890
guideline for Docker. Issue number 10 was the issue that Dockle

00:01:53.890 --> 00:01:55.650
flagged for our local image.

00:01:56.140 --> 00:01:58.560
Do not store secrets in Dockerfiles.

00:01:59.440 --> 00:02:04.930
Let's go back to our test results. Dockle found a file with a suspicious file

00:02:04.930 --> 00:02:08.660
name, and that's why the specific checkpoint was triggered.

00:02:09.440 --> 00:02:12.050
But I know for a fact that this is a false positive.

00:02:12.740 --> 00:02:16.170
How can we configure Dockle in the continuous integration

00:02:16.170 --> 00:02:18.950
pipeline to ignore false positives?

00:02:19.740 --> 00:02:22.050
That's what we're going to do in the next clip.