Trust page: explain the security advisory workload and why a busy advisory page is a good sign

[oscerd]

Summary

Recent releases have shipped a large batch of CVE advisories. This adds a box to the Trust by Default page that addresses that head-on: it frames the volume as evidence of an active security effort rather than a leaky framework, and explains the work and timing behind each advisory.

The new box sits directly after "Security handled in the open", so the two read as a pair — first how vulnerabilities are handled, then what it costs and why you see so many.

What the section says

• Where reports come from — researchers across the industry report to the ASF's private security list, and the project also audits proactively: when one component is found to mishandle inbound message headers, the whole connector portfolio is swept for the same pattern rather than patching only the reported one. That is why advisories arrive in families.
• Every reporter is credited by name in the advisory.
• The work behind each one — triage against the Security Model, a fix with regression tests, a backport to every supported release line, a CVE assignment, and a written, signed advisory with the affected version ranges and an applicable workaround.
• The timing — nothing is published until the fixes have shipped (coordinated disclosure).
• Above and beyond — advisories are published even when a hardening change has no known exploit path, "because the alternative is asking you to trust a silence you cannot check."

Notes

• No hardcoded advisory count. The copy deliberately uses durable framing ("a lot of", "in families") rather than a number, since any count drifts with every release. Verified: the new section contains no digits.
• Reuses the existing security icon and the established box/shortcode structure; shortcode open/close balance verified (20/20).
• Single file changed, additive only.

🤖 Generated with Claude Code