# Ensure secrets are not stored in Dockerfiles

- Source: https://support.icompaas.com/support/solutions/articles/62000234385-ensure-secrets-are-not-stored-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:

Secrets, such as API keys, passwords, and sensitive data, should not be stored in Dockerfiles.  

Rationale:

Docker images are not opaque and reveal their contents. Storing secrets in Dockerfiles can expose sensitive data to anyone who uses the image.  

Impact:

Pros: Enhances security by protecting sensitive information during the build process.

Cons: Requires a secure secrets management solution for Docker builds.

Default Value:

By default, there are no restrictions on storing secrets in Dockerfiles.  

Pre-requisites:

-   Use of a secrets management tool during the Docker build process (e.g., Docker BuildKit).  
    

Remediation:

Test Plan:

Using AWS Console:

1.  Navigate to the EC2 instance running Docker.  
    
2.  Run the command docker history <IMAGE ID> to review the image and check for any stored secrets.

Using AWS CLI:

1.  Connect to the EC2 instance where Docker is running.  
    
2.  Run the following command:  
    

docker history <IMAGE ID>

Implementation Plan:

Using AWS Console:

1.  Open the Dockerfile and ensure no secrets are stored in plaintext.  
    
2.  Use Docker BuildKit or a similar secrets management tool to handle sensitive data during the build process.  
    
3.  Rebuild the Docker image:  
    

sudo docker build -t <image\_name> .

Using AWS CLI:

1.  Use SSM to update the Dockerfile and rebuild the image securely.  
    
2.  Run the following command:  
    

aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=instanceIds,Values=instance\_id" --parameters 'commands=\["echo \\"DO NOT store secrets in Dockerfile\\" >> /path/to/Dockerfile && sudo docker build -t <image\_name> ."\]'

Backout Plan:

Using AWS Console:

1.  Revert the Dockerfile changes and remove any secrets stored in the file.  
    
2.  Rebuild the Docker image:  
    

sudo docker build -t <image\_name> .

Using AWS CLI:

1.  Use SSM to revert any changes made to the Dockerfile and rebuild the image.  
    
2.  Run the following command:  
    

aws ssm send-command --document-name "AWS-RunShellScript" --targets "Key=instanceIds,Values=instance\_id" --parameters 'commands=\["sed -i \\"/DO NOT store secrets in Dockerfile/d\\" /path/to/Dockerfile && sudo docker build -t <image\_name> ."\]'

References:

-   CIS Docker Benchmark v1.7  
    
-   Docker Documentation: [https://docs.docker.com/](https://docs.docker.com/)

## 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.