Split security policy into three documents

[eriknordmark]

Description

Draft: the values marked TBD(TSC) need project decisions before this is mergeable. See "Open decisions" below.

The security policy answered three unrelated questions in one file, and the one it answered worst was which releases still get security fixes. A hand-maintained table in a file nobody opens during a release had drifted into marking 10.4.x and 12.0.x supported — 10.4-stable has had no commit since July 2024 and 12.0-stable none since June 2025. That matters beyond tidiness: a vendor shipping an EVE-based product reads that table as the upstream commitment sitting behind the support period it promises its own customers.

This splits the file three ways:

• SECURITY.md keeps only what a reporter needs: where to report, what to include, when to expect an acknowledgment, the disclosure timeline, safe harbor and testing boundaries, what is in scope, and where advisories appear.
• docs/RELEASE-SUPPORT.md becomes the authoritative statement of which lines receive security fixes. It also writes down what the GitHub prerelease flag encodes, which is currently folklore: only -lts tags are published as full releases, and that is what makes the releases/latest link in the README resolve to the current LTS rather than to the newest agile release.
• docs/VULNERABILITY-HANDLING.md describes what happens after a report arrives — triage, severity, patch development in the advisory private fork, CVE assignment, embargo and vendor pre-notification, publication, and the separate path for a vulnerability already under active exploitation.

Moving the version list out of SECURITY.md follows what projects that keep their policy current do. Kubernetes, Istio and Moby all keep a "Supported Versions" heading and delegate the list to a living document; the canonical OpenSSF security-policy templates carry no supported-version content at all. The GitHub releases page is not a candidate for that pointer, because it has no support-status field and cannot express a line that receives backports without a release being cut, which is 13.4.x today.

SECURITY.md also carries the CRA stewardship statement the Linux Foundation asked its hosted projects to add, adapted from LF's template. LF's project-hosting legal entities act as the CRA stewards for the projects they host, are registered on the ENISA single reporting platform, and file the regulatory reports, so the project's job is to name the steward and to reach its contact immediately when a vulnerability turns out to be actively exploited — not to build a reporting function. This also corrects the handling policy, which claimed downstream vendors alone notify CSIRTs and ENISA; the steward files as well, and those are two separate tracks.

Three smaller changes ride along. Scope now names the repositories that build or ship code into a released image separately from the build and test repositories, and states that a vulnerability in a particular controller belongs to that controller's vendor — EVE is controller-agnostic. docs/SBOM-AND-SOURCES.md was reachable from no other page in the tree and is now linked, which matters for anyone doing component due diligence on an EVE-based product. And the acknowledgment SLA is now labelled as an acknowledgment, so it is not mistaken for a regulatory reporting deadline that happens to carry the same number of hours.

Open decisions

Every marker is greppable as TBD(TSC). None are in SECURITY.md.

Where	Decision needed
RELEASE-SUPPORT.md table	End-date of security support for 17.0.x, 16.0.x, 14.5.x, 13.4.x
RELEASE-SUPPORT.md table	Whether 10.4.x, 11.0.x and 12.0.x are end of life. The branch activity says yes; the declaration is the TSC's
RELEASE-SUPPORT.md pre-notification	Intake address, membership criteria and approver, embargo agreement text, what a member receives and when
VULNERABILITY-HANDLING.md security team	The roster, by role and GitHub handle, plus the internal coordination alias
VULNERABILITY-HANDLING.md triage	The triage window in working days
VULNERABILITY-HANDLING.md remediation	Fix and backport targets per severity
VULNERABILITY-HANDLING.md CVE assignment	Whether the project requests IDs through GitHub as a CNA, or uses a CNA of last resort
VULNERABILITY-HANDLING.md pre-notification	Vendor lead time, and whether pre-notification carries the patch or only the description
SECURITY.md CRA stewardship	The steward legal entity: the "Legal Parent" in LFX PCC under Operations, Project Definition, Legal Details. Not publicly documented, so left unset rather than guessed; support@linuxfoundation.org can confirm it
SECURITY.md CRA stewardship	Whether to add a separate emergency reporting channel, which LF's template offers, or keep the single intake with the subject-line convention
VULNERABILITY-HANDLING.md escalation	The steward's CRA escalation contact, and who on the security team holds it

Two values are filled in rather than marked, and both are published commitments worth confirming:

• 24-hour acknowledgment is carried over unchanged from the current SECURITY.md. It is aggressive for a volunteer team; the OpenSSF template default is three working days.
• 90-day disclosure timeline is new. The current policy states no disclosure deadline, and Annex I Part II(5) of Regulation (EU) 2024/2847 requires a coordinated-disclosure policy that is enforced, which needs a date. 90 days is the OpenSSF template default.

How to test and validate this PR

Documentation only; no build or runtime change, and nothing to test on device.

• markdownlint under the repository's own .markdownlint.yaml reports no findings on the three files.
• All relative links and heading anchors in the three files resolve, including RELEASE-SUPPORT.md#pre-notification-list and CONTRIBUTING.md#backporting.
• ./tools/spdx-check.sh upstream/master passes.

For review, the substantive questions are whether the scope section draws the repository boundary correctly, and whether the handling policy matches how the security team actually wants to work — it is written as a proposal, not a description of existing practice.

Changelog notes

The security policy is reorganized. SECURITY.md now covers reporting and disclosure only; security support per release line moves to docs/RELEASE-SUPPORT.md, and the vulnerability handling process is documented in docs/VULNERABILITY-HANDLING.md. The previously published support table listed release lines that no longer receive fixes.

PR Backports

• 17.0-stable: No.
• 16.0-stable: No.
• 14.5-stable: No.
• 13.4-stable: No.

GitHub surfaces SECURITY.md from the default branch only, so a backport would not change what a reporter sees. The documents describe the project as a whole rather than a branch, and per-branch copies would diverge.

Checklist

• I've provided a proper description
• I've added the proper documentation
• I've tested my PR on amd64 device
• I've tested my PR on arm64 device
• I've written the test verification instructions
• I've set the proper labels to this PR
• I've checked the boxes above, or I've provided a good reason why I didn't check them.

Device testing does not apply: the PR changes three Markdown files and no build input. No stable label, since nothing is proposed for backport.

🤖 Generated with Claude Code

https://claude.ai/code/session_01GhfowfL6NxSopWpQh2T4mD

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 26.25%. Comparing base (66f1741) to head (949a6fd).
⚠️ Report is 14 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6504      +/-   ##
==========================================
+ Coverage   25.95%   26.25%   +0.29%     
==========================================
  Files         513      523      +10     
  Lines       94155    95871    +1716     
==========================================
+ Hits        24441    25173     +732     
- Misses      67833    68628     +795     
- Partials     1881     2070     +189     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.