4 ms·
Note that an image containing vulnerable binaries is not the same thing as an exploitable cointainer. A container derived from a full OS like Ubuntu will have m
by Scaevolus 10y ago
Note that an image containing vulnerable binaries is not the same thing as an exploitable cointainer. A container derived from a full OS like Ubuntu will have many binaries to provide a standard environment, but most of them will never be touched by the running program. That year-old image might have a vulnerable Perl version, but nothing in the container even runs Perl, so it's a non-issue.
This is why many people can get away with a minimal base image like Alphine-- a tiny busybox shell provides enough features to run the application while still supporting some manual debugging with docker exec. It also avoids false positives like these, letting you more quickly find precisely what you need to upgrade when a new OpenSSL vulnerability is announced.
(Disclaimer: I work on Google Container Engine / Kubernetes).
- jsulinski 10y agoThis is a very well-written explanation. The only exception is when people have access to the underlying container, willing or not. Then these vulnerable binaries can lead to a vulnerable container. This is also why the subjectivity in CVE rating is such a significant problem.
- jvehent 10y agoIn addition, it's really not that hard to add the equivalent of "apt update && apt -y upgrade && apt autoclean" to every dockerfile.