Security Linting of Dockerfiles
hadolint
hadolint
Hadolint comes with a robust and easy to use CLI. You can install it on a variety of platforms, including macOS using brew install hadolint
.
Confirm the installation was successful with the following command:
We’ll use the following Dockerfile as an example, which can be used to run a Python Django web server. On the surface, it looks fine but we’ll see it has a lot of problems.
Let’s run it through Hadolint:
Every violation takes on the following structure:
A rule code is prefixed with either DL or SC. The DL prefix means the rule comes from Hadolint directly. The SC prefix means the rule comes from SpellCheck which is a static analysis tool for shell scripts that comes with Hadolint out of the box. You can find the combined list of rules here.
Every rule has a dedicated documentation page that lists code examples, rationale and other important details. See the dedicated page for DL3006 here.
You can ignore one or more rules using the --ignore RULECODE
option:
You can also ignore rules within the Dockerfile inline. I prefer this approach because you can exclude rule codes on a per-line basis and it’s more clear where the violation is actually happening.
Hadolint has an active open-source community. New rule codes are added on a regular basis so be sure to check you’re running the latest version of Hadolint every so often.
Severity level
The severity level indicates how critical a violation is. There are six levels: error, warning, info, style, ignore, and none.
The CLI includes a –failure-threshold (abbreviated as -t) to exclude certain severity levels from causing a failure. For example, if you only want Hadolint to fail on error violations.
Note, violations from other severity levels will still be reported but they won’t cause a failure.
If you don’t agree with a rule code’s severity level, you can easily change it using the –<SEVERITY_LEVEL> RULECODE option. For example, the following command upgrades DL3006 to error and downgrades DL3045 to info (both codes are warning by default):
Fix the Dockerfile
Working through each error one-by-one is a fantastic exercise for learning about Dockerfile best practices. As mentioned above, every rule has a very clear and detailed documentation page. Give it a shot and revisit this post when you’re done.
At this point, Hadolint should report no errors. Your file should look similar to this:
- Integrations
Hadolint includes many convenient integrations for automatically running the linter throughout the development process. My favorites are:
VS Code: run Hadolint directly in your editor pre-commit: run Hadolint on every git commit GitHub Actions: run Hadolint in GitHub CI/CD
Last updated 8 days ago.