Practicing Safe Containerisation

Everyone knows that Kubernetes has won the container wars. Except what Kubernetes has won is the container runtime wars. You see, the container image war was won by Docker. That can be seen in the statistic that more than 1 billion Docker containers are downloaded every two weeks according to the State of Open Source Security Report 2019. Docker Hub has become for the enterprise what Apple’s AppStore and Google Play are to consumers.

Container images run the gamut from base operating systems to app stacks, from databases to middleware to app engines supporting node.js, Python, and Go. They even include ecosystem integrations for application services.

If you’re in the majority of organisations deploying containers, you’re probably deploying Docker images within a Kubernetes environment.

And if you’re doing that, then you’re probably also deploying vulnerable container images. The aforementioned research from Snyk discovered that “each of the top ten most popular default Docker images contains at least 30 vulnerable system libraries.” It’s common, the report goes on to note, “for system libraries to be available in many docker images, as these rely on a parent image that is commonly using a Linux distribution as a base.”

So, we’ve got a whole lot of vulnerable images being downloaded by organisations all the time. According to Snyk, the number of vulnerabilities is steadily increasing across all three major Linux distributions.

It’s no surprise, then, that  Tripwire’s 2019 State of Container Security found a staggering 60% of respondents that had experienced a container security incident in the past twelve months. For nearly one in five (17%), that’s likely because the organisation was aware of the vulnerabilities – but deployed them anyway. That’s despite Snyk’s finding that for 44% of the Docker images found to contain known vulnerabilities there were newer and more secure base images available. In other words, simply pulling an up to date image would have mitigated the risk. Another 22% of those images with vulnerabilities could have been addressed by simply rebuilding the image.

Really. I can’t make this stuff up.

A lot of the focus on “shifting security left” is as much about deploying the appropriate security application services (BOT defense, web application firewalls, identity and access control) as it is incorporating secure practices into the development and delivery life cycle.  Those practices include scanning code and containers for known vulnerabilities and then addressing them.

​That emphasis was for the 17% of you that knew about vulnerabilities in a container image but deployed without remediating.

We can do better than this. Yes, speed is important but speed without security is dangerous – not just to the organisation but to customers who ultimately use the apps you’re hurrying out the door.

If you aren’t already practicing safe containerisation, consider putting into practice these steps:

1. Assess usage. Many organisations aren’t aware how pervasive their consumption of open and third-party source/images really is. Getting a handle on that is an important first step. You can’t address vulnerabilities in software you don’t even know you’re using.
2. Standardise. Try to find common ground across applications and operations and standardise on the fewest container images/components possible. This will distribute the security burden across the organisation and ultimately result in better security for everyone.
3. Secure code reviews. If you’re including third-party components or scripts (and you almost certainly are) then review it and deliver/build from a private repository.
4. Secure container audits. If you’re consuming third-party images, audit and certify their security, then deliver from a private repository.
5. Subscribe to security channels. If you’re relying on an image or source code, find and subscribe to the channel(s) through which they communicate potential vulnerabilities. Knowing is half the battle, after all.