Hacker News Reader

Comment by paulfurtado | Hacker News Reader

> 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.

View on HN

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.

Are there any dynamic scanners that are designed like Vuls or Clair (I'm assuming they're both static)?

I don't fully understand the question.

clair does static analysis

vuls uses a package manager and changelogs

Are there (any) dynamic analysis options available that would give a report similar in scope to clair or vuls?

> 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.

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.

Reply on news.ycombinator.com