CKV_AWS_45 false positive flagging Lambda environment variables that contain no secrets

[S02D-forpeople]

Describe the issue
CKV_AWS_45 is incorrectly flagging Lambda functions that have no hardcoded secrets in their environment variables. The check appears to be using regex pattern matching based on string length and is flagging any environment variable value that is exactly 40 or 48 characters long, which matches the pattern of an AWS secret access key. The values being flagged are legitimate resource names, URLs, and bucket names that just happen to be that length, not actual secrets.

Examples
CloudFormation template that triggers the false positive
"Environment": {
"Variables": {
"METRIC_NAMESPACE": "mdp/feature-logging/FdaCompositePipeline",
"FDA_DOWNLOAD_URL": "https://www.fda.gov/media/76860/download",
"S3_BUCKET": "mdp-test-new-destroy-147997161038-uploads-bucket"
}
}

Expected outcome: check passes since none of these are secrets
Actual outcome: check fails with CKV_AWS_45
What makes this particularly painful is that the failure is inconsistent across branches because our resource names are dynamically built using the branch name. So depending on how long the branch name is the resulting string length changes and sometimes lands on 40 or 48 characters which triggers the false positive. This makes it very hard to predict and fix at the source.

Version (please complete the following information):

• Checkov Version 3.2.450

Additional context
This false positive is causing our CI/CD pipelines to fail and is delaying our deployments. For now we are skipping the check entirely to unblock our pipelines but we would really like a proper fix or at minimum an official workaround other than skipping the check altogether. Is there a way to make the check smarter about distinguishing between actual secrets and resource names that happen to match the length pattern?

[MuhammadSaljooq]

Hi, I'd like to take a stab at fixing this.

I've worked extensively with Lambda and CloudFormation on AWS, and this false positive pattern is something I've run into myself — environment variable values that hit the 40/48-char length threshold but are clearly not secret access keys (bucket names, URLs, namespaces).

My proposed approach:

• Review the regex logic in the CKV_AWS_45 check
• Add entropy-based validation alongside the length check, so only values with both the right length and high entropy (characteristic of real AWS secret keys) are flagged
• Add test cases covering the exact CloudFormation patterns from this issue

Would you be happy to assign this to me? I can have a PR up within a few days.

[arpitjain099]

I dug into this. The false positive comes from the first AWS pattern in checkov/common/util/secrets.py:

(?<![A-Za-z0-9/+=])[A-Za-z0-9/+=]{40}(?![A-Za-z0-9/+=])

It matches any bare 40-character base64 run with no entropy or keyword gating, so a Lambda env value that just happens to contain a 40-char resource name, bucket name or URL fragment trips it even though it holds no secret.

Two things worth noting:

1. This is not Terraform-specific. CKV_AWS_45 has both a Terraform check (LambdaEnvironmentCredentials.py, via string_has_secrets) and a CloudFormation check (via get_secrets_from_string), and both go through that same regex, so the reported CFN case and the TF case share the root cause.
2. A Shannon-entropy gate does not cleanly separate them: a real AWS secret key (base64 of 30 random bytes) and a 40-char lowercase-plus-digits resource name land at almost the same entropy (~4.66 vs ~4.68), so raising an entropy threshold would either miss real keys or keep the FP.

The structural signal that does separate them: a real AWS secret access key almost always mixes upper-case, lower-case and digit characters, whereas a coincidental 40-char resource name usually does not.

I have a fix ready and can send a PR either way, depending on what you prefer:

• check-local: keep the change inside the CKV_AWS_45 checks (drop a bare-40-run match that can't plausibly be an AWS key), applied to both the TF and CFN variants for parity; or
• shared-scanner: tighten the bare-40-run AWS pattern in secrets.py itself, which fixes every check that uses it but has wider blast radius.

Which direction would you rather take?