Skip to content

CodeBuild projects should have logging enabled

Build logs capture compilation errors, dependency resolution output, test results, and security scan findings. Without them, debugging failed builds becomes guesswork, and incident responders lose visibility into what code was built, when, and with what dependencies.

Disabling all logging also removes the audit trail for build activity. If a compromised build injects malicious artifacts, you have no log evidence to trace the timeline or scope of impact.

Retrofit consideration

Enabling logging on existing projects does not interrupt running builds. Verify the target CloudWatch log group or S3 bucket exists and has correct IAM permissions before applying.

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"
  }

  logs_config {
    cloudwatch_logs {
      status = "ENABLED"
    }
  }

  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"
  }
}

What this control checks

The aws_codebuild_project resource includes a logs_config block with optional cloudwatch_logs and s3_logs sub-blocks. Each sub-block takes a status argument: ENABLED or DISABLED. The control passes when at least one sub-block sets status = "ENABLED". It fails only when both cloudwatch_logs and s3_logs explicitly set status = "DISABLED". To pass, configure at least one destination: cloudwatch_logs { status = "ENABLED" } with a group_name pointing to a valid log group, or s3_logs { status = "ENABLED" location = "<bucket>/<prefix>" }, or both.

Common pitfalls

  • Omitting logs_config entirely still passes

    Without an explicit logs_config block, you have no control over log group naming, retention, or encryption. A status-based check may still pass depending on defaults, but you're relying on behavior you haven't defined in Terraform. Always declare logs_config explicitly.

  • S3 logs enabled without a valid location

    Setting s3_logs { status = "ENABLED" } without specifying location causes an API error. The location argument (format: bucket-name or bucket-name/prefix) is required when S3 logging is enabled.

  • IAM role missing log permissions

    The CodeBuild service role needs logs:CreateLogGroup, logs:CreateLogStream, and logs:PutLogEvents for CloudWatch, or s3:PutObject for S3. Missing permissions mean builds may fail or silently skip logging even though the Terraform configuration looks correct.

  • Encryption mismatch on S3 log bucket

    If the S3 bucket uses a customer-managed KMS key, the CodeBuild service role also needs kms:GenerateDataKey on that key. Without it, log delivery fails silently and the bucket stays empty despite encryption_disabled = false in the s3_logs block.

Audit evidence

Auditors expect Config rule evaluation results showing all CodeBuild projects COMPLIANT, or equivalent output from a cloud security posture tool. Supporting evidence includes the CloudWatch log group ARN or S3 bucket path configured in each project's logsConfig, visible in the CodeBuild console under Build details or via aws codebuild batch-get-projects. Auditors will also check that the referenced log group or bucket contains actual build log entries, confirming logs are not just configured but actively received and retained for the required period.

Framework-specific interpretation

PCI DSS v4.0: Requirement 10 mandates logging and monitoring across all system components in cardholder data scope. CodeBuild projects that compile or package payment application code must produce logs to support activity tracking and detection of unauthorized access.

HIPAA Omnibus Rule 2013: 164.312(b) requires audit controls that record and examine activity in systems containing ePHI. CodeBuild projects that process health data or build healthcare applications need to retain build logs as part of that information system activity review obligation.

NIST Cybersecurity Framework v2.0: Build logs feed directly into DE.CM continuous monitoring and support anomaly and event detection for anything built in CodeBuild. Without them, you lose a key input for correlating security events and identifying unauthorized changes to software artifacts.

Tool mappings

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

  • Compliance.tf Control: codebuild_project_logging_enabled

  • AWS Config Managed Rule: CODEBUILD_PROJECT_LOGGING_ENABLED

  • Checkov Check: CKV_AWS_314

  • Powerpipe Control: aws_compliance.control.codebuild_project_logging_enabled

  • Prowler Check: codebuild_project_logging_enabled

  • AWS Security Hub Control: CodeBuild.4

Last reviewed: 2026-03-09