security(k8s): disposition KSV-01010 — 3 ConfigMap 'sensitive content' findings are a contact address and identifier names #3240

🤖 Generated by the Agentic Engineer

Evidence

Measured on main @4d2a3dc4 with scripts/megalinter-scan-counts.sh --trivy-only, plus a
per-target JSON breakdown and a with/without-ignorefile ablation of the same scan.

KSV-01010 "ConfigMap with sensitive content" accounts for 3 of the 24 remaining trivy
misconfigurations, and it is the only remaining check with no disposition entry at all:

Why the existing KSV-0109 entries do not cover it

.trivyignore.yaml already disposes KSV-0109 ("ConfigMap stores secrets") for two of these files.
It would be easy to assume KSV-01010 is that same check renumbered and that the dispositions have
silently died — that is not what is happening, and it was checked rather than assumed:

with    .trivyignore.yaml :  24 findings — KSV-0109 ×0, KSV-01010 ×3
without .trivyignore.yaml : 598 findings — KSV-0109 ×2, KSV-01010 ×3

The ablation moves the total 24 → 598, so it demonstrably fired. KSV-0109 still exists in this
trivy and is still correctly suppressed; KSV-01010 is a separate sibling check with a wider match
set that no entry covers. The two overlap on files but not on keys — KSV-0109 fires on
external_secrets_replicas, KSV-01010 on admin_email.

Note also that k8s/clusters/local/bootstrap/config-map.yaml carries no disposition under either
id — the existing entries were written per-file for the prod bootstrap only.

Why all three are false positives

• admin_email (prod + local bootstrap) — the Let's Encrypt / ACME registration contact for the
  cluster issuer. It is a contact address the issuer requires and that appears in issued-certificate
  metadata; it is deliberately public and carries no authentication value.
• actual-budget — the ConfigMap embeds a JavaScript source file that reads credentials from an
  ESO-mounted Secret and writes them into the app's SQLite table. trivy matches the identifier
  names (enablebanking_secretKey, const secretKey), not credential values; the file contains no
  secret material. This is the identical reasoning already accepted for the same file under
  KSV-0109.

Scanner-version caveat

Measured with trivy 0.74.0; CI runs 0.73.0 via MegaLinter 10.0.0, and 🔢 Validate Scanner Versions exists precisely because that drift can look like backlog movement. Whether KSV-01010
exists in 0.73.0 is not established here. An ignorefile entry for an id the running scanner does
not emit is inert, so the disposition is safe under both and is correct ahead of the next MegaLinter
bump — but the count claim below is a 0.74.0 claim, not a CI claim.

Smallest useful change

Three path-scoped KSV-01010 entries in .trivyignore.yaml, each carrying its own reason, in the
same shape as the existing KSV-0109 pair — plus a paired control proving the scoping is what
decides, so an application ConfigMap that genuinely embeds a credential is still reported.

Acceptance criteria

• KSV-01010 reports 0 on this tree, path-scoped rather than skipped outright.
• trivy total drops 24 → 21, measured with scripts/megalinter-scan-counts.sh --trivy-only.
• A paired control shows the same bytes under a non-excepted path still FAIL the check.
• No other check's count moves.

Size: small.

Part of #2787