Skip to content

Rebuild current image to get updated PHP version and avoid CVEs / security-scanning false-positives?Β #21

@sambernet

Description

@sambernet

Hi

We use the current 0.12.2 version of the agentejo/cockpit-docker image.
The image is based upon the php:7.4-apache upstream base image.

Unfortunately the 0.12.2 version (but also latest) have not been built & published for over 6 months now. the php base image was using PHP version 7.4.2 when the last image build was performed:

docker run --rm -it agentejo/cockpit:0.12.2 bash -c "php -v"
PHP 7.4.2 (cli) (built: Feb  1 2020 19:39:30) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies
    with Zend OPcache v7.4.2, Copyright (c), by Zend Technologies

Whereas the current version of the php:7.4-apache image delivers a fully-patched "old-stable" PHP version 7.4.28:

docker run --rm -it php:7.4-apache bash -c "php -v"
PHP 7.4.28 (cli) (built: Mar  3 2022 09:55:51) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0, Copyright (c) Zend Technologies

This leads to the agentejo/cockpit-docker:latest and agentejo/cockpit-docker:0.12.2 image versions being tagged as vulnerable to a range of vulnerabilities during security scanning. Some examples:

To be fair, agentejo/cockpit-docker is in reality not vulnerable to any of those CVEs according to my own research (e.g. the critical CVE-2020-7061 only affects PHP running on windows OS to start with...) - but due to the outdated and potentially vulnerable PHP 7.4.2 version being used in the image, this still raises red flags whenever any security scanning is performed on the final image or some exposure assessment is done.

Overall I am left with the following questions/wishes/suggestions:

  • Would it be possible to just perform a fresh build, making sure the updated php:7.4-apache base image is used for the build, and publish an updated image?
  • Would it maybe make sense to use more explicit upstream version tags in the FROM instruction in the Dockerfile to simplify obtaining upstream PHP/Apache version information? That would mean using FROM php:7.4.28-apache-buster instead of the more broad FROM php:7.4-apache (also fixing the debian base distro version along the way)?
  • Should this updated image be published with a new version tag, e.g. 0.12.2_1 to distinguish it from the previous, vulnerable version, or would it be favorable to override the existing tag?

I would be happy to discuss those matters with @aheinze - or whoever can help - and can of course also provide an MR if that helps.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions