5 ms·

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

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. I think another aspect that is missed is that just because you use a vulnerable image doesn'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.

jsulinski 10y ago
Absolutely agree. I did see some bad practices in the Docker community that I expect to see elsewhere as well. Specifically: reliance on deprecated images and not updating images during build. Thoughts? I didn't address the implications of software vulnerabilities in respect to other mitigation techniques, however, as it's far outside the scope of the article. I probably should at least add a second addendum though. I'll work on this soon. Thanks!
paulfurtado 10y ago
> by adopting Docker this analysis actually becomes easier to do across an organization and similarly mitigation becomes easier as well I'm curious what makes you say such analysis and mitigation is easier with docker?
- dozzie 10y ago
  Analysis is easier because you already have a running agent that you can remotely query about deployed software. With regular OS you need to provide such an agent. I don't know why it's easier to mitigate risks, though. Maybe just because it's easier to run the analysis.
  - paulfurtado 10y ago
    > Analysis is easier because you already have a running agent that you can remotely query about deployed software. Not sure I buy this. Sure, I can query the docker daemon for what images are running, but that's not enough to tell me which images are vulnerable. I still need to build something to actually scan the images. Also, on any linux host, I don't need a daemon to tell me about deployed software - the package manager can do just that, and the tool used for scanning in this article appears to just query the package manager, which would work just as well on any linux host outside of docker.
    - dozzie 10y ago
      > Sure, I can query the docker daemon for what images are running, but that's not enough to tell me which images are vulnerable. If you can query what images are running, you can tie it with list of deployed software. Then you can compare that list with database of known vulnerabilities; obviously, you'd do the same if you were assessing the host OS without Docker. What's easier is that you already have an API that can be called remotely. > Also, on any linux host, I don't need a daemon to tell me about deployed software - the package manager can do just that But you need to get to each of these hosts somehow and get the data out of package manager, so a report can be prepared. This is the part that makes it easier to assess what you have in the case of Docker. Then there is also software that was not installed with OS-supplied package system, because programmers somehow dislike those and work around them with virtualenv or npm-du-jour. > [...] the tool used for scanning in this article appears to just query the package manager, which would work just as well on any linux host outside of docker. I haven't read the article, but most probably you're right.
      - jsulinski 10y ago
        The conversion of package version numbers to vulnerabilities is perilous and incredibly complicated. That's one of the most significant challenges that we want to solve, which is even more pressing considering how badly the CVE ecosystem is breaking down.
    - jsulinski 10y ago
      That's correct, vuls queries the package manager for installed packages, versions, and changelogs. It then compares the CVEs found in the changelogs to NVD. There are certainly flaws in this approach; it's one of the reasons we intend to support multiple scanners. We started with vuls because clair wasn't released yet and we wanted to support more than containers.

jsulinski 10y ago

Absolutely agree. I did see some bad practices in the Docker community that I expect to see elsewhere as well. Specifically: reliance on deprecated images and not updating images during build. Thoughts? I didn't address the implications of software vulnerabilities in respect to other mitigation techniques, however, as it's far outside the scope of the article. I probably should at least add a second addendum though. I'll work on this soon. Thanks!

paulfurtado 10y ago

> by adopting Docker this analysis actually becomes easier to do across an organization and similarly mitigation becomes easier as well I'm curious what makes you say such analysis and mitigation is easier with docker?

dozzie 10y ago
Analysis is easier because you already have a running agent that you can remotely query about deployed software. With regular OS you need to provide such an agent. I don't know why it's easier to mitigate risks, though. Maybe just because it's easier to run the analysis.
- paulfurtado 10y ago
  > Analysis is easier because you already have a running agent that you can remotely query about deployed software. Not sure I buy this. Sure, I can query the docker daemon for what images are running, but that's not enough to tell me which images are vulnerable. I still need to build something to actually scan the images. Also, on any linux host, I don't need a daemon to tell me about deployed software - the package manager can do just that, and the tool used for scanning in this article appears to just query the package manager, which would work just as well on any linux host outside of docker.
  - dozzie 10y ago
    > Sure, I can query the docker daemon for what images are running, but that's not enough to tell me which images are vulnerable. If you can query what images are running, you can tie it with list of deployed software. Then you can compare that list with database of known vulnerabilities; obviously, you'd do the same if you were assessing the host OS without Docker. What's easier is that you already have an API that can be called remotely. > Also, on any linux host, I don't need a daemon to tell me about deployed software - the package manager can do just that But you need to get to each of these hosts somehow and get the data out of package manager, so a report can be prepared. This is the part that makes it easier to assess what you have in the case of Docker. Then there is also software that was not installed with OS-supplied package system, because programmers somehow dislike those and work around them with virtualenv or npm-du-jour. > [...] the tool used for scanning in this article appears to just query the package manager, which would work just as well on any linux host outside of docker. I haven't read the article, but most probably you're right.
    - jsulinski 10y ago
      The conversion of package version numbers to vulnerabilities is perilous and incredibly complicated. That's one of the most significant challenges that we want to solve, which is even more pressing considering how badly the CVE ecosystem is breaking down.
  - jsulinski 10y ago
    That's correct, vuls queries the package manager for installed packages, versions, and changelogs. It then compares the CVEs found in the changelogs to NVD. There are certainly flaws in this approach; it's one of the reasons we intend to support multiple scanners. We started with vuls because clair wasn't released yet and we wanted to support more than containers.