Maintainer decisions on the two questions this branch raised rather than
answered.
Supported versions are the latest stable minor and the two minors preceding it.
Expressed as a rolling rule, so it names concrete lines when read against the
Releases page without going stale, and it replaces the activity-window test,
which classified every 1.x line back to 1.0 as supported and so described
something wider than the project does.
There is no documented rule for choosing which supported lines a fix is
backported to; it is a per-fix maintainer decision weighing severity against
backport risk. Say that plainly in SECURITY.md instead of implying a policy.
That also resolves the promise in the incident-response process, which said a
fix ships across all affected supported release lines. It does not necessarily,
and with no rule governing the choice that sentence committed the project to
something it has not agreed. Point at the per-fix decision instead.
Assisted-By: Claude <noreply@anthropic.com>
Signed-off-by: Timur Tukaev <timur.tukaev@aenix.io>
Bring the security documentation in line with controls that are already
in place, and add the two coordinated-disclosure items flagged during the
incubation due-diligence review.
- self-assessment: DCO is enforced by an automated check; private intake
is GitHub Private Vulnerability Reporting; OpenSSF passing badge achieved
2026-04-01 (working toward silver); GHSA/PVR framing for advisory history;
incident-response now summarized publicly.
- SECURITY.md: route reports to Private Vulnerability Reporting with a
MAINTAINERS.md fallback; add a 90-day coordinated-disclosure window and a
CVSS-based remediation-target table.
- CODEOWNERS: document that it encodes the area-scoped Reviewer role, which
is intentionally distinct from the MAINTAINERS.md governance roster, and
that security reporting is not routed through this file.
- Add docs/security/incident-response.md as the public incident runbook.
Co-Authored-By: Claude <noreply@anthropic.com>
Signed-off-by: tym83 <6355522@gmail.com>