# Ensure that COPY is used instead of ADD in Dockerfiles

- Source: https://support.icompaas.com/support/solutions/articles/62000234384-ensure-that-copy-is-used-instead-of-add-in-dockerfiles
- Section: [Solutions](https://support.icompaas.com/support/solutions) › [CIS Docker Benchmark v1.7.0](https://support.icompaas.com/support/solutions/62000112687) › [CIS Docker Benchmark](https://support.icompaas.com/support/solutions/folders/62000169241)
- Last updated: 2026-05-29
- Publisher: iCompaas, Inc. (https://www.icompaas.com)

Profile Applicability:

-   Level 1  
    

Description:

You should use the COPY instruction instead of the ADD instruction in the Dockerfile.

Rationale:

The COPY instruction simply copies files from the local host machine to the container file system. The ADD instruction can retrieve files from remote URLs and perform operations like unpacking them. Using ADD introduces security risks, such as retrieving potentially malicious files from URLs without scanning them, or vulnerabilities related to decompressing files.

Impact:

Pros:  

-   Using COPY ensures more predictable behavior and reduces security risks.
    
-   Prevents unintentional file downloads or decompression vulnerabilities.  
    

Cons:  

-   If your application requires functionality from the ADD instruction (such as downloading files from a URL), this might require changes to your Dockerfile.
    

Default Value:

Not applicable.  

Pre-requisites:

Ensure that you have access to the Dockerfile and can modify its instructions.  

Remediation:

Test Plan:

Using AWS Console:

1.  Review the Dockerfile for the image to verify that ADD is not used. If it is, replace it with COPY.  
    

Using AWS CLI:

1.  Run the following command to check the image history:  
    
    docker history <IMAGE ID>
    
2.  Review the output to see if the ADD instruction is used.

Implementation Plan:

Using AWS Console:

Edit the Dockerfile to replace any instances of ADD with COPY. For example:

\# Replace this:
ADD https://example.com/file.tar.gz /path/in/container
# With this:
COPY file.tar.gz /path/in/container

-   Rebuild the image to apply the changes:  
    
    docker build -t <IMAGE\_NAME> .
    

Using AWS CLI:

1.  If using SSM to deploy changes, run the following command to edit the Dockerfile:  
    

aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=instanceIds,Values=instance\_id" --parameters 'commands=\["sed -i \\"s/ADD/COPY/g\\" Dockerfile && docker build -t <IMAGE\_NAME> ."\]'

Backout Plan:

Using AWS Console:

1.  Revert the Dockerfile to its previous state if the changes caused issues.  
    
2.  Use ADD instead of COPY if required by the application.

Using AWS CLI:

1.  Revert the changes in the Dockerfile by using the original file:  
    

aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=instanceIds,Values=instance\_id" --parameters 'commands=\["git checkout Dockerfile && docker build -t <IMAGE\_NAME> ."\]'

References:

-   [Dockerfile Best Practices: ADD vs COPY](https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#add-or-copy)

## Related compliance guidance

- [SOC 2 compliance: a practical implementation guide for cloud-native SaaS teams](https://support.icompaas.com/compliance/soc-2-trust-services-criteria): Configuration checks like this one are the technical half of a SOC 2 / ISO 27001 programme — the guide shows where they fit, what else an auditor expects, and how to evidence them.
- [ISO/IEC 27001:2022 compliance: a practical implementation guide](https://support.icompaas.com/compliance/iso-27001-2022): ISO 27001 Annex A.8 (technological controls) is where cloud hardening evidence lands; the guide shows how to run the ISMS around it.