Container images that can be downloaded to the Docker Hub are able to meet almost by any need, from operating systems to complete application ecosystems, databases, middleware or yet the application engines supporting node.js, Python, and Go. You can find everything there, in fact, companies that today use containers (and this is the majority) probably deploy Docker images in a Kubernetes environment. And that means they are probably deploying vulnerable images. Because according to the report mentioned earlier, “each of the ten most popular default images of Docker contains at least 30 vulnerable system libraries”.
Except that, Kubernetes won the war of the container orchestrators container orchestrators it’s rather a Docker who won the war of container images. In any case, this is clear from the State of Open Source Security Report 2019, according to which more than one billion Docker images are downloaded every two weeks, which is huge.
How is it possible? Still according to this study, it is common “that these vulnerable system libraries are available in many docker images, because they rely on a mother image that usually uses a Linux distribution as a base.” Many vulnerable images are permanently downloaded by companies. And still according to the same report, the number of vulnerabilities discovered in the three main Linux distributions is steadily increasing, which automatically increases the number of vulnerabilities in the downloaded containers, because the system libraries used obviously come from a Linux distribution! Not surprisingly, the publisher Tripwire, in its 2019 State of Container Security report, found that 60% of respondents
Container security incident in the last 12 months. This is a truly amazing rate! More surprisingly, in almost one in five cases (17%), the organization was aware of the vulnerabilities, but still deployed them. And this even though for 44% of Docker images that were known to be vulnerable, a newer and more secure version was available.
In other words, simply updating the image would have mitigated the risk. And as a bonus, 22% of these images could have been corrected without updating, but simply by rebuilding the image. It’s unbelievable, it’s depressing, and yet, it’s the reality.
When we say that we need to “move security to the left“: we are talking just as much to deploy the appropriate security services at the earliest (defense against malicious bots, Web application firewall, access control, etc.) than to follow good security practices throughout the project life cycle, up to its putting into production. And the good practices in question include, among others, an analysis of unpatched vulnerabilities and their correction! We can obviously do better than that. Yes, speed is important, but speed without security is dangerous, not only for the company, but for the customers who use the applications.
Here is some best security strategy for deploying containers with confidence: Evaluate usage, many organizations are not yet aware of the ubiquity of third-party container images in their information systems. Having visibility on these uses is an important step because it is obviously impossible to deal with vulnerabilities in software that we do not even know exists. We need to find common ground between development and operations and standardize the use as few different images or components as possible.
This will better distribute the security burden across the organization and ultimately result in better security for all audit the third-party code. If third-party components or scripts are integrated into the developments (and this is almost always the case), it is necessary to audit them and once validated to make them available from a private repository. Audit the containers. In the same way, third-party container images should be verified and certified and made available from a private repository.
Make a security issueswatch. It is important to subscribe to security alert delivery channels for third-party components used in developments.
RELATED: Why Is the Security Of Healthcare IoT needs To Be Taken Seriously?