Rule: CodeBuild Project Plaintext Environment Variables
This rule ensures sensitive AWS values are not in plaintext environment variables.
| Rule | CodeBuild project plaintext environment variables should not contain sensitive AWS values |
| Framework | SOC 2 |
| Severity | ✔ Critical |
AWS CodeBuild Project Plaintext Environment Variables and SOC 2 Compliance
AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages that are ready to deploy. During the CI/CD (Continuous Integration and Continuous Delivery) process, it's common for developers to use environment variables to manage configuration options and secrets necessary to build and test their applications. For SOC 2 compliance, it is imperative that sensitive information, such as AWS credentials, should not be stored in plaintext in environment variables.
Understanding the Rule: No Sensitive AWS Values in Plaintext
Rule Details
Sensitive AWS values, such as access keys, secret keys, and session tokens, are considered high-risk information. Storing these values in plaintext can expose them to unauthorized users, potentially compromising the AWS account's security.
SOC 2 Compliance Implications
SOC 2 (System and Organization Controls 2) is a set of criteria for managing customer data based on five "trust service principles":
- Security
- Availability
- Processing Integrity
- Confidentiality
- Privacy
Storing sensitive AWS values in plaintext violates the security principle and can lead to non-compliance, putting the organization at risk of failing SOC 2 audits.
Troubleshooting and Remediation Steps
Identifying The Issue
- 1.Audit CodeBuild Projects: Review all AWS CodeBuild projects to identify any that may contain plaintext environment variables.
Remediation Steps
- 1.
Migrate to Secure Storage:
- Use AWS Systems Manager Parameter Store or AWS Secrets Manager to store sensitive information securely.
- Encrypt the data using AWS KMS (Key Management Service).
- 2.
Update CodeBuild Projects:
- Modify the buildspec.yml file or the project configuration to remove any sensitive data from plaintext environment variables.
- Reference secure storage solutions from the buildspec.yml.
Example Remediation
Using AWS Secrets Manager
version: 0.2
env:
secrets-manager:
MY_SECRET: my-secret-key:json-key # Reference for a secret in Secrets Manager
Using AWS Systems Manager Parameter Store
version: 0.2
env:
parameter-store:
MY_PARAMETER: "/my/parameter/store/key" # Reference for a parameter in Parameter Store
CLI Commands to Retrieve Secure Parameters in Build Phase
# Retrieve an encrypted secret from Secrets Manager aws secretsmanager get-secret-value --secret-id my-secret-key | jq -r ".SecretString" # Retrieve a parameter from Parameter Store aws ssm get-parameters --names "/my/parameter/store/key" --with-decryption | jq -r ".Parameters[0].Value"
Ongoing Compliance Monitoring
- Regular Scans: Utilize AWS services or third-party tools to conduct regular scans for compliance issues.
- Change Management: Implement a process that prevents storing sensitive values in plaintext and requires code reviews for any changes to buildspec.yml files or CodeBuild project configurations.
- Automation: Automate compliance checks using AWS Config rules or custom Lambda functions.
Validation
To validate that sensitive information is no longer stored in plaintext, recheck the CodeBuild project environment variables to ensure they only reference parameters in secured storage, and do not contain the sensitive information directly.
Final Notes
Taking these steps not only aligns with SOC 2 compliance but also strengthens the overall security posture of your AWS environment. Regular audits, proper use of secure storage, and adherence to best practices for managing secrets are essential for maintaining a robust security framework.