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:
- 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.
- 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.
- 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.
- Secure container audits. If you’re consuming third-party images, audit and certify their security, then deliver from a private repository.
- 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.
Lori MacVittie is the principal technical evangelist for cloud computing, cloud and application security, and application delivery and is responsible for education and evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations. Prior to joining F5, MacVittie was an award-winning Senior Technology Editor at Network Computing Magazine, where she authored articles on a variety of topics aimed at IT professionals. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University. She also serves on the Board of Regents for the DevOps Institute and CloudNOW, and has been named one of the top influential women in DevOps.
The opinions expressed in this post belong to the individual contributors and do not necessarily reflect the views of Information Security Buzz.