Skip to content
Getting a handle on container security
Branch: master
Clone or download
drwetter Merge pull request #15 from hartwork/improve-dockerfile
Dockerfile: Avoid outdated Docker cache for "apt-get install"
Latest commit 484177d Nov 9, 2019
Type Name Latest commit message Commit time
Failed to load latest commit information.
assets Partly fix License mentioning issue Nov 9, 2019
000 - chore: make repo directory structure flat Jun 29, 2019
001 -
D00 -
D01 - Secure User
D02 - Patch Management
D03 - Network Segmentation and Adding a references (Tesla incident) Sep 14, 2019
D04 - Secure Defaults and Wording, footnotes, (bad) design from orchestration tool interfaces Sep 20, 2019
D05 - Maintain Security Typos, some paragraphs phrased better Sep 14, 2019
D06 - Protect
D07 - Resource chore: make repo directory structure flat Jun 29, 2019
D08 - Container Image Integrity and
D09 - Follow Immutable
D10 -
Dockerfile Dockerfile: Avoid outdated Docker cache for "apt-get install" Nov 8, 2019
E11 - What's Next?.md chore: make repo directory structure flat Jun 29, 2019 chore: make repo directory structure flat Jun 29, 2019
cover.jpg fix: cover typo Nov 8, 2019
cover_small.jpg fix: cover typo Nov 8, 2019

Docker Security

This is the OWASP Docker Top 10. It's a work in progress.

About this document

This document describes the most important 10 security bullet points for building a secure containerized environment. You can use it as a specification sheet if you start from scratch, alternatively handing it to a contractor who will do this for you.

It can also be used to audit or secure an existing installation but especially here you should start thinking about security very early. Best is in the design phase. Later on it becomes either difficult to change some decisions you made or they becomes costly, in terms of money or time.


Albeit the document's name resembles the OWASP Top 10 it's quite different. First, it is not about risks which are based on data collected as the OWASP Top 10. Secondly the 10 bullet points here resemble (proactive) controls.

For whom is this?

This guide is for developers, auditors, architects, system and networking engineers. As indicated above you can also use this guide for external contractors to add formal technical requirements to your contract. The information security officer should have some interest too to meet baseline security requirements and beyond.

These 10 bullet points are mostly (see below this paragraph) about system and network security and system and network architecture. As a developer you don't have to be an expert in those -- that's what this guide is for. But as indicated above best is to start thinking about and addressing those points early. Please do not just start building it.

One of the bullet point should not be misunderstood: Patch management is not a techincal point. It's a management process. Last but not least for technical or information security management who has not been much worried about containerization this document also provides insights about the risks involve.

Structure of this document

Security in Docker environments seemed often to be misunderstood. It was/is a highly disputed matter what the threats are supposed to be. So before diving into the Docker Top 10 bullet points, the threads need to be modeled which is happening upfront in this document. It not only helps to understand any security impacts but also gives you the ability to prioritize your tasks.

How to Build PDF version

You can build yourself a PDF version as long as you have Docker (and docker compose) installed.

docker-compose run --rm build


Why not "Container Security"

Albeit the name of this project carries the word "Docker", it also can be used with little abstraction for other containment solutions. Docker is as of now the most popular one, so the in-depth details are focusing for now on Docker. This could change later.

A single container?

If you run more than 3 containers on a server you probably have an orchestration solution to manage them. Specific security pitfalls of such a tool are currently beyond the scope of this document. That does not mean that this guide is just concerning one or a few containers managed manually -- on the contrary. It means only that we're looking at the containers including their networking and their host systems in such an orchestrated environment and not on special pitfalls of e.g. Kubernetes, Swarm, Mesos or OpenShift.

Why ten?

To be honest for us humans the number 10 sounds catchy and while putting it all together those 10 were considered to be the most important ones.

You can’t perform that action at this time.