Security fixes are developed on the staged workspace line and backported to the published supported line when applicable. See docs/release.md for the publication state.

When the repository Security tab shows Report a vulnerability, report suspected vulnerabilities through the corresponding GitHub private reporting form. If that button is unavailable, do not put vulnerability details in a public issue. Open a minimal issue asking the maintainers to provide a private contact, without naming the affected code or including proof-of-concept details. A verified direct private channel must be published before any future release is approved.

The tag-publish preflight authenticates to GitHub and reads the repository's private-vulnerability-reporting setting. Publication fails closed unless that setting reports enabled: true; API authorization failures and malformed responses also block publication. Before creating the release tag, a repository administrator must enable Security > Private vulnerability reporting and confirm that Report a vulnerability is visible. Ordinary offline repository lint does not make this network request.

Response expectations:

• Acknowledgment of a private report within 3 business days.
• Triage decision (accepted / declined / needs more information) within 14 days of acknowledgment.
• Coordinated disclosure: we will agree on a publication date with the reporter before any advisory or fix details are made public.

• Unsupported input must fail explicitly.
• Error responses must avoid sensitive internal details.
• Device backends must not silently substitute a different explicit backend.
• Unsafe Rust inventory is tracked in docs/unsafe-audit.md.
• Fuzzing and malformed-input tests are part of release hardening.