We opened the pipeline definition file in our favorite editor, Emacs. And the
only thing we need to do in order to make the pipeline fail if Dockle finds
issues is adding the parameter ‑‑exit‑code 1.
This ensures that the pipeline will fail, that it will return
a non‑zero exit code when it finds issues.
Let's now add the file to our Git repository.
Let's commit again with a nice commit message, and push it to our GitLab server.
Let's switch over to the web interface, and you can see GitLab already
pushed up the changes in the pipeline configuration file.
And if we click on the running pipeline, here we can
see that the linting stage failed.
If you now drill down to the lint stage,
you can see that the test itself ran successfully, but the test results
ensured that the exit code was 1 so that the pipeline stage failed. And
this is ideally how you set up automatic security pipelines. You'd like the
pipeline stage to fail when the test result is negative or positive,
depending on your point of view.
What about the results?
How can they help me build more secure images? On the
goodwithtech Dockle GitHub pages, you can find more information
about how Dockle implements those checkpoints.
If you check the page CHECKPOINT.md and scroll down,
you can find more information about why Dockle flagged
something, and more importantly, how to mitigate that specific
point or that specific vulnerability.
These checkpoints are based on the Center for Internet
Security's Docker benchmarks, and this is an objective security
guideline for Docker. Issue number 10 was the issue that Dockle
flagged for our local image.
Do not store secrets in Dockerfiles.
Let's go back to our test results. Dockle found a file with a suspicious file
name, and that's why the specific checkpoint was triggered.
But I know for a fact that this is a false positive.
How can we configure Dockle in the continuous integration
pipeline to ignore false positives?
That's what we're going to do in the next clip.