Skip to content
Ask AI about this
Help improve this page

CodeBuild projects should have S3 logs encrypted

CodeBuild logs often contain build commands, environment variable references, dependency URLs, error traces, and occasionally leaked secrets or internal hostnames. Storing these logs unencrypted in S3 means anyone with bucket read access can view raw build output without an additional cryptographic barrier.

Enabling S3 log encryption adds a defense-in-depth layer. Even if bucket policies or IAM permissions are misconfigured, the log objects remain unreadable without the corresponding KMS or SSE key permissions. The cost is negligible and the default Terraform behavior already favors encryption, so disabling it is almost always an oversight.

Retrofit consideration

Changing encryption_disabled from true to false does not affect existing log objects already written to S3. Previously unencrypted objects remain unencrypted and must be re-encrypted separately.

Implementation

Choose the approach that matches how you manage Terraform.

Use AWS provider resources directly. See docs for the resources involved: aws_codebuild_project.

resource "aws_codebuild_project" "this" {
  artifacts {
    encryption_disabled = false
    location            = "example-bucket-abc123"
    type                = "S3"
  }

  environment {
    compute_type = "BUILD_GENERAL1_SMALL"
    image        = "aws/codebuild/amazonlinux2-x86_64-standard:5.0"
    type         = "LINUX_CONTAINER"
  }

  name         = "pofix-abc123"
  service_role = "arn:aws:iam::123456789012:role/example-role"

  source {
    buildspec = "version: 0.2\nphases:\n  build:\n    commands:\n      - echo hello"
    type      = "NO_SOURCE"
  }

  logs_config {
    cloudwatch_logs {
      status = "ENABLED"
    }

    s3_logs {
      encryption_disabled = false
    }
  }
}

What this control checks

In the aws_codebuild_project resource, the logs_config block may contain an s3_logs sub-block. Within s3_logs, encryption_disabled controls whether build logs written to S3 are encrypted. It defaults to false (encryption enabled), so the control passes when encryption_disabled is omitted or explicitly set to false. It fails when encryption_disabled is set to true. If the s3_logs block is absent entirely, meaning S3 logging is not configured, the control is not applicable. To use a customer-managed KMS key, configure the encryption_key argument at the top level of aws_codebuild_project; it applies to both build artifacts and logs.

Common pitfalls

  • Default is safe but easy to override

    The encryption_disabled argument defaults to false, so omitting it passes. The risk is copy-paste: some teams pull from older example configurations that explicitly set encryption_disabled = true for debugging and never revert. Review all s3_logs blocks for this flag before deploying.

  • Encryption key scope confusion

    The encryption_key argument on aws_codebuild_project applies to both artifacts and logs. If you specify a KMS key ARN there, the CodeBuild service role needs kms:GenerateDataKey and kms:Decrypt on that key. Missing those permissions causes build failures, not just compliance failures.

  • S3 bucket default encryption is not sufficient alone

    Even if the destination bucket has default encryption configured via aws_s3_bucket_server_side_encryption_configuration, CodeBuild overrides it when encryption_disabled = true is set in the project config. The control checks the CodeBuild project setting, not the bucket.

  • Existing unencrypted log objects persist

    Flipping encryption_disabled to false only affects new log writes. Objects written while encryption was off stay unencrypted. If your data protection policy requires retroactive coverage, use aws s3 cp --sse or an S3 Batch Operations job to re-encrypt them.

Audit evidence

An auditor expects to see Config rule evaluation results showing all in-scope CodeBuild projects pass the S3 log encryption check. Supporting evidence includes aws codebuild batch-get-projects output with logsConfig.s3Logs.encryptionDisabled set to false for each project. If a customer-managed KMS key is used, the key ARN should appear in the encryptionKey field and the KMS key policy should demonstrate proper access controls.

Security Hub compliance dashboards aggregating this finding across accounts add breadth to the evidence package. CloudTrail UpdateProject and CreateProject entries help show that encryption settings were not changed during the audit period.

Framework-specific interpretation

PCI DSS v4.0: Build logs in a cardholder data environment can inadvertently capture account data or sensitive authentication data. Requirement 3 expects stored data to be encrypted, and this control enforces that for CodeBuild log output.

NIST Cybersecurity Framework v2.0: PR.DS-1 and related Data Security subcategories call for protecting data at rest throughout its lifecycle. Encrypting CodeBuild S3 logs keeps build output covered under that requirement.

Tool mappings

Use these identifiers to cross-reference this control across tools, reports, and evidence.

  • Compliance.tf Control: codebuild_project_s3_logs_encryption_enabled

  • AWS Config Managed Rule: CODEBUILD_PROJECT_S3_LOGS_ENCRYPTED

  • Checkov Check: CKV_AWS_311

  • Powerpipe Control: aws_compliance.control.codebuild_project_s3_logs_encryption_enabled

  • Prowler Check: codebuild_project_s3_logs_encrypted

  • AWS Security Hub Control: CodeBuild.3

Last reviewed: 2026-03-09