search

docker / docker-bench-security

The Docker Bench for Security is a script that checks for dozens of common best-practices around deploying Docker containers in production.
Apache License 2.0
9.17k stars 1.02k forks source link

Docker Benchmark support v1.4.x / v1.5.x #512

Closed ktsowes closed 10 months ago

ktsowes commented 1 year ago

CIS released version v1.4.x and v1.5.x of Docker Bechmark.

Are there any plans to support this versions with this repository?

konstruktoid commented 1 year ago

Hi @ktsowes , yes. The code will be updated to match 1.5 as soon as possible.

ktsowes commented 1 year ago

Hi @konstruktoid, that's perfect! Thanks for your fast response.

madantnk commented 1 year ago

Hi @konstruktoid is there any way I can customize and use a particular CIS benchmark version for scans? Suppose I want to use an older CIS benchmark version or the latest CIS version to scan my images.

konstruktoid commented 1 year ago

Hi @madantnk, not by using the script itself, but you can always use a older release https://github.com/docker/docker-bench-security/releases

ktsowes commented 1 year ago

Hi @konstruktoid, I'm a little bit unsure if I should use release tag v1.3.6 or master branch for 1.3.6.

The release tag v1.3.6 is from march 2022 and I see several commits into master branch, quite likely fixes for 1.3.6.

As a proposal, we could extend the release tag a bit, something like:

This way, we could release fixes for specific CIS benchmark versions and it would be clearer what to use.

konstruktoid commented 1 year ago

How would extending the release tag help in this case?

Personally I use the master branch, this because the tags/releases was mostly used for the Docker image and as you said, the master branch contains fixes not yet pushed as a release.

ktsowes commented 1 year ago

The problem I see is, that current release tags reflect the CIS versions and not the versions of this repository.

Lets assume we work in the master branch for 1.5.0 and create a release tag for 1.5.0, we would have this tags:

1.5.0 1.3.6 1.3.5 ...

Now we want to fix a bug for 1.3.6.

Either we delete tag 1.3.6 and recreate it (bad idea) or we add a version information to the "CIS" version.

konstruktoid commented 1 year ago

The releases doesn't correspond to the CIS Benchmark version, and I don't believe there's a reason to fix previous releases since an old benchmark gets end-of-life when there's a new version available.

Eg https://github.com/docker/docker-bench-security/releases/tag/v1.3.5 aligns with CIS Docker Benchmark v1.2.0

ktsowes commented 1 year ago

Ok, wasn't clear to me that the releases don't correspond to the CIS Benchmark version.

In this case I propose a mapping table in the Readme.md to indicate which repository version corresponds to which CIS Benchmark version.

Repository (Tag) CIS
v1.3.6 1.3.6
v1.3.5 1.2.0
v... ...
konstruktoid commented 1 year ago

Why would you ever want to use an old benchmark?

ktsowes commented 1 year ago

Let's assume CIS releases version 1.4.0, 1.5.0, 2.x.x, 3.x.x of docker bench.

The security team decided in the past to implement version 1.4.0 of the CIS controls. Now they want to have a docker-bench-security version which belongs to this exact version. Even if CIS releases newer major version, they have to continue with 1.4.x for a while, it's not always possible to jump to the latest greatest.

Just because we have windows 11 doesn't mean windows 10 no longer exists and fixes for windows 10 still have to be done.

konstruktoid commented 1 year ago

Yes, but an older benchmark is not always applicable to a newer version of Docker.

konstruktoid commented 1 year ago

Or are you saying that because 1.5.0 is tested against Docker Engine 20.10.20 on RHEL 7 and Ubuntu 20.04, you will stick to those releases as well?

konstruktoid commented 1 year ago

Master branch updated to match 1.5.0.

konstruktoid commented 1 year ago

Updated readme to include a version table.

ktsowes commented 1 year ago

Yes, but an older benchmark is not always applicable to a newer version of Docker.

Would it make sense to add the min. docker version in the mapping table? Then all the necessary information are at one place:

Repository (Tag) CIS min. Docker version
v1.3.6 1.3.6
v1.3.5 1.2.0
v... ...
ktsowes commented 1 year ago

Or are you saying that because 1.5.0 is tested against Docker Engine 20.10.20 on RHEL 7 and Ubuntu 20.04, you will stick to those releases as well?

We stick to the major versions of the Docker Engine. We try to be as close as possible to the newest versions, but we have dev, test, prod systems, so it could take a while from when we start on dev until it gets released on prod.