<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>djsumdog</author><text>This entire depending on a base container for setup and then essentially throwing away everything you get from the package manager is part of the issue. There is no real package management for Docker. Hell, there isn&amp;#x27;t even an official way to determine if your image needs an upgrade (I wrote a ruby script that gets the latest tags from a docker repo, extracts the ones with numbers and sorts them in order and compares them to what I have running).&lt;p&gt;Relying on an Alpine&amp;#x2F;Debian&amp;#x2F;Ubuntu base helps to get dependencies installed quickly. Docker could have just created their own base distro and some mechanism to track package updates across images, but they did not.&lt;p&gt;There are guides for making bare containers, they contain nothing .. no ip, grep, bash .. only the bare minimum libraries and requirements to run your service. They are minimal, but incredibly difficult to debug (sysdig still sucks unless you shell out money for enterprise).&lt;p&gt;I feel like containers are alright, but Docker is a partial dumpster fire. cgroup isolation is good, the crazy way we deal with packages in container systems is not so good.&lt;p&gt;Sure if you&amp;#x27;re just checking for base-distro packages for security vulnerabilities, you&amp;#x27;re going to find security issues that don&amp;#x27;t apply (e.g. an exploit in libpng even though your container runs nothing that even links to libpng), but it does excuse the whole issue with the way containers are constructed.&lt;p&gt;I think this space is really open too, for people to find better systems that are also portable: image formats that are easy to build, easy to maintain dependencies for, and easy to run as FreeBSD jails OR Linux cgroup managed containers (Docker for FreeBSD translated images to jails, but it&amp;#x27;s been unmaintained for years).</text><parent_chain><item><author>DCKing</author><text>Although vulnerability scanners can be a useful tool, I find it very troublesome that you can utter the sentence &amp;quot;this package contains XX vulnerabilities, and that package contains YY vulnerabilities&amp;quot; &lt;i&gt;and then stop talking&lt;/i&gt;. You&amp;#x27;ve provided barely any useful information!&lt;p&gt;The quantity of vulnerabilities in an image is not really all that useful information. A large amount of vulnerabilities in a Docker image does not necessarily imply that there&amp;#x27;s anything insecure going on. Many people don&amp;#x27;t realize that a vulnerability is usually defined as &amp;quot;has a CVE security advisory&amp;quot;, and that CVEs get assigned based on a worst-case evaluation of the bug. As a result, having a CVE in your container barely tells you anything about your actual vulnerability position. In fact, most of the time you will find that having a CVE in some random utility doesn&amp;#x27;t matter. Most CVEs in system packages don&amp;#x27;t apply to most of your containers&amp;#x27; threat models.&lt;p&gt;Why not? Because an attacker is very unlikely to be able to use vulnerabilities in these system libraries or utilities. Those utilities are usually not in active use in the first place. Even if they are used, you are not usually in a position to exploit these vulnerabilities as an attacker.&lt;p&gt;Just as an example, a hypothetical outdated version of grep in one of these containers can hypothetically contain many CVEs. But if your Docker service doesn&amp;#x27;t use grep, then you would need to &lt;i&gt;manually run&lt;/i&gt; grep to be vulnerable. And an attacker that is able to run grep in your Docker container has &lt;i&gt;already owned you&lt;/i&gt; - it doesn&amp;#x27;t make a difference that your grep is vulnerable! This hypothetical vulnerable version of grep therefore makes no difference in the security of your container, despite containing many CVEs.&lt;p&gt;It&amp;#x27;s the &lt;i&gt;quality&lt;/i&gt; of these vulnerabilities that matters. Can an attacker actually exploit the vulnerabilities to do bad things? The answer for almost all of these CVEs is &amp;quot;no&amp;quot;. But that&amp;#x27;s not really the product that Snyk sells - Snyk sells a product to show you as many vulnerabilities as possible. Any vulnerability scanner company thinks it can provide most business value (and make the most money) by reporting as many vulnerabilities as it can. For sure it can help you to pinpoint those few vulnerabilities that are exploitable, but that&amp;#x27;s where your own analysis comes in.&lt;p&gt;I&amp;#x27;m not saying there&amp;#x27;s not a lot to improve in terms of container security. There&amp;#x27;s a &lt;i&gt;whole bunch&lt;/i&gt; to improve there. But focusing on quantities like &amp;quot;amount of CVEs in an image&amp;quot; is not the solution - it&amp;#x27;s marketing.</text></item></parent_chain></comment><story><title>The most popular docker images each contain at least 30 vulnerabilities</title><url>https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/</url></story>
<instructions>Your goal is to analyze the following comment and estimate how highly it will be upvoted by the Hacker News community.</instructions><comment><author>kayfox</author><text>I work for a network hardware and security vendor and its utterly disheartening how many customers come to us and don&amp;#x27;t actually care about the impact of any of the vulnerabilities they ask us about, they just care about the CVSS score, its PCI impact and their often bizarre policy about them.    Theres often less concern about actually doing something about security risks and more concern about meeting their compliance goals.  Now, this may be biased by who actually reaches out, but it is scary that big names have underlings who dont know the first thing about some of the security issues their &amp;quot;investigating&amp;quot;.&lt;p&gt;In another discussion the other day, I had heard programming these days compared to slowly transitioning out of the hunter-gatherer phase and into more structured society.   From what I have seen this largely rings true, we are still relying on software that is largely not engineered, but written with loose engineering.    The security industry seems to largely be like this, but more of a wild west (as depicted in Westerns) feel to it.   Some companies and organizations have structured strategies for security, but even in large organizations like Equifax theres still a kinda &amp;quot;go shoot the bad guys and tie up the gate so the cattle dont get out&amp;quot; aspect to it, very ad hoc.&lt;p&gt;I am hoping the industry moves more towards engineering things, standardizing interactions, characterizing software modules, etc so that the security industry can spend less time on wild goose chases when trying to figure out how something is supposed to work and how this latest vulnerability applies to that.</text><parent_chain><item><author>DCKing</author><text>Although vulnerability scanners can be a useful tool, I find it very troublesome that you can utter the sentence &amp;quot;this package contains XX vulnerabilities, and that package contains YY vulnerabilities&amp;quot; &lt;i&gt;and then stop talking&lt;/i&gt;. You&amp;#x27;ve provided barely any useful information!&lt;p&gt;The quantity of vulnerabilities in an image is not really all that useful information. A large amount of vulnerabilities in a Docker image does not necessarily imply that there&amp;#x27;s anything insecure going on. Many people don&amp;#x27;t realize that a vulnerability is usually defined as &amp;quot;has a CVE security advisory&amp;quot;, and that CVEs get assigned based on a worst-case evaluation of the bug. As a result, having a CVE in your container barely tells you anything about your actual vulnerability position. In fact, most of the time you will find that having a CVE in some random utility doesn&amp;#x27;t matter. Most CVEs in system packages don&amp;#x27;t apply to most of your containers&amp;#x27; threat models.&lt;p&gt;Why not? Because an attacker is very unlikely to be able to use vulnerabilities in these system libraries or utilities. Those utilities are usually not in active use in the first place. Even if they are used, you are not usually in a position to exploit these vulnerabilities as an attacker.&lt;p&gt;Just as an example, a hypothetical outdated version of grep in one of these containers can hypothetically contain many CVEs. But if your Docker service doesn&amp;#x27;t use grep, then you would need to &lt;i&gt;manually run&lt;/i&gt; grep to be vulnerable. And an attacker that is able to run grep in your Docker container has &lt;i&gt;already owned you&lt;/i&gt; - it doesn&amp;#x27;t make a difference that your grep is vulnerable! This hypothetical vulnerable version of grep therefore makes no difference in the security of your container, despite containing many CVEs.&lt;p&gt;It&amp;#x27;s the &lt;i&gt;quality&lt;/i&gt; of these vulnerabilities that matters. Can an attacker actually exploit the vulnerabilities to do bad things? The answer for almost all of these CVEs is &amp;quot;no&amp;quot;. But that&amp;#x27;s not really the product that Snyk sells - Snyk sells a product to show you as many vulnerabilities as possible. Any vulnerability scanner company thinks it can provide most business value (and make the most money) by reporting as many vulnerabilities as it can. For sure it can help you to pinpoint those few vulnerabilities that are exploitable, but that&amp;#x27;s where your own analysis comes in.&lt;p&gt;I&amp;#x27;m not saying there&amp;#x27;s not a lot to improve in terms of container security. There&amp;#x27;s a &lt;i&gt;whole bunch&lt;/i&gt; to improve there. But focusing on quantities like &amp;quot;amount of CVEs in an image&amp;quot; is not the solution - it&amp;#x27;s marketing.</text></item></parent_chain></comment><story><title>The most popular docker images each contain at least 30 vulnerabilities</title><url>https://snyk.io/blog/top-ten-most-popular-docker-images-each-contain-at-least-30-vulnerabilities/</url></story>