Docker Image Scan results for linuxserver/phpmyadmin

Scan performed at 2022-12-12 15:23:07 using the CoGuard CLI

Summary

11 Total failed checks. 1 High / 2 Medium / 8 Low.

Details

Rule identifier	Severity	Documentation
dockerfile_last_user_should_be_non_root	4	When creating a Docker container, it is possible to set the user who is actually running the application and any command on the container. It is important to specifically use the USER directive in any Dockerfile to ensure that the user is not root and has unnecessary privileges. Remediation: Have at least one USER directive in your Dockerfile, and the last user directive should not reference the root user or root group. Source: https://docs.docker.com/engine/reference/builder/#user
dockerfile_pin_versions_package_install	3	One desirable goal of docker images is that changing their Docker-files and re-building them in the future does not cause issues unrelated to the new changes. One way an image may not build in the future is if the Dockerfile contains instructions to install a certain program/library without pinning the version. Remediation: Ensure that inside a Dockerfile, you pin the versions of any installed packages using apt, yum, apk, pacman, dnf, zypper, npm or pip. Source: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#apt-get
dockerfile_create_volume_for_var_log	3	In linux systems, important operating system logs are stored in the /var/log subfolder. This folder should always be made available to the host through a volume, so that log tracking and log analysis systems can capture them. Remediation: In every Dockerfile, there should be a VOLUME directive which has /var/log as an argument. Source: https://docs.docker.com/engine/reference/builder/
dockerfile_shell_commands_invalid_for_image_creation	2	A Dockerfile is a set of commands to create an image. This image creation can appear on any host, and is not reflective of the host the container is run on at the end. Hence, certain shell commands do not make sense in a Dockerfile context. Remediation: For any RUN command, ensure that the following unix shell commands do not appear in its argument: - ssh - vim - emacs - nano - shutdown - service - systemctl - ps - free - top - kill - mount .
dockerfile_shell_check_on_run_commands	2	Run commands in the Dockerfile are, generally speaking, shell scripts. It is best practice to lint them and do a shell-check on them for common, shell-script related errors, which can be quite subtle. Remediation: Ensure that all RUN command lines would pass a run through the shellcheck database of common shell scripting errors. Source: https://www.shellcheck.net/wiki/
dockerfile_copy_command_more_than_two_arguments_slash	2	The COPY directive allows the copying of one or more files on the host machine into the image that is being built. If there is more than one file copied, it is apparent that the destination is a folder, and hence has to end with /. Remediation: Ensure that every COPY instruction with more than two arguments has the last argument ending with / Source: https://docs.docker.com/engine/reference/builder/#copy
dockerfile_container_healthcheck_parameter	2	Dockerfiles have an instruction called HEALTHCHECK. It enables a user to define a command to figure out if the program(s) running inside the container are working properly. It is generally advisable to have healthchecks in place to assist monitoring of running containers. Remediation: Have at least one HEALTHCHECK instruction in your Dockerfile. Source: https://docs.docker.com/engine/reference/builder/#healthcheck
dockerfile_copy_destination_absolute_path_or_var	1	The COPY command should define its destination using an absolute path. Remediation: Ensure that every COPY instruction has as last argument a string starting with '/' or starting with an environment variable/argument. Source: https://docs.docker.com/develop/develop-images/dockerfile_best-practices
dockerfile_env_and_arg_defined_and_right_away_used	1	When creating Docker images that use environment variables or build arguments, it is advisable to position the ARG or ENV directives close to their actual uses, since otherwise the caching for building the images is not greatly used. Remediation: Every variable defined by an ENV or ARG directive should be used within the next five commands inside the Dockerfile.
dockerfile_only_one_definition_per_env_statement	1	The ENV statement allows multiple definitions. This should be avoided for readability reasons, as well as pitfalls like variables not being evaluated if defined within the same ENV directive. Remediation: Ensure that every ENV directive has only one assignment.
dockerfile_do_not_use_add	1	Dockerfiles have two directives that allow you to add files from the machine where you build the image into the image, namely COPY and ADD. Both are technically similar, but ADD also has side-effects like automated decompression of archives. It is generally recommended to only use COPY Remediation: Remove any ADD directive in your dockerfile and replace it with COPY. Source: https://docs.docker.com/engine/reference/builder/#copy

Scan performed at 2022-12-12 15:23:07 using the CoGuard CLI