> ## Documentation Index
> Fetch the complete documentation index at: https://docs.codeant.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Docker

<AccordionGroup>
  <Accordion title="Double quote to prevent globbing and word splitting">
    <div class="paragraph">
      <p>Within the command, variable references and command substitutions go through word splitting and pathname expansion (globbing).</p>
    </div>

    <div class="paragraph">
      <p>This causes issues if the variable contains whitespaces or shell pathname expansion (glob) characters like \*.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```docker Bad theme={null}
      RUN test="command t*.sh" && echo $test
      ```

      ```docker Fix theme={null}
      RUN test=" Hello World " && echo $test
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Allowing shell scripts execution during package installation is security-sensitive">
    <div class="paragraph">
      <p>ncies, package managers like <code>npm</code> will
      automatically execute shell scripts distributed along with the source code.
      Post-install scripts, for example, are a common way to execute malicious code
      at install time whenever a package is compromised.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM node:latest

      # Sensitive
      RUN npm install
      ```

      ```docker Fix theme={null}
      FROM node:latest

      # Sensitive
      RUN yarn install
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Exposing administration services is security-sensitive">
    <div class="literalblock">
      <div class="content">
        <pre> services can lead to unauthorized access to containers
        or escalation of privilege inside of containers.</pre>
      </div>
    </div>

    <div class="paragraph">
      <p>A port that is commonly used for administration services is marked as being open
      through the EXPOSE command. Administration services like SSH might contain
      vulnerabilities, hard-coded credentials, or other security issues that increase
      the attack surface of a Docker deployment.
      Even if the ports of the services do not get forwarded to the host system, by
      default they are reachable from other containers in the same network. A
      malicious actor that gets access to one container could use such services to
      escalate access and privileges.</p>
    </div>

    <div class="paragraph">
      <p>Removing the EXPOSE command is not sufficient to be secure. The port is still
      open and the service accessible. To be secure, no administration services should
      be started. Instead, try to access the required information from the host system.
      For example, if the administration service is included to access logs or debug
      a service, you can do this from the host system instead. Docker allows you to
      read out any file that is inside of a container and to spawn a shell inside of
      a container if necessary.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM ubuntu:22.04
      # Sensitive
      EXPOSE 22
      CMD ["/usr/sbin/sshd", "-f", "/etc/ssh/sshd_config", "-D"]
      ```

      ```docker Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Allowing downgrades to a clear-text protocol is security-sensitive">
    <div class="paragraph">
      <p>ot enforced here. As it is possible for the HTTP client to follow redirects, such redirects might lead to websites using HTTP.</p>
    </div>

    <div class="paragraph">
      <p>As HTTP is a clear-text protocol, it is considered insecure. Due to its lack of encryption, attackers that are able to sniff traffic from the network can read, modify, or corrupt the transported content. Therefore, allowing redirects to HTTP can lead to several risks:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Exposure of sensitive data</p>
        </li>

        <li>
          <p>Malware-infected software updates or installers</p>
        </li>

        <li>
          <p>Corruption of critical information</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Even in isolated networks, such as segmented cloud or offline environments, it is important to ensure the usage of HTTPS. If not, then insider threats with access to these environments might still be able to monitor or tamper with communications.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM ubuntu:22.04

      # Sensitive
      RUN curl --tlsv1.2 -sSf -L https://might-redirect.example.com/install.sh | sh
      ```

      ```docker Fix theme={null}
      FROM ubuntu:22.04

      # Sensitive
      RUN wget --secure-protocol=TLSv1_2 -q -O - https://might-redirect.example.com/install.sh | sh
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Running containers as a privileged user is security-sensitive">
    <div class="literalblock">
      <div class="content">
        <pre> privileged user weakens their runtime security,
        allowing any user whose code runs on the container to perform administrative
        actions. +
        In Linux containers, the privileged user is usually named root. In Windows
        containers, the equivalent is ContainerAdministrator.</pre>
      </div>
    </div>

    <div class="paragraph">
      <p>A malicious user can run code on a system either thanks to actions that could
      be deemed legitimate - depending on internal business logic or operational
      management shells - or thanks to malicious actions. For example, with arbitrary
      code execution after exploiting a service that the container hosts.</p>
    </div>

    <div class="paragraph">
      <p>Suppose the container is not hardened to prevent using a shell, interpreter, or
      <a href="https://man7.org/linux/man-pages/man7/capabilities.7.html">Linux capabilities</a>.
      In this case, the malicious user can read and exfiltrate any file (including
      Docker volumes), open new network connections, install malicious software, or,
      worse, break out of the container’s isolation context by exploiting other
      components.</p>
    </div>

    <div class="paragraph">
      <p>This means giving the possibility to attackers to steal important
      infrastructure files, intellectual property, or personal data.</p>
    </div>

    <div class="paragraph">
      <p>Depending on the infrastructure’s resilience, attackers may then extend their
      attack to other services, such as Kubernetes clusters or cloud providers, in
      order to maximize their reach.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      # Sensitive
      FROM alpine

      ENTRYPOINT ["id"]
      ```

      ```docker Fix theme={null}
      FROM alpine AS builder
      COPY Makefile ./src /
      RUN make build
      USER nonroot

      # Sensitive, previous user settings are dropped
      FROM alpine AS runtime
      COPY --from=builder bin/production /app
      ENTRYPOINT ["/app/production"]
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Cache should be cleaned after package installation">
    <div class="paragraph">
      <p>Docker images should only contain necessary data.
      The package index is optional for the correct working of the installed software.
      Storing an index also increases the size of the Docker image.
      It should be reduced to speed up deployments and reduce storage and bandwidth.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      RUN apk add nginx
      ```

      ```docker Fix theme={null}
      RUN apt-get update \
      && apt-get install nginx
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Package update should not be executed without installing it">
    <div class="paragraph">
      <p>Leaving unnecessary files in Docker image increases its size.
      The Docker images should be small and only contain necessary data.
      The cache index is obsolete after installation.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      RUN apk update
      RUN apt-get update
      RUN aptitude update
      ```

      ```docker Fix theme={null}
      RUN apk update && apk add ...
      RUN apt-get update && apt-get install ...
      RUN aptitude update && aptitude install ...
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Permissions of sensitive mount points should be restrictive">
    <div class="paragraph">
      <p>Docker offers a feature to mount files and directories for specific RUN
      instructions when building Docker images. This feature can be used to provide
      secrets to commands that are executed during the build without baking them
      into the image. Additionally, it can be used to access SSH agents during the
      build.</p>
    </div>

    <div class="paragraph">
      <p>The mode option is an octal value that allows you to specify the permissions
      for a particular file or directory. By default, on Docker, when mounting a
      secret, it is set to 0400.</p>
    </div>

    <div class="paragraph">
      <p>For ssh, it is set by default to 0600:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>The first digit 0 stands for special permissions (like setuid, setgid and
          sticky bit) and in this case means that no special permissions are set.</p>
        </li>

        <li>
          <p>The following 6 (4+2 in octal format) means that the owner has read (4)
          and write (2) permissions</p>
        </li>

        <li>
          <p>00 means that the group and others have no permissions.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>If the others bit is set to a value other than 0 at build-time, any other
      process can access it when the RUN command is executed: the secrets are
      vulnerable to supply chain attacks that aim to siphon secrets from containers.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```docker Bad theme={null}
      # Noncompliant
      RUN --mount=type=secret,id=build_secret,mode=0777 ./installer.sh
      ```

      ```docker Fix theme={null}
      RUN --mount=type=secret,id=build_secret,mode=0700 ./installer.sh
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Disabling builder sandboxes is security-sensitive">
    <div class="paragraph">
      <p>oxes can lead to unauthorized access of the host system
      by malicious programs.</p>
    </div>

    <div class="paragraph">
      <p>By default, programs executed by a RUN statement use only a subset of
      <a href="https://man7.org/linux/man-pages/man7/capabilities.7.html">capabilities</a> which
      are considered safe: this is called sandbox mode.</p>
    </div>

    <div class="paragraph">
      <p>If you disable the sandbox with the --security=insecure option, the executed command
      can use the full set of Linux capabilities.
      This can lead to a container escape. For example, an attacker with the
      SYS\_ADMIN capability is able to mount devices from the host system.</p>
    </div>

    <div class="paragraph">
      <p>This vulnerability allows an attacker who controls the behavior of the ran command to access
      the host system, break out of the container and penetrate the infrastructure.</p>
    </div>

    <div class="paragraph">
      <p>After a successful intrusion, the underlying systems are exposed to:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>theft of intellectual property and/or personal data</p>
        </li>

        <li>
          <p>extortion</p>
        </li>

        <li>
          <p>denial of service</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      # syntax=docker/dockerfile:1-labs
      FROM ubuntu:22.04
      # Sensitive
      RUN --security=insecure ./example.sh
      ```

      ```docker Fix theme={null}
      # syntax=docker/dockerfile:1-labs
      FROM ubuntu:22.04
      RUN ./example.sh
      RUN --security=sandbox ./example.sh
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Allowing non-root users to modify resources copied to an image is security-sensitive">
    <div class="paragraph">
      <p>issions for a file or directory copied to the Docker image have been assigned to a user other than root.</p>
    </div>

    <div class="paragraph">
      <p>Write permissions enable malicious actors, who have a foothold on the container,
      to tamper with the resource and thus potentially manipulate the container’s expected behavior.
      Manipulating files could disrupt services or aid in escalating privileges inside the container.</p>
    </div>

    <div class="paragraph">
      <p>This also breaches the container immutability principle as it facilitates container
      changes during its life. Immutability, a container best practice, allows for a
      more reliable and reproducible behavior of Docker containers.</p>
    </div>

    <div class="paragraph">
      <p>If a user is given ownership on a file but no write permissions, the user can still modify it by using his ownership to change the file permissions first. This is why both ownership and write permissions should be avoided.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM example

      RUN useradd exampleuser
      # Sensitive
      COPY --chown=exampleuser:exampleuser src.py dst.py
      ```

      ```docker Fix theme={null}
      FROM example

      COPY --chown=root:root --chmod=755 src.py dst.py
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="WORKDIR instruction should be used instead of cd commands">
    <div class="paragraph">
      <p>In Dockerfile, instructions RUN, CMD, and ENTRYPOINT can contain long shell scripts chaining multiple commands, including the cd command for changing directories.
      Using WORKDIR instruction instead reduces the complexity of the above instructions and makes them easier to read, understand, troubleshoot, and maintain.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```docker Bad theme={null}
      RUN cd /tmp && \
      git clone myrepository.com/MyOrganization/project && \
      cd project && \
      make && \
      cd /app/bin
      ```

      ```docker Fix theme={null}
      WORKDIR /tmp
      RUN git clone myrepository.com/MyOrganization/project && \
      cd project && \
      make
      WORKDIR /app/bin
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using ENV or ARG to handle secrets is security-sensitive">
    <div class="paragraph">
      <p>o handle secrets can lead to sensitive information being
      disclosed
      to an inappropriate sphere.</p>
    </div>

    <div class="paragraph">
      <p>The ARG and ENV instructions in a Dockerfile are used to configure the image
      build and the container environment respectively. Both can be used at image
      build time,
      during the execution of commands in the container, and ENV can also be used
      at runtime.</p>
    </div>

    <div class="paragraph">
      <p>In most cases, build-time and environment variables are used to propagate
      configuration items
      from the host to the image or container. A typical example for an environmental
      variable is the PATH variable, used
      to configure where system executables are searched for.</p>
    </div>

    <div class="paragraph">
      <p>Using ARG and ENV to propagate configuration entries that contain secrets
      causes a
      security risk. Indeed, in most cases, artifacts of those values are kept in the
      final image. The secret information
      leak can happen either in the container environment itself, the image
      metadata or the build environment logs.</p>
    </div>

    <div class="paragraph">
      <p>The concrete impact of such an issue highly depends on the secret’s purpose and
      the exposure sphere:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>Financial impact if a paid service API key is disclosed and used.</p>
        </li>

        <li>
          <p>Application compromise if an application’s secret, like a session signing
          key, is disclosed.</p>
        </li>

        <li>
          <p>Infrastructure component takeover, if a system secret, like a remote access
          key, is leaked.</p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM example
      # Sensitive
      ARG ACCESS_TOKEN
      # Sensitive
      ENV ACCESS_TOKEN=${ACCESS_TOKEN}
      CMD /run.sh
      ```

      ```docker Fix theme={null}
      FROM example
      RUN --mount=type=secret,id=build_secret ./installer.sh
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Deprecated instructions should not be used">
    <div class="paragraph">
      <p>Languages and technologies evolve, which leads to deprecation of some features.
      At some day they may be removed.
      It is important to use up-to-date constructs to avoid issues by migration to newer version of technology.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      MAINTAINER bob
      ```

      ```docker Fix theme={null}
      LABEL org.opencontainers.image.authors="bob"
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Consent flag should be set to avoid manual input">
    <div class="paragraph">
      <p>Suppose a package manager invocation is part of a script that is executed automatically, and non-interactive mode is not enabled.
      Then, execution is aborted because there is no confirming manual input.
      As a result, instructions, such as installation or update of packages, cannot be performed in an automated way.
      This applies, among others, to the package manager used in Debian-based systems, Advanced Package Tool (APT).</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      RUN apt-get install ca-certificates
      RUN aptitude install ca-certificates
      RUN apt install ca-certificates
      ```

      ```docker Fix theme={null}
      RUN apt-get -y install ca-certificates
      RUN aptitude -y install ca-certificates
      RUN apt -y install ca-certificates
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="A space before the equal sign in key-value pair may lead to unintended behavior">
    <div class="paragraph">
      <p>A few Docker instructions (like ARG, ENV, LABEL) may contain key-value pairs in form of \<key>=\<value>.
      The equal sign should not be followed by a space.
      The space before the equal sign may lead to unintended behavior.
      This is critical, especially for multiple key-value pairs, e.g. key1 = value1 key2 = value2, will lead to the key key1 with the value = value1 key2 = value2.
      In most cases it is unintended.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      ENV BUILD_NUMBER =1
      RUN echo $BUILD_NUMBER
      ```

      ```docker Fix theme={null}
      ENV BUILD_NUMBER=1
      RUN echo $BUILD_NUMBER
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Instructions should be upper case">
    <div class="paragraph">
      <p>While Dockerfile instructions are not case-sensitive, adhering to uppercase conventions for instructions helps enhance clarity and collaboration within development teams.
      This ensures that instructions are more easily distinguishable from arguments and contributes to effective collaboration.</p>
    </div>

    <div class="paragraph" />

    <CodeGroup>
      ```docker Bad theme={null}
      from ubuntu:22.04 aS jammy
      ```

      ```docker Fix theme={null}
      FROM ubuntu:22.04 AS jammy
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Pulling an image based on its digest is security-sensitive">
    <div class="paragraph">
      <p>t uniquely and immutably identifies a container image.
      A tag, on the other hand, is a mutable reference to a container image.</p>
    </div>

    <div class="paragraph">
      <p>This tag can be updated to point to another version of the container at any point in time.
      In general, the use of image digests instead of tags is intended to keep
      determinism stable within a system or infrastructure for reliability reasons.</p>
    </div>

    <div class="paragraph">
      <p>The problem is that pulling such an image prevents the resulting container from
      being updated or patched in order to remove vulnerabilities or significant bugs.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM mongo@sha256:8eb8f46e22f5ccf1feb7f0831d02032b187781b178cb971cd1222556a6cee9d1

      RUN echo ls
      ```

      ```docker Fix theme={null}
      FROM mongo:6.0

      RUN echo ls
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using remote artifacts without authenticity and integrity checks is security-sensitive">
    <div class="paragraph">
      <p>without authenticity and integrity checks can lead to
      the unexpected installation of malicious software in the built container image.</p>
    </div>

    <div class="paragraph">
      <p>In the build environment, where Dockerfiles are compiled into container images,
      malicious code could gain access to sensitive data, such as build secrets or
      source code, and durably poison the resulting image.</p>
    </div>

    <div class="paragraph">
      <p>In the runtime environments where the container images are executed, malicious
      code could access and modify all runtime data and use the container as a pivot
      to attack the surrounding network environment.</p>
    </div>

    <div class="paragraph">
      <p>By ensuring that a remote artifact is exactly what it is supposed to be before
      it is used, the environment is protected from unexpected changes before or
      after it is downloaded.
      That is to say if it has been replaced by malware:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>on the website where it is published.</p>
        </li>

        <li>
          <p>in the environment where it is used.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Important note: HTTPS protects data in transit from one host to another. It
      provides authenticity and integrity checks <strong>for the network stream</strong>, not for
      the downloaded artifact itself.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM debian

      RUN curl https://example.com/installer.sh | bash # Sensitive

      RUN curl https://example.com/installer.py -o installer.py; \
      python3 installer.py # Sensitive
      ```

      ```docker Fix theme={null}
      FROM mcr.microsoft.com/windows/servercore:ltsc2019

      RUN Invoke-Expression ((new-object net.webclient).DownloadString('https://example.com/installer.ps1')) # Sensitive

      RUN Invoke-WebRequest 'https://example.com/installer.ps1' -OutFile 'installer.ps1' -UseBasicParsing ; \
      python script.ps1 # Sensitive
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Access variable which is not available in the current scope">
    <div class="paragraph">
      <p>The variables defined by ARG instruction have a scope from the definition to the end of the build stage where it was defined.
      If it was defined in the beginning of the Dockerfile (outside of any build stage), then its scope is restricted to only FROM instructions.
      Outside of their scope, variables will be resolved to empty string which may lead to unintended behaviour.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      ARG SETTINGS
      FROM busybox
      RUN ./run/setup $SETTINGS
      ```

      ```docker Fix theme={null}
      FROM busybox
      ARG SETTINGS
      RUN ./run/setup $SETTINGS
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Dockerfile should only have one ENTRYPOINT and CMD instruction">
    <div class="paragraph">
      <p>Multiple ENTRYPOINT or CMD instructions in a file can lead to confusion as we may think they are all applied.
      This is not the case, as only the last one is applied.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM busybox
      ENTRYPOINT ignored_entrypoint param1 param2
      ENTRYPOINT effective_entrypoint param1 param2

      CMD ignored_cmd param1 param2
      CMD effective_cmd param1 param2
      ```

      ```docker Fix theme={null}
      FROM scratch as development
      CMD ignored_scratch_cmd param1 param2
      CMD effective_scratch_cmd param1 param2

      FROM busybox
      CMD ignored_busyBox_cmd param1 param2
      CMD effective_busyBox_cmd param1 param2
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Automatically installing recommended packages is security-sensitive">
    <div class="paragraph">
      <p>packages automatically can lead to vulnerabilities in the
      Docker image.</p>
    </div>

    <div class="paragraph">
      <p>Potentially unnecessary packages are installed via a known Debian package
      manager. These packages will increase the attack surface of the created
      container as they might contain unidentified vulnerabilities or malicious code.
      Those packages could be used as part of a broader supply chain attack.
      In general, the more packages are installed in a container, the weaker its
      security posture is.
      Depending on the introduced vulnerabilities, a malicious actor accessing such a
      container could use these for privilege escalation.
      Removing unused packages can also significantly reduce your Docker image size.</p>
    </div>

    <div class="paragraph">
      <p>To be secure, remove unused packages where possible and ensure images are
      subject to routine vulnerability scans.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM ubuntu:22.04

      # Sensitive
      RUN apt install -y build-essential

      # Sensitive
      RUN apt-get install -y build-essential

      # Sensitive
      RUN aptitude install -y build-essential
      ```

      ```docker Fix theme={null}
      FROM ubuntu:22.04

      RUN apt --no-install-recommends install -y build-essential

      RUN apt-get --no-install-recommends install -y build-essential

      RUN aptitude --without-recommends install -y build-essential
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Expanded filenames should not become options">
    <div class="paragraph">
      <p>Within the command, arguments and filenames as options are passed as strings.
      Programs may misinterpret files as arguments if the file name starts with a single or double dash.
      When filenames are specified using glob, files whose names begin with a dash are not included in the scope.
      For example, if a file is named "-f" and passed as an argument to a command such as "rm", it may be interpreted as a command line option instead of a file, causing unexpected behaviour.
      This issue affects all instructions processing shell commands.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      RUN rm *
      ```

      ```docker Fix theme={null}
      RUN rm ./*
      RUN rm -- *
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Environment variables should not be unset on a different layer than they were set">
    <div class="paragraph">
      <p>The environment variables often contain secrets, tokens, and other sensitive information.
      They are present in the containers and could be dumped anytime.
      Calling unset doesn’t prevent this information from being hidden for other commands.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      ENV $ADMIN_USER
      RUN unset $ADMIN_USER
      ```

      ```docker Fix theme={null}
      RUN export ADMIN_USER="admin" \
      && ... \
      && unset ADMIN_USER
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Recursively copying context directories is security-sensitive">
    <div class="paragraph">
      <p>image from a Dockerfile, a context directory is used and
      sent to the Docker daemon before the actual build starts. This context
      directory usually contains the Dockerfile itself, along with all the files that
      will be necessary for the build to succeed. This generally includes:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>the source code of applications to set up in the container.</p>
        </li>

        <li>
          <p>configuration files for other software components.</p>
        </li>

        <li>
          <p>other necessary packages or components.</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>The COPY and ADD directives in the Dockerfiles are then used to actually
      copy content from the context directory to the image file system.</p>
    </div>

    <div class="paragraph">
      <p>When COPY or ADD are used to recursively copy entire top-level directories
      or multiple items whose names are determined at build-time, unexpected files
      might get copied to the image filesystem. It could affect their
      confidentiality.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM ubuntu:22.04
      # Sensitive
      COPY . . 
      CMD /run.sh
      ```

      ```docker Fix theme={null}
      FROM ubuntu:22.04
      # Sensitive
      COPY ./example* /
      COPY ./run.sh /
      CMD /run.sh
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using host operating system namespaces is security-sensitive">
    <div class="paragraph">
      <p>stem namespaces can lead to compromise of the host system.
      Opening network services of the local host system to the container creates a new attack surface for attackers.</p>
    </div>

    <div class="paragraph">
      <p>Host network sharing could provide a significant performance advantage for
      workloads that require critical network performance. However, the successful
      exploitation of this attack vector could have a catastrophic impact on
      confidentiality within the host.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      # syntax=docker/dockerfile:1.3
      FROM example
      # Sensitive
      RUN --network=host wget -O /home/sessions http://127.0.0.1:9000/sessions
      ```

      ```docker Fix theme={null}
      # syntax=docker/dockerfile:1.3
      FROM example
      RUN --network=none wget -O /home/sessions http://127.0.0.1:9000/sessions
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Delivering code in production with debug features activated is security-sensitive">
    <div class="paragraph">
      <p>Development tools and frameworks usually have options to make debugging easier for developers. Although these features are useful during development, they should never be enabled for applications deployed in production. Debug instructions or error messages can leak detailed information about the system, like the application’s path or file names.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM example
      # Sensitive
      ENV APP_DEBUG=true
      # Sensitive
      ENV ENV=development
      CMD /run.sh
      ```

      ```docker Fix theme={null}
      FROM example
      ENV APP_DEBUG=false
      ENV ENV=production
      CMD /run.sh
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using clear-text protocols is security-sensitive">
    <div class="paragraph">
      <p>Clear-text protocols such as \`ftp, telnet, or http lack
      encryption of transported data, as well as the capability to build an
      authenticated connection. It means that an attacker able to sniff traffic from
      the network can read, modify, or corrupt the transported content. These
      protocols are not secure as they expose applications to an extensive range of
      risks:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>sensitive data exposure</p>
        </li>

        <li>
          <p>traffic redirected  to a malicious endpoint</p>
        </li>

        <li>
          <p>malware-infected software update or installer</p>
        </li>

        <li>
          <p>execution of client-side code</p>
        </li>

        <li>
          <p>corruption of critical information</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>Even in the context of isolated networks like offline environments or segmented
      cloud environments, the insider threat exists. Thus, attacks involving
      communications being sniffed or tampered with can still happen.</p>
    </div>

    <div class="paragraph">
      <p>For example, attackers could successfully compromise prior security layers by:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p>bypassing isolation mechanisms</p>
        </li>

        <li>
          <p>compromising a component of the network</p>
        </li>

        <li>
          <p>getting the credentials of an internal IAM account (either from a service
          account or an actual person)</p>
        </li>
      </ul>
    </div>

    <div class="paragraph">
      <p>In such cases, encrypting communications would decrease the chances of attackers
      to successfully leak data or steal credentials from other network components.
      By layering various security practices (segmentation and encryption, for
      example), the application will follow the <em>defense-in-depth</em> principle.</p>
    </div>

    <div class="paragraph">
      <p>Note that using the http\` protocol is being deprecated by
      <a href="https://blog.mozilla.org/security/2015/04/30/deprecating-non-secure-http">major web browsers</a>.</p>
    </div>

    <div class="paragraph">
      <p>In the past, it has led to the following vulnerabilities:</p>
    </div>

    <div class="ulist">
      <ul>
        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-6169">CVE-2019-6169</a></p>
        </li>

        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-12327">CVE-2019-12327</a></p>
        </li>

        <li>
          <p><a href="https://nvd.nist.gov/vuln/detail/CVE-2019-11065">CVE-2019-11065</a></p>
        </li>
      </ul>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      RUN curl http://www.example.com/
      ```

      ```docker Fix theme={null}
      RUN curl https://www.example.com/
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Track uses of TODO tags">
    <div class="paragraph">
      <p>Developers often use TODO tags to mark areas in the code where additional work or improvements are needed but are not implemented immediately.
      However, these TODO tags sometimes get overlooked or forgotten, leading to incomplete or unfinished code.
      This rule aims to identify and address unattended TODO tags to ensure a clean and maintainable codebase.
      This description explores why this is a problem and how it can be fixed to improve the overall code quality.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      # TODO
      FROM ubuntu
      ```

      ```docker Fix theme={null}
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Setting loose POSIX file permissions is security-sensitive">
    <div class="paragraph">
      <p>In Unix file system permissions, the "`others`" category refers to all
      users except the owner of the file system resource and the members of the group
      assigned to this resource.</p>
    </div>

    <div class="paragraph">
      <p>Granting permissions to this category can lead to unintended access to files or
      directories that could allow attackers to obtain sensitive information, disrupt
      services or elevate privileges.</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      # Sensitive
      ADD --chmod=777 src dst
      # Sensitive
      COPY --chmod=777 src dst
      # Sensitive
      RUN chmod +x resource
      # Sensitive
      RUN chmod u+s resource
      ```

      ```docker Fix theme={null}
      ADD --chmod=754 src dst
      COPY --chown=user:user --chmod=744 src dst
      RUN chmod u+x resource
      RUN chmod +t resource
      ```
    </CodeGroup>
  </Accordion>

  <Accordion title="Using weak hashing algorithms is security-sensitive">
    <div class="paragraph">
      <p>Cryptographic hash algorithms such as <code>MD2, MD4, MD5, MD6, HAVAL-128, HMAC-MD5, DSA (which uses SHA-1), RIPEMD, RIPEMD-128, RIPEMD-160, HMACRIPEMD160 and SHA-1 are no longer considered secure, because it is possible to have collisions</code> (little computational effort is enough to find two or more different inputs that produce the same hash).</p>
    </div>

    <CodeGroup>
      ```docker Bad theme={null}
      FROM ubuntu:22.04

      # Sensitive
      RUN echo "a40216e7c028e7d77f1aec22d2bbd5f9a357016f  go1.20.linux-amd64.tar.gz" | sha1sum -c 
      RUN tar -C /usr/local -xzf go1.20.linux-amd64.tar.gz
      ENV PATH="$PATH:/usr/local/go/bin"
      ```

      ```docker Fix theme={null}
      FROM ubuntu:22.04

      RUN echo "5a9ebcc65c1cce56e0d2dc616aff4c4cedcfbda8cc6f0288cc08cda3b18dcbf1  go1.20.linux-amd64.tar.gz" | sha256sum -c 
      RUN tar -C /usr/local -xzf go1.20.linux-amd64.tar.gz
      ENV PATH="$PATH:/usr/local/go/bin"
      ```
    </CodeGroup>
  </Accordion>
</AccordionGroup>