extend `SECURITY.md` with servicing commitments (SUP-05, SEC-08, SEC-09)

[turbobobbytraykov]

Situation

SECURITY.md is already strong on the intake half of the process. It publishes a private reporting channel, a coordinated-disclosure process, acknowledgement within three business days, triage within seven, a severity rubric, and a supported-versions table. Those satisfy SEC-04, SEC-05, SUP-02, SUP-04 and SUP-08, and the assessment records them as verified.

What it does not publish is anything about the outbound half — what happens after triage. Three requirements land in that gap:

ID	Requirement	Assessed as
SUP-05	Security patch cadence is documented.	defect
SEC-08	Vulnerability servicing aligns with the supported .NET cadence.	maintainer evidence required
SEC-09	Emergency out-of-band release capability exists for exploited critical issues.	maintainer evidence required

The current text says only that fix development "depends on severity and complexity" and that a patch release will be published. A reporter therefore knows when we will reply but not when, or on what release vehicle, a fix will ship — and nothing states whether we are able to ship one outside the normal release schedule at all.

SEC-09 is worth separating from the other two. It is not a request for a promise; it is a request for evidence that the capability exists. The release workflow on this branch is triggered by release: published on any tag, so an out-of-band patch release is already mechanically possible today. That is a factual statement we can make without committing to a cadence, and it closes SEC-09 on its own.

SEC-08 is partly answered by the existing supported-versions table, but the assessment reads it as a question about the .NET servicing cadence specifically: whether a fix for a supported .NET version reaches consumers on the cadence Microsoft services that version on. Since the package multi-targets net8.0, net9.0 and net10.0, an answer needs to say what happens to a target framework when it leaves Microsoft support.

Options

Option 1 — severity-based target windows

Add fix-and-ship targets keyed to the severity rubric already in the file. Concretely:

• Critical and High — patched in an out-of-band release, not held for the next scheduled one, within a stated window from triage.
• Medium and Low — patched in the next scheduled release.
• Servicing alignment — a statement that supported target frameworks track Microsoft's .NET support lifecycle, and what happens to a TFM once it goes out of support.
• Out-of-band capability — an explicit statement that the release pipeline can cut a patch release for any supported version at any time, independent of the normal schedule.

Closes SUP-05, SEC-08 and SEC-09. Strongest outcome, and the one the rubric is actually asking for.

The cost is that a published window is falsifiable. If we state fourteen days for Critical and take thirty on a hard one, we have a documented miss. That argues for choosing a window we would hit on a bad month rather than a good one, not for publishing nothing.

Option 2 — qualitative statement, no day counts

The same structure without numbers: fixes ship in the next scheduled release; Critical and High issues may ship out-of-band; supported target frameworks follow the .NET support lifecycle.

Closes SEC-09 cleanly and answers SEC-08 in substance. Leaves SUP-05 weakly addressed — a cadence is described, but "may ship out-of-band" is not a cadence, and a strict reading of the requirement would still record it as unmet.

Defensible if we are not prepared to commit to a window, and still a clear improvement on the current text.

Decisions needed before this can be implemented

1. Whether to publish day counts at all — Option 1 or Option 2.
2. If Option 1: the window for Critical and for High, measured from triage completion rather than from report receipt, so the clock is one we control.
3. What happens to a target framework when Microsoft support for it ends — dropped at the next minor, dropped at the next major, or retained until the next major regardless.
4. Whether these statements bind the commercial Ignite UI for Blazor product too, or only the Lite package. This overlaps with the same boundary question raised in add-support-issue.md and the two should be answered together.

Recommendation

Option 1, with deliberately conservative windows. Whichever is chosen, the out-of-band capability statement should go in regardless — it is a description of a pipeline that already exists, it costs nothing, and it closes SEC-09 by itself.