Certainly good work automating a category of base tests like this, though I notice some odd assumptions being made like having more than 5 ports open at all being an inherent warning, tests that assume presence of systemd and auditd (the audit trail can be useful, though from what I know many distros configure it poorly out of the box, if at all), aufs being marked as a warning (over what - Device-mapper? UnionFS? How is it a security consideration?) and the LXC execution driver being a warning.

EDIT: Apparently the CIS paper justifies marking aufs due to its age and gradual dropping of mainstream support. >5 ports isn't rationalized. LXC driver again legacy reasons in favor of libcontainer (though why do I seem to recall libcontainer had pluggable backends, LXC included... hm...)

Why is this distributed as a docker container?

Also, their README asks sers to pull their container from index (with no guarantee that it corresponds to the repo and, last I've checked, no real integrity guarantees stronger than "it's coming over ssl from docker.org") and then run it while giving it write access to /etc and command access to the docker daemon. This seems tome to be a very insecure way of starting a process that's not supposed to alter anything.

Looking at purely just output... this is useful for visual aid, but hard to use it for fully automated health check because I would have to parse the output. This is what made sqlmap hard in my previous work which I was trying to automate these awesome tools together. If I have time I might hack some JSON together...