Is this image meet any security benchmark

[traveendran]

We are using this image.Please let me know any security benchmark (policy) applied in this image.

[MichaelSimons]

The .NET images do not have any security benchmarks applied. Are you aware if this is a practice applied to any of the Official Images on Docker Hub?

[omajid]

Are you aware if this is a practice applied to any of the Official Images on Docker Hub?

I don't think so. Many images, for better or worse, are in a much much worse position. For example, see docker-library/openjdk#320 which links to this email:

Right now, anyone using the Official Docker images for OpenJDK 8 and 11 (https://hub.docker.com/_/openjdk) is probably thinking that they are running 8u212 or 11.0.3, when what they are actually running is an interim "work in progress build", with several bugs unaddressed, several updates missing, and (critically) CVE vulnerabilities that were fixed in the actual 8u212 and 11.0.3 un-addressed.

[traveendran]

The .NET images do not have any security benchmarks applied. Are you aware if this is a practice applied to any of the Official Images on Docker Hub?
Thanks or the replay, some of them where come with this type of security fixes for there image how can we applied these fixes in image here i am ataching some of the pdf related the benchmark
CIS_Debian_Linux_10_Benchmark_v1.0.0.pdf
CIS_Ubuntu_Linux_18.04_LTS_Benchmark_v2.0.1.pdf

[richlander]

I don't actually know what "security benchmark" means. If it means, "are they scanned", the answer is "yes". We would very much like to post the results, but don't currently. The challenge is that they are scanned by a team in another part of Microsoft that doesn't have an automatic export capability of the results that we can publish. We have asked for this.

Stepping back, we should define what security scanners do and the value they provide you as a user. Also, if I have any of this wrong, I'd like to be corrected.

• What security scanners do: They flag security vulnerabilities relative to published CVEs.
• The value you get: You learn that the images you use contain vulnerabilities in them that your app may be subject to. This either means that your images are out of date, and you should rebuild your higher-level image, or the vulnerability is unpatched in the latest version of the image you rely on, and you need a different plan (rationalize that the vulnerability doesn't apply to you, pick a different distro to base your app on, lock down security with a different mechanism, or play the odds).

Now, let's talk about the practices we use for producing container images.

• We have two patterns for Linux-based images: depend on the distro directly, like Debian or on buildpack-deps (for build/sdk scenarios).
• When the underlying images (again, like Debian) are updated, we updated .NET Core images within 12 hours. We could make the SLA shorter, but doing so has other user-visible problems that are off-topic.

So, as it relates to .NET Core images that rely on Linux distro images, the leading edge of .NET Core digests (that our tags point to) are always up to date.

Then, there is the unique code that we ship (.NET Core). By the definition I provided above on how security scanners work, .NET Core never has security vulnerabilities in it. How so? We release fixes for AND disclose vulnerabilities together. This happens on most patch tuesdays (second tuesday of the month).

That leads to an outcome where .NET Core images are always up-to-date as it relates to both the Linux distro, higher-level packages (like openssl) and .NET Core.

As it relates to Linux, there may still be disclosed vulnerabilities in the latest images. Based on a previous analysis we did, this is frequently the case. There is nothing we can do about that. We recommend that you choose Alpine if you care deeply about this topic. In addition, we recommend running containers with least privilege (not as root). We are in the process of writing guidance that covers some of that scenario.

We also recommend you do one of the following:

• Stay up to date with .NET Core images, via an automated CI/CD solution that monitors our image repos. This will ensure that your apps are always running on images with the latest fixes. We know that many organizations do this. We also recommend you have a way to keep up to date with vulnerabilities in your distro (possibly via a vulnerability scanner). Note: Debian Security Tracker.
• Employ the use of a scanner to find images in your environment that don't meet the vulnerability profile you require. For example, you might accept sev3 vulnerabilities and not sev2.

Also, I highly doubt that this problem is specific to containers. I would imagine that an unpatched vulnerability in Debian, for example, would be unpatched in both the latest container and latest ISO or VHD (for VMs).

We have been asked this general question many times. There is no great answer. I hope that helps. I'm also happy to talk about it further.

¯\(ツ)/¯

[richlander]

Looks like my reply was on the wrong topic. Ooops!

Security benchmarks are new for me. We haven't targeted those before. They seems more like something that a user of our images would reason about. Our only goal is to not make images worse than what we pull from Debian, for example. Is that a fair model?

[MichaelSimons]

As Rich eluded to we feel this is something that would make more sense for users of the .NET Core to do against the images they build on top of the .NET Core images. Closing.