Find missing S3 logging, then test a source change

Check: CKV_AWS_18: "Ensure the S3 bucket has access logging enabled"
	FAILED for resource: module.s3_bucket.aws_s3_bucket.this[0]

The bucket has versioning enabled. It still fails the access-logging check. Those settings solve different problems, and a familiar module source does not make both appear automatically.

This is a real Checkov 3.3.20 finding, captured on 2026-09-28. The remediation experiment below changes the registry source and supplies logging inputs. Its authenticated plan results are not yet captured in the demo repository.

Versioning does not configure access logging

The scanned configuration uses s3-bucket 5.15.4:

module "s3_bucket" {
  source  = "terraform-aws-modules/s3-bucket/aws"
  version = "5.15.4"

  bucket = var.bucket_name

  versioning = {
    enabled = true
  }
}

There is no logging block. The scan is scoped to CKV_AWS_18, so this example answers one logging question. It does not inventory every possible finding. The full capture includes the resource address and module file that failed.

The immediate fix is to configure logging. You also need to choose where to enforce that requirement the next time someone uses the module.

Choose where the requirement should live

A wrapper can expose a narrower interface and require logging inputs. A fork can add defaults and validations inside the resource implementation, at the cost of maintaining those edits across upstream releases. A CI scanner or policy check can reject a configuration without changing the downloaded module.

Changing the module's registry source is another option. compliance.tf serves terraform-aws-modules with framework controls added to the code. That makes the downloaded implementation a place to enforce the requirement, while keeping the caller configuration recognizable. It also gives you different code to review; a familiar version number is not a substitute for inspecting it.

Keep the version fixed while changing the source

 module "s3_bucket" {
-  source  = "terraform-aws-modules/s3-bucket/aws"
+  source  = "soc2.compliance.tf/terraform-aws-modules/s3-bucket/aws"
   version = "5.15.4"

The repository's before/ and after/ configurations differ only on this source line. The request selects the SOC 2 host. It does not by itself prove that the plan is safe, that the logging requirement is enforced, or that existing resources will remain untouched.

Before introducing a requirement into an existing stack, decide what a good plan should show: missing logging rejected, the intended logging input accepted, and any replacements or unrelated changes explained. The migration guide covers the wider review; this demo has not captured a migration against existing state.

Supply logging inputs, then inspect the actual plan

The after-fixed/ example adds:

logging = {
  target_bucket = var.log_bucket_name
  target_prefix = "s3-access-logs/"
}

This is configuration to test, not a captured success. The destination bucket and its permissions need their own review. A logging block does not demonstrate that logs arrived, and a successful plan would not demonstrate delivery either.

To run the experiment, configure a compliance.tf token with SOC 2 access using Registry Endpoints, provide AWS credentials, and set bucket_name and log_bucket_name. From the scenario directory:

export TF_VAR_bucket_name=example-source-bucket
export TF_VAR_log_bucket_name=example-log-bucket
make live

Use names appropriate for your test environment. The target attempts a plan for after/, then one for after-fixed/; it does not apply infrastructure. Keep the actual errors and changes, not just the command's exit status. The first plan is allowed to fail so the second can run.

The missing outputs are listed in NOT_CAPTURED.md. Until those files exist, the evidence here is the scanner finding and the caller configuration. One logging control also remains one control, not an SOC 2 audit conclusion.

Inspect the finding without credentials

git clone https://github.com/antonbabenko/compliance.tf-demo
cd compliance.tf-demo/scenarios/01-brownfield-swap
cat expected/checkov-before.txt
make diff

These commands read the recorded finding and compare the source files locally. make demo runs Checkov if it is installed, otherwise it replays the capture; use the commands above when you want the recorded result only.

If your immediate task is fixing one bucket, configure and verify logging. If you are choosing a shared enforcement mechanism, run the authenticated experiment and review its served code and plans before adopting the source change more widely.