A CVE-bearing fix appears **twice** in its release's block: once as the "Defects Fixed" entry describing what was wrong, and once in the "Security Advisories" `<ul>` (`Release <ver> deals with the following CVEs:`) as `<li>CVE-YYYY-NNNNN - <one-line summary>.</li>`, kept in ascending CVE-number order. **Cross-reference the two**: close the Defects Fixed entry with a trailing `(CVE-YYYY-NNNNN)` before the `</li>` so a reader of the defect list can find the advisory, and vice versa. Historically the two lists were left unlinked; the 1.78 block was brought into line retroactively in `b1e21a374d` and is the worked example of the finished shape — all five of its advisory CVEs now carry a cross-reference in both directions. Do the same for new entries from now on. If an advisory has no matching Defects Fixed entry at all, that is a gap to fill rather than a case for skipping the cross-reference: 1.78 was missing entries for both CVE-2024-14041 (KyberSlash) and CVE-2024-29857 (crafted F2m EC parameters), and the fix is to write the defect entry from what the commits actually changed — for CVE-2024-29857, the `m` bound added to `ECCurve.F2m.buildField` in `efc498ca4c` / `fee80dd230` — not to paraphrase the advisory line.

**A CVE number stays out of everything until the final release of the version that fixes it.** Before then it goes in no release-note entry, no Security Advisories list, no commit message, no source or test comment, no javadoc, no documentation - anywhere public or headed that way. The defect entry is written in full without it; the cross-references above, and the Security Advisories list, are added as part of cutting the release. Until then the number lives only in the maintainer's local CVE records.

Changing the BC version (opening a dev cycle, cutting a release) is a fixed, multi-file edit, and the version string is stamped in several places besides the build properties. Update **all** of these together: