I'm happy about any contribution :-)

@aheinze I just ran some more analysis and for now it seems to be the most realisitic option to just upgrade to php:7.4.24 as base image. So basically it would already help a lot, if you just rebuild the image and pushed it again :)

Since php-7.4 will run be reaching EOL by the end of the year, I already checked for php-8. Running cockpit locally on php-8.0.11 seems to be working fine. Running it on php-8.1.1 however does not seem to work. From docker security perspective it currently makes no difference anyhow.

If I find more time I will look into more options. For now I think it's good to get from 284 vulnerabilities to 91 (especially from 91 ciritical/high to 9 critical/high) with little effort.

I will close here for now and reopen if I have more findings.

Not sure why you closed this issue @tommueller - after all, a new build / image push is still desperately needed here 😉

I didn't notice this issue because it was closed and then filed my own issue for the very same reasons in March (albeit less detailed than yours - thanks for the info/research, especially putting PHP 8 into this relation also...): #21

So linking this together here.

By any chance: how did you manually build the images to test with/run scans?
I have this image running in a production setup and we are running out of time to get this fixed, so I'm starting to look for workarounds as there is very few activity here unfortunately.

I closed this, because rebuilding fixed most of the warnings for me. Since the Dockerfile starts from FROM php:7.4-apache, by rebuilding I got to php:7.4.24-apache´. Since php:8.0.11-apache` wouldn't have provided more fixes, I closed the ticket, because it seemed as good as possible for now.

Thanks @tommueller for the swift response 😉
So I understand you went for "roll your own", which solved your case - but doesn't make any up-to-date image publicly available.

Thus I will keep #21 open and probably go with a fork for now.

Thanks for your support 👍