infisical scan (0.43.136+) never reports an AWS access key ID that has no secret within 5 lines #428

Version: CLI 0.43.136 through 0.43.141 (betterleaks engine). 0.43.135 (gitleaks engine) is not affected.

Since #406 vendored betterleaks 1.8.1, infisical scan no longer reports an AWS access key ID unless an AWS secret access key sits within 5 lines of it in the same file. This holds at every --confidence level, so a key ID alone in a .env, a ~/.aws/credentials file, a JSON/YAML config, a URL, or a log line is never reported.

Reproduction

printf 'AWS_ACCESS_KEY_ID=AKIA%s\n' "$(LC_ALL=C tr -dc 'A-Z2-7' </dev/urandom | head -c16)" > lone.env
infisical scan --no-git --source . --report-path r.json --report-format json --exit-code 0
cat r.json   # 0.43.141: []   0.43.135: one aws-access-token finding

Same with --confidence low or high. Adding AWS_SECRET_ACCESS_KEY=<40 chars> on the next line makes the key ID appear again, with the secret nested under ComponentSets.

Measured on 30 random samples x 19 lone-key shapes (env, ini, json, yaml, URL, boto3 kwargs, aws configure set, Terraform, properties, ...): 570/570 reported by 0.43.135, 0/570 by 0.43.141.

Cause

Upstream: the aws-access-token rule became a composite in betterleaks/betterleaks#53, requiring an aws-secret-access-key component (within = "5L", skipReport = true); see detect/config/betterleaks.toml:739-818 at v0.43.141. When the component is missing, the primary finding is dropped in detect/detect.go (hasAllRequiredComponents) before confidence filtering. Reported upstream as betterleaks/betterleaks#408 with a fix in betterleaks/betterleaks#409: a standalone medium-confidence aws-access-key-id rule that leaves the composite untouched.

Separately, the default --confidence medium drops lone AWS secret access keys, generic API keys and passwords, because betterleaks rates its generic rules low. That one is a documented trade-off rather than a bug, but it compounds this gap for anyone who moved from 0.43.135 expecting the same findings.

Proposed fix

Re-vendor once the upstream fix is released, or cherry-pick the 21-line aws-access-key-id block into detect/config/betterleaks.toml. I tested that block against a rebuild of v0.43.141: lone key IDs went from 0/570 to 570/570, paired keys were unchanged, and 4,428 secret-free files produced no new findings. Happy to open the PR once you're OK with the approach.