HYG-02: Real production AWS account ID committed in tracked files, violating the repo's .gitallowed policy

[cristim]

Severity: P2. Confidence: high.

Affected files: internal/email/sender.go:517, internal/email/executed_notification_test.go:39, internal/email/template_renderers_test.go, frontend/src/__tests__/settings-accounts.test.ts:1240-1256, known_issues/23_ux_review_2026_04_22.md, .gitallowed:10

Evidence: git grep -l '540659244915' hits 5 tracked files (comment in sender.go, AccountLabel fixtures, settings-accounts external_id fixtures, a known_issues doc). This is provably the real deployment account: untracked terraform-apply-fargate.txt shows data.aws_caller_identity.current ... [id=540659244915]. The repo's own .gitallowed says: "DO NOT add a real account ID here. If a real account ID lands in the repo, rotate it and treat the leak seriously instead of silencing the scanner." All other fixtures use deliberate placeholders (123456789012 etc.).

Impact: The live account ID is published in a public repo (gh confirms visibility=PUBLIC; 4 of the files carry it on origin/main). Account IDs are not secrets but the repo's own policy treats them as sensitive: targeted phishing, ARN construction, bucket-policy probing, confused-deputy attempts. It also demonstrates the git-secrets gate has a hole - bare 12-digit numbers in labels/comments fall outside the registered regex shape.

Recommendation: Replace 540659244915 with an allowlisted placeholder in all five tracked files; investigate why git-secrets did not flag these commits; decide with the owner whether history scrubbing / treat-as-leak is warranted per the .gitallowed note.

Verifier verdict: confirmed - pushed to public main, not allowlisted, scanner-gap mechanism identified; P2 since account IDs are not credentials but this is a real published policy violation with a demonstrated gate hole.

Source: docs/reviews/codebase-review-2026-06-10.md (automated multi-dimension code review, adversarially verified for P1/P2)

[cristim]

PR #1212 replaces all occurrences of 540659244915 with the allowlisted placeholder 123456789012 in the four files that still carried it on main (internal/email/executed_notification_test.go, cited in the report, no longer contains it).

Findings from the recommended gate investigation, plus two items needing owner decisions:

1. Why git-secrets did not flag these commits (confirmed by probing the registered patterns):

• The --register-aws account-ID pattern only matches key/assignment shapes: optional aws/account/id words, then :/=/=>, then the 12 digits. aws_account_id = 540659244915 is flagged; all of the leaked shapes are not:
  • AccountLabel: "AWS 540659244915" and the sender.go comment: the digits are preceded by "AWS rather than a :/=, so the pattern cannot anchor.
  • external_id: '540659244915': git-secrets scans with grep -w (whole-word matches). A match would have to start at the id inside external_id, which is not at a word boundary, so it is rejected.
• Closing the hole generically (flag any bare 12-digit run) is noisy: tracked files legitimately contain many placeholder IDs not in .gitallowed (111122223333, 987654321098, 100000000001-400000000004, 123456789013) plus the public fck-nat AMI publisher account 568608671756 in terraform/modules/networking/aws/main.tf. If you want a stricter gate, the practical option is allowlisting those shapes and adding a bare-12-digit pattern; happy to do that as a follow-up if desired.

2. History scrubbing / treat-as-leak decision (owner call per the .gitallowed note): the ID remains in git history on the public repo even after PR #1212 merges. Scrubbing requires history rewriting (destructive, breaks clones/PRs), so it is explicitly not done here. AWS account IDs are not credentials; the standard alternative is to accept the historical exposure and rely on account hardening (SCPs, external IDs on cross-account roles, GuardDuty).

3. Second suspect ID: 909626172446 ("CUDly host") appears in 3 tracked files and looks real; filed separately as a follow-up issue.