TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Docker Image Vulnerability Research

90 点作者 jsulinski大约 8 年前

9 条评论

philips大约 8 年前
This is something near and dear to my heart! The great thing about container images is the software distribution is based on static assets. This enables scanners to give teams actionable data without being on every host. This is a net new capability and I think enables better security in organizations who adopt containers. And unlike &quot;VM sprawl&quot; container systems are generally introspectable via a cluster level API like Kubernetes and scanning doesn&#x27;t require active agents on every node. Two things that have happened recently in this space:<p>- Quay.io[1] offers scanning as a standard feature on all accounts including free open source accounts. This also includes notifications to external services like Slack. This is what it looks like when you ignore an image[1].<p>- The Kubernetes community has started automating scans of all of the containers that are maintained by that community to ensure that they are patched and bumped to the latest versions. A recent example[2].<p>The cool thing is that both of these systems utilize Clair[3] Open Source Project as a way of gathering up data sources from all of the various distribution projects. This all leads to the reason we feel automated updates of distributed systems are so critical and why CoreOS continues to push forward these concepts in CoreOS Tectonic[4].<p>[0] <a href="https:&#x2F;&#x2F;blog.quay.io&#x2F;quay-secscanner-clair1&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.quay.io&#x2F;quay-secscanner-clair1&#x2F;</a><p>[1] <a href="https:&#x2F;&#x2F;quay.io&#x2F;repository&#x2F;philips&#x2F;host-info?tag=latest&amp;tab=tags" rel="nofollow">https:&#x2F;&#x2F;quay.io&#x2F;repository&#x2F;philips&#x2F;host-info?tag=latest&amp;tab=...</a><p>[2] <a href="https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;pull&#x2F;42933" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;kubernetes&#x2F;kubernetes&#x2F;pull&#x2F;42933</a><p>[3] <a href="https:&#x2F;&#x2F;github.com&#x2F;coreos&#x2F;clair" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;coreos&#x2F;clair</a><p>[4] <a href="https:&#x2F;&#x2F;coreos.com&#x2F;tectonic" rel="nofollow">https:&#x2F;&#x2F;coreos.com&#x2F;tectonic</a>
评论 #13871179 未加载
djb_hackernews大约 8 年前
This is great research but I think an important point is missed. It may come across that these images are vulnerable because of some intrinsic property of using Docker however this is not the case. What is also important to point out is by adopting Docker this analysis actually becomes easier to do across an organization and similarly mitigation becomes easier as well.<p>I think another aspect that is missed is that just because you use a vulnerable image doesn&#x27;t necessarily mean you are at risk of being compromised no matter what other security layers you employ. This gets to the practical scenarios of security operations.
评论 #13870824 未加载
评论 #13871038 未加载
Scaevolus大约 8 年前
Note that an image containing <i>vulnerable binaries</i> is not the same thing as an <i>exploitable cointainer</i>. 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&#x27;s a non-issue.<p>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.<p>(Disclaimer: I work on Google Container Engine &#x2F; Kubernetes).
评论 #13872357 未加载
评论 #13886201 未加载
raesene9大约 8 年前
One thing that does get a mention but only right at the bottom of the post is using smaller base images (e.g. Alpine).<p>If you can I&#x27;d recommend this as a good practice to reduce these kinds of problems. The fundamental fact is that if you don&#x27;t have a library installed, you can&#x27;t be affected by a vulnerability in it. So the smaller your image, the fewer possible avenues for shipping vulnerable libs you&#x27;ll have and you&#x27;ll have to spend less time re-building images with updated packages.
评论 #13870725 未加载
评论 #13870759 未加载
kaskavalci大约 8 年前
I&#x27;m looking for a base image choice and this article helped me a lot. It seems Debian base image is a good choice so far. Alpine is quite popular lately but I&#x27;m afraid musl library may cause some headaches in the future. Is Debian to go for production use? What about other alternatives like Centos?
评论 #13870782 未加载
LogicX大约 8 年前
Not for shaming purposes, but to see if there are any patterns, will you release a list of the docker images reviewed, and which have vulnerabilities?<p>Do those without vulnerabilities use a CI&#x2F;CD process which results in the container being auto-updated whenever there are new releases?
评论 #13868855 未加载
jrs95大约 8 年前
If this is the vulnerability rate for &#x27;latest&#x27; Docker images...imagine how many servers <i>in general</i> have vulnerabilities like this.
评论 #13870650 未加载
beevek大约 8 年前
Is there a way for teams with production Docker deployments to easily experiment with this kind of scanning on their own infra to understand their own situation? Maybe worth writing up a quick description of how operators can do something like that.
评论 #13869491 未加载
wjossey大约 8 年前
How do people currently scan their infrastructure to look for vulnerabilities? Do you have a dedicated team that handles this, or is security &quot;everyone&#x27;s job&quot;?
评论 #13870688 未加载