Docker Images not Maintained Properly

[jamiejackson]

I've come across this issue with several other image vendors, too. Let me give an example.

https://www.elastic.co/support/eol mentions that beats 6.7.2 isn't EOL until 2020-09-26.

However, say, filebeat 6.7.2 hasn't been updated since April 2019. https://www.docker.elastic.co/r/beats/filebeat:6.7.2

You'll see on the previous link that there are (currently) 13 high vulnerabilities (not to mention medium ones) identified in the image.

Docker images should be maintained (i.e., continuously rebuilt) for any supported versions. at least the latest patch versions (e.g., 6.7.2) for any given supported minor version (6.7).

Otherwise, it means that only the very latest versions are supported in docker images, which is bad and misleading. In other words, the one and only only secure image version will be {very_latest_major_rev}.{very_latest_minor_rev}.{very_latest_patch}, with all others accruing vulnerabilities.

I was going to put in a bug report about this but I wanted to check here to make sure I"m not missing something.

Thanks,
Jamie

[warkolm (Mark Walkom)]

We are planning on moving to a custom, minimal base image which should reduce these kind of CVE reports.

At this point we consider our docker images like our releases, in that they are immutable once released.

[jamiejackson]

Thanks for the information. Is there a place to follow that progress?

I hope that the minimal image achieves the goal because the immutable tag philosophy renders anything but "latest" unusable.

In the meantime, is there any information on rolling one's own images? At a glance, I can't figure out how filebeat images are built: https://github.com/elastic/beats/tree/master/filebeat