security criteria for cloud image updates

[Andy Grimm]

In today's Cloud WG meeting, we discussed our cloud base image update
policy, and generally agreed on "~1 month + any security/major
bugfix".  Major bugfix can remain pretty fluid, but we'd like to
tighten up the security criteria.  The cloud base image is small, but
it still has dozens of packages, so saying we'll respin for "any"
security update is probably too much.

My thought: our commitment should be that the base image cannot be
exploited at the following points:

1) during the boot process
2) by attacking a service running by default on a publicly-accessible port
3) during the package update process

So our list becomes something like:

kernel
glibc
systemd
python
cloud-init (and its python deps)
openssl
openssh
yum (dnf?)

and so on.  Specifically, I think we need not worry about minor
security bugfixes to userspace tools, unless they can be exploited in
the normal course of system initialization.

Thoughts?  Additions?

Thanks.

--Andy