Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
1–10 of 79 posts
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#2Not surprised at all.
And here we have the prime example, why the Docker-model of building and distributing containers is horrible when it comes to security and maintenance.
Bundling dependencies for production environments has always been and always will be a terrible idea.
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#3"Containers have revolutionized software development by providing a very efficient path to take software written by developers and run it in production in a matter of minutes or hours, rather than days or months using traditional approaches."
FUD. The technology of deployment does not change 'minutes or hours' into 'days or months' - it's management red tape that does that. In fact, in my use case, Docker takes a similar time to build as a normal package (.deb) using an up-to-date base image, but is actually slower to deploy, since now my servers have to download a stupidly large container with build-essential (npm doesn't really survive without it), python (because npm maintainers use python frequently), and graphicsmagick (for the in-house app), instead of 'just the app' that's in a normal package.
If your environment is simple enough that you don't have to be concerned with testing in 'staging' against staging databases or similar, then you're definitely not saving 'days', because your env just isn't that complicated.
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#4A bit overstated. They definition of security vulnerable == got package which is vulnerable.
However, merely having some packages with vulnerabilities may not be enough. E.g. you have security in package manager (apt), but you never use it after building the image. Or even shellshock is no flyer, if you don't use CGI scripts and don't have ssh access.
In Virtual Machines this problem also exists. I guess it is more about how often you update your software than Docker itself.
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#5Based on their definition of vulnerable the Ubuntu 12.04LTS installation image is also vulnerable. I think this is only news to anyone that hasn't setup a fresh install of Windows. I remember some presentation from the Honeynet project circa 1999 about how a new win98 installation, without updating service packs, took less than N (N<24) hours until compromise. Still I guess it is worth reminding people to not trust official containers without first applying security updates, and maybe never trusting unofficial containers, depending on your project
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#6"Containers have revolutionized software development by providing a very efficient path to take software written by developers and run it in production in a matter of minutes or hours, rather than days or months using traditional approaches." FUD. The technology of deployment does not change 'minutes or hours' into 'days or months' - it's management red tape that does that. In fact, in my use case, Docker takes a sim…
"The technology of deployment does not change 'minutes or hours' into 'days or months'"
I wouldn't say that's true. We're transitioning into multiple languages, and want to have an environment that will allow future languages to be added as required. Building a generic infrastructure to run containers lets us run everything on the same base platform. Otherwise, we'd need to tailor the images and configuration for the individual language type. When a new language is introduced, it can take 'days or months' to get everything working well.
That's not to say Docker doesn't require the same attention to security as other options. This seems to me akin to running a downloaded base VM image without first doing updates.
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#7Not surprised at all. And here we have the prime example, why the Docker-model of building and distributing containers is horrible when it comes to security and maintenance. Bundling dependencies for production environments has always been and always will be a terrible idea.
This sounds like an oversimplification, though:
> Bundling dependencies for production environments has always been and always will be a terrible idea.
We're considering Docker currently -- not for the distribution model at all, since we'd only ever use our own internally built & maintained images -- but as a clean way to break apart dependencies, and make it possible to run a diverse multiple-server-type environment (production) in miniature (development, demo, UAT).
I quite like the idea of something that may occupy multiple VMs or dedicated servers in production be able to run as a lightweight app in a dev environment, with exactly the same dependencies in place -- that's quite useful.
If this kind of use case is also a terrible idea, I'm interested to hear more -- we're just now tinkering with the idea, and haven't yet moved from theory to practice.
My own concerns revolve around how easy it will be to keep updated on RHEL patches, for example -- apparently we should be able to keep both host and app dependencies updated without much trouble, but it adds more complexity to the maintenance cycle (it seems).
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#8Not surprised at all. And here we have the prime example, why the Docker-model of building and distributing containers is horrible when it comes to security and maintenance. Bundling dependencies for production environments has always been and always will be a terrible idea.
I see it as the opposite. If the maintainer of the container put some effort in, everyone could have a secure version of their software with minimal effort.
The trick is to get people to care about their security. In theory, this is what open source is about. Why not assemble a taskforce to go and secure these containers?
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#9Not surprised at all. And here we have the prime example, why the Docker-model of building and distributing containers is horrible when it comes to security and maintenance. Bundling dependencies for production environments has always been and always will be a terrible idea.
This sounds like an oversimplification, though: > Bundling dependencies for production environments has always been and always will be a terrible idea. We're considering Docker currently -- not for the distribution model at all, since we'd only ever use our own internally built & maintained images -- but as a clean way to break apart dependencies, and make it possible to run a diverse multiple-server-type environment…
> My own concerns revolve around how easy it will be to keep updated on RHEL patches, for example -- apparently we should be able to keep both host and app dependencies updated without much trouble, but it adds more complexity to the maintenance cycle (it seems).
That's about the "problem" with Docker – it's deceptively easy to roll out everything as its own containerized app. Updating? Not so much.
It turns Docker from a magical silver bullet into a slightly fancier way to handle reproducible deployments. Using it this way is fine, but not what Docker is marketed as by many.
Re: Over 30% of Official Images in Docker Hub Contain Security Vulnerabilities
#10"Containers have revolutionized software development by providing a very efficient path to take software written by developers and run it in production in a matter of minutes or hours, rather than days or months using traditional approaches." FUD. The technology of deployment does not change 'minutes or hours' into 'days or months' - it's management red tape that does that. In fact, in my use case, Docker takes a sim…
"The technology of deployment does not change 'minutes or hours' into 'days or months'" I wouldn't say that's true. We're transitioning into multiple languages, and want to have an environment that will allow future languages to be added as required. Building a generic infrastructure to run containers lets us run everything on the same base platform. Otherwise, we'd need to tailor the images and configuration for the…
Otherwise, we'd need to tailor the images and configuration for the individual language type. When a new language is introduced, it can take 'days or months' to get everything working well.
Yes, and now you have to tailor the distribution in the container to the new language. Of course, the impact is smaller than changing one system that contains everything.
However, this problem was long-solved before containers (as in OS-level virtualization) as well in virtualization (Xen, KVM, etc.). (Of course, FreeBSD had containers for ages, but they were largely ignored.)