docs: [#435] document mysql:8.4 CVE analysis and accepted risk

[josecelano]

Summary

Re-scan of mysql:8.4 as requested in issue #435.

No code change — mysql:8.4 is a floating tag (no version constant to update).

Findings (Apr 15, 2026 — Trivy v0.69.3)

Image	Resolves to	HIGH	CRITICAL
mysql:8.4	8.4.8	9	1
mysql:9.6	9.6.0	9	1

The floating tag still resolves to 8.4.8 (same digest as Apr 8 baseline). The CVE count
moved from 7H+1C → 9H+1C due to Trivy DB updates only; no new MySQL release was shipped.

All vulnerabilities are in helper components only — not MySQL Server core:

• gosu v1.24.6 (Go stdlib): 7 HIGH + 1 CRITICAL
  • CRITICAL: CVE-2025-68121 — crypto/tls cert validation during TLS resumption (fix: Go ≥ 1.24.13)
• MySQL Shell Python packages: 2 HIGH (cryptography, pyOpenSSL)

mysql:9.x Assessment

mysql:9.6 (latest Innovation Release, 2026-04-14) has an identical CVE profile: same
gosu v1.24.6 and same Python packages → no security benefit to switching. Additionally,
mysql:9.x is a non-LTS Innovation Release with a shorter lifecycle vs mysql:8.4 (LTS until Apr 2032).

Decision

Accepted risk — close #435.

• No viable upgrade path exists (same CVEs across all tags)
• CVEs are in gosu helper and mysqlsh tools, not MySQL server
• Fix requires MySQL upstream to ship new image with gosu rebuilt on Go ≥ 1.24.13
• Revisit when mysql:8.4.9 or later is released

Changes

• docs/security/docker/scans/mysql.md — new Remediation Pass 2 history entry with full CVE tables
• docs/security/docker/scans/README.md — updated mysql row (9H+1C, Apr 15)
• docs/issues/435-mysql-cves.md — checked off steps, filled Outcome section
• project-words.txt — added DTLS, mysqlsh, syscall

Closes #435

[josecelano]

ACK 0ece6d4