
CoreOS Introduces Clair: Open Source Vulnerability Analysis for Your Containers - xfiler
https://coreos.com/blog/vulnerability-analysis-for-containers/
======
rwmj
Does this use the OVAL data published by various companies? (eg. Red Hat's
here:
[https://www.redhat.com/security/data/oval/](https://www.redhat.com/security/data/oval/)
)

~~~
robszumski
Yes it does:

> For now, Clair uses three databases, one for each supported operating
> system: Ubuntu CVE Tracker, Debian Security Bug Tracker, Red Hat Security
> Data

[https://github.com/coreos/clair/blob/master/README.md#detect...](https://github.com/coreos/clair/blob/master/README.md#detectors
--fetchers)

------
neumino
Hey CoreOS, quick question for my own curiosity. You have released/are
releasing tons of cool stuff, I'm just wondering what you plans are to
maintain them? How much to you expect the community to update them? Is your
team growing as fast as you release software?

Thanks for all your great work!

~~~
philips
Great question. Our projects are lead by a set of maintainers that may change
overtime. We love to have folks from the wider community help there too and
have had good success with that. Two examples of long term involvement: Ben
Darnell from CockroachDB helping maintain the raft library or Simone Gotti
helping build out rkt. So, community is one way to sustain and we welcome new
folks to join.

We also continue to grow the team at a good pace for the stuff we are building
too. We have a diverse set of challenging technology we are building to make
everyone successful with distributed systems and containers. If you want to
learn more see [https://coreos.com/careers](https://coreos.com/careers)

------
rdl
It's exciting to me that virtualization and containers raise some new security
issues (cotenancy, memory dump, etc.), but also allow new security
capabilities (reading memory from outside the protected system, separation
kernels, etc.). It would be foolish to ignore them from a security
perspective, on top of all the other management/usability improvements they
bring.

------
kylequest
Cool project! Detecting installed packages and checking against known
vulnerabilities is definitely useful. A similar feature is on the todo list
for DockerSlim[1], so it'll be nice to reuse relevant bits and pieces.

[1]DockerSlim was a recent Docker Hack Day project. The goal is to make Docker
containers lean and mean :) It analyzes existing images and then creates much
smaller images throwing away stuff you don't need.

~~~
jzelinskie
That's really cool. It sounds similar to Squashed Image support on Quay.io[0].
Is it open source?

[0]: [https://blog.quay.io/New-quay-features/](https://blog.quay.io/New-quay-
features/)

~~~
kylequest
Yes, it is open sourced. I think it's different though. It looks like the
"squashed image" feature flattens an image. DockerSlim tries to extract only
the artifacts the application needs, so it can turn a 431 MB image into a 14
MB image (just an example, not always possible with every application type).
DockerSlim relies on runtime analysis to shrink images that much.

~~~
russell_h
Neat.

Reminds me a little of this: [https://github.com/mafintosh/torrent-
docker](https://github.com/mafintosh/torrent-docker)

------
zathros
Is this a pivot?

On a related note, what do you guys think the future holds for CoreOS now that
Kelsey Hightower has quit and moved to $GOOG?

~~~
HorizonXP
I'm not sure why you think this is a pivot.

CoreOS, the company's name, is a bit of misnomer now. Their original product,
CoreOS, is their namesake and a good foundation for the rest of their
platform.

As a company, they've been putting out a number of products, such as etcd,
fleet, flannel, and more. It seems that Clair is another product under their
umbrella.

So it's not a pivot, it's just another product as a part of their larger
offering.

CoreOS's products are all open-source and openly developed, which is awesome.
They make their money from their managed service offerings, such as Quay.io
container registry (which Clair seems to bolster), CoreOS managed linux, and
Tectonic (Kubernetes as a service).

So each product announcement you see is another facet of CoreOS's larger
offering.

~~~
gtaylor
Quay.io has been outstanding for us so far. Much better overall than Docker
Hub for our organization. Particularly in ergonomics and team/permissions
granularity.

~~~
HorizonXP
100% agree. I just tried Docker Hub for a separate open-source project, and
I'll probably just move it back to Quay.io instead.

~~~
shimo5037
Please don't use Quay for official open source images if you care about
international users, or at least offer a Docker Hub option as well. Quay is
super slow compared to Docker Hub. When I contacted support back in July, they
were very polite and professional, but in the end "everything is being served
from AWS's US East region". Peak time performance is intolerable. It was so
bad that our systemd units were timing out even with a massive 5min
TimeoutStartSec.

To worsen the issue, Quay still doesn't seem to support parallel layer
downloads, and Docker 1.9 even complains that "this image was pulled from a
legacy registry. Important: This registry version will not be supported in
future versions of docker."

I just ran a quick test (way off peak time) and Quay was 2.5x slower than
Docker Hub for an image built from the same Dockerfile.

I'm looking forward to more usable international service at some point, but
right now it just isn't really worth it.

------
mtourne
This is pretty interesting. It would be great if there was a step-by-step
guide to check my own Docker containers. Instead of looking like a piece to
promote Quay.

~~~
spacenerf
You could use contrib/analyze-local-images - see discussion at
[https://github.com/coreos/clair/issues/5](https://github.com/coreos/clair/issues/5)

------
tonyhb
Unfortunately using dpkg and yum to detect installed software means this isn't
a secure audit. Anyone can add known bad binaries after the fact and pretend
to provide a "secure" base image. I'd be skeptical of trusting anything
quay.io says is secure based on this scan.

~~~
mjg59
It's intended to identify known security vulnerabilities, not identify
malicious actors. Someone could add known bad binaries after the fact, but
they could also add unknown bad binaries.

