RUN update’ instruction alone

Property
Languageterraform
Severityhigh
Vulnerability Typeomission

Description

Using ‘RUN update’ alone in a Dockerfile leaves the package index updated without immediately installing packages, allowing cached layers to serve outdated or vulnerable packages in subsequent builds. The update and install commands should be combined in a single RUN statement to ensure consistency and security.

Impact

Separating update and install steps can result in outdated or insecure packages being installed if the Docker image is rebuilt, as the package list may become stale. This increases the risk of deploying containers with unpatched vulnerabilities, potentially exposing the application to exploits and compromising system integrity.

RUN cd …’ to change directory

Property
Languageterraform
Severitymedium
Vulnerability Typeomission

Description

The Dockerfile uses ‘RUN cd …’ to change directories instead of the recommended ‘WORKDIR’ instruction, making the build process harder to read, maintain, and debug. This practice can lead to unexpected behavior in subsequent instructions since directory changes do not persist across Dockerfile layers.

Impact

Relying on ‘RUN cd …’ may result in commands executing in unintended directories, increasing the risk of build errors or misconfigurations. This can lead to unreliable container images, which may expose the application to operational issues or inadvertently leak sensitive files if directory context is misunderstood.

RUN using ‘sudo

Property
Languageterraform
Severitycritical
Vulnerability Typeomission

Description

Including ‘sudo’ in RUN instructions within a Dockerfile introduces unnecessary privilege escalation, leading to unpredictable build behavior and inconsistent image states. Docker containers typically execute as root by default, making ‘sudo’ redundant and potentially problematic.

Impact

Using ‘sudo’ in Dockerfile RUN commands can cause build failures, security risks, and portability issues. It may mask permission problems, complicate troubleshooting, and open avenues for privilege misuse, potentially resulting in images that behave inconsistently or are vulnerable to privilege escalation attacks.

RUN using ‘wget’ and ‘curl

Property
Languageterraform
Severitylow

Description

Using both ‘wget’ and ‘curl’ in Dockerfiles or scripts creates unnecessary duplication, as both tools serve the same purpose for fetching remote resources. This can increase image size and maintenance complexity without adding functional value.

Impact

Including redundant utilities like ‘wget’ and ‘curl’ expands the attack surface, potentially introducing more vulnerabilities and increasing the risk of outdated or unpatched software being exploited. It also complicates dependency management and can lead to inconsistent behavior in automated environments.

Runs as root user

Property
Languageterraform
Severitymedium
Vulnerability Typeomission

Description

Containers are configured to run as the root user by default, rather than specifying a non-root user in the security context. This setup does not enforce least privilege and increases the risk of privilege escalation within the container.

Impact

If exploited, a process running as root inside the container could gain elevated permissions, potentially allowing an attacker to compromise the container, escape to the host system, or access sensitive data and resources, increasing the risk of broader system compromise.

Runs with a root primary or supplementary GID

Property
Languageterraform
Severitylow

Description

Containers are configured to run with a primary or supplementary group ID (GID) of 0, which means they operate with root group privileges. This configuration violates pod security standards that require containers to avoid running with root group access.

Impact

If exploited, a container running with root group privileges could allow processes to access or modify sensitive system files and resources, increasing the risk of privilege escalation or lateral movement within the cluster. This weakens isolation and may expose the environment to further attacks.

Runs with GID <= 10000

Property
Languageterraform
Severitylow

Description

Containers are configured to run with a group ID (GID) of 10000 or lower, or without explicitly setting ‘securityContext.runAsGroup’. This increases the risk of GID conflicts with host system groups, potentially exposing sensitive host resources.

Impact

If a container runs with a low GID or no set GID, it may unintentionally share group privileges with host users or services, increasing the risk of privilege escalation or unauthorized access to host files and processes. This can compromise container isolation and weaken overall system security.

Runs with UID <= 10000

Property
Languageterraform
Severitylow

Description

Containers are configured to run with a user ID (UID) of 10,000 or lower, or do not explicitly set a UID. This can cause conflicts with system users on the host, increasing the risk of privilege escalation or unintended access.

Impact

If exploited, attackers could leverage predictable or low-numbered UIDs to gain elevated privileges or interact with sensitive host resources, potentially compromising container isolation and system security.

Runtime/Default AppArmor profile not set

Property
Languageterraform
Severitylow

Description

The AppArmor profile for Kubernetes pods is not set to ‘runtime/default’ or is configured with a custom, non-standard profile. This means containers may run without the expected baseline security confinement provided by AppArmor.

Impact

Without the ‘runtime/default’ AppArmor profile, containers could have fewer security restrictions, increasing the risk that a compromised container could escalate privileges or affect the host system. This weakens pod isolation and may expose the cluster to container breakout or lateral movement attacks.

Runtime/Default Seccomp profile not set

Property
Languageterraform
Severitylow

Description

The Kubernetes pod or container is missing the RuntimeDefault seccomp profile, which means system call filtering is not enforced according to security best practices. This configuration leaves the workload with an overly permissive security posture.

Impact

Without the RuntimeDefault seccomp profile, containers are exposed to a broader set of system calls, increasing the risk that an attacker could exploit kernel vulnerabilities or escalate privileges if the container is compromised. This weakens pod isolation and could allow unauthorized actions on the host system.