Publish the versioning, support and security policy

README.md

@@ -60,6 +60,8 @@ The packages share one version and follow [Semantic Versioning](https://semver.o
 
 A minor version may add client methods, model properties and options, raise a dependency's minimum version, or drop a .NET target that isn't the lowest one once Microsoft has ended its support. A patch version may raise a dependency's patch version to fix a vulnerability. Log and exception message text can change in any version, and previews may break anything. The full rules are in [ADR-0011](docs/adr/0011-compatibility-policy.md).
 
+Fixes go to the latest minor version of the latest major version, as a new patch version: to get a fix, update to the latest minor. Previews aren't supported. When a new major version is released, the previous major version still gets security fixes for 6 months. To report a vulnerability, see [SECURITY.md](SECURITY.md).
+
 ---
 
 ## 🛠️ Quick start

SECURITY.md

@@ -2,16 +2,37 @@
 
 🇵🇱 [Jak zgłosić podatność (po polsku)](SECURITY.pl.md)
 
+## Supported versions
+
+| Version | Security fixes |
+| :--- | :--- |
+| The latest minor version of the latest major version | ✅ |
+| The previous major version | ✅ for 6 months after the next major version is released |
+| Older versions, and every preview | ❌ |
+
+A fix ships in a new patch version of the supported line (for example `1.4.2` after `1.4.1`). If you use an older minor version, update to the latest one: minor versions don't break the public API ([Versioning and support](README.md#versioning-and-support)).
+
+## Reporting a vulnerability
+
 If you find a security vulnerability in OpenUrzednik.NET (e.g. a way to leak an API key, SSRF through a crafted URL, or a problem with validating data from government responses), **don't report it in a public issue**.
 
-Use **Security → Report a vulnerability** in this repository instead (GitHub Private Vulnerability Reporting), or write to the repository maintainer.
+- **Preferred:** use **Security → Report a vulnerability** in this repository (GitHub private vulnerability reporting).
+- **If you can't use GitHub:** e-mail **security@ochodek.net**.
 
 Please include:
 
 - the package (e.g. Core, Nbp) and its version,
 - steps to reproduce,
 - the potential impact.
 
-We reply as soon as we can. This is a hobby open-source project, not a company with an SLA, so a reply may take a few days.
+## What happens next
+
+- We acknowledge your report **within 14 days**.
+- We confirm the issue or explain why we don't consider it a vulnerability, and keep you updated while we work on it.
+- We aim to publish a fixed version **within 90 days** of confirming the issue.
+- We disclose the vulnerability in a **GitHub Security Advisory** for the NuGet packages, with the affected and patched version ranges, and request a CVE when it is warranted. We credit you in the advisory unless you prefer not to be named.
+- We **deprecate the affected versions on nuget.org**, pointing to the patched version, so `dotnet list package --deprecated` and NuGet's tools show them.
+
+Please keep the details private until the advisory is published.
 
 The strong-name key `OpenUrzednik.snk` in the repository is public on purpose: a strong name is an assembly identity, not a security measure ([ADR-0005](docs/adr/0005-target-frameworks.md)). It isn't a leaked secret, so please don't report it.

SECURITY.pl.md

@@ -2,14 +2,15 @@
 
 🇬🇧 Pełna polityka bezpieczeństwa jest po angielsku: [SECURITY.md](SECURITY.md). Tu opisujemy tylko, jak zgłosić podatność. Jeśli wersje się różnią, obowiązuje angielska.
 
-Jeśli znajdziesz podatność bezpieczeństwa w OpenUrzednik.NET (np. sposób na wyciek klucza API, podatność SSRF przez skonstruowany URL, albo problem z walidacją danych z odpowiedzi urzędów), **nie zgłaszaj jej przez publiczne issue**.
+Jeśli znajdziesz podatność bezpieczeństwa w OpenUrzednik.NET (np. sposób na wyciek klucza API, podatność SSRF przez spreparowany URL albo problem z walidacją danych z odpowiedzi urzędów), **nie zgłaszaj jej w publicznym issue**.
 
-Zamiast tego użyj zakładki **Security → Report a vulnerability** w tym repozytorium (GitHub Private Vulnerability Reporting) albo napisz bezpośrednio do opiekuna repozytorium.
+- **Najlepiej:** użyj zakładki **Security → Report a vulnerability** w tym repozytorium (GitHub Private Vulnerability Reporting).
+- **Jeśli nie możesz skorzystać z GitHuba:** napisz na **security@ochodek.net**.
 
-Postaraj się opisać:
+Opisz:
 
-- który pakiet (np. Core, Nbp) i wersję,
+- pakiet (np. Core, Nbp) i jego wersję,
 - kroki do odtworzenia,
 - potencjalny wpływ.
 
-Odpowiadamy najszybciej jak to możliwe — to projekt hobbystyczny/open source, nie firma z SLA, więc czas reakcji może wynosić kilka dni.
+Nie ujawniaj szczegółów, dopóki nie opublikujemy komunikatu o podatności (GitHub Security Advisory). Terminy odpowiedzi, obsługiwane wersje i sposób ujawniania podatności opisuje [angielska polityka](SECURITY.md).

docs/RELEASE-PROCESS.md

@@ -56,8 +56,8 @@ With Claude Code, `/prepare-release` runs steps 1–5 with extra checks, and `/p
 ## Hotfix procedure (main = 1.0, develop = 1.1)
 
 We assume full API compatibility between `1.0` and `1.1` (per SemVer — a minor bump must not
-break compatibility), so there is **no need for a separate support line or for NBGV
-branch-naming**. The full process:
+break compatibility), so within one major version there is **no need for a separate support line or for NBGV
+branch-naming**. For the previous major version, see [Support for the previous major version](#support-for-the-previous-major-version). The full process:
 
 1. Create a branch from the tag of the last released version:
 
@@ -91,7 +91,19 @@ Open a PR from `merge/v1.1.0` into `develop`, label it `skip-changelog`, and mer
 
 **Never open a PR straight from `main` into `develop`:** `develop` would get the stable version from `main`'s `version.json` and publish `1.1.0-g<commit>` previews, and resolving a conflict in GitHub's web editor would commit to `main`.
 
-> If a breaking change (`2.0`) is introduced in the future and parallel support for an older `1.x` line becomes necessary, that's the point to revisit NBGV's branch-naming mechanism (`release.branchName`). It's deliberately left out for now as unneeded complexity.
+## Security fix
+
+A vulnerability is reported privately ([`SECURITY.md`](../SECURITY.md)): acknowledge it within 14 days, and aim to publish the fix within 90 days of confirming it.
+
+1. Create a draft **GitHub Security Advisory** for the report (Security → Advisories), and prepare and review the fix privately, e.g. in the advisory's **temporary private fork**, so nothing is public too early.
+2. When the fix is ready to ship, push it as a `hotfix/…` branch and release it with the hotfix procedure above. The hotfix PR is public and runs the required checks, so open it only then (`hotfix/…` from the last release tag, the next patch version, release notes, back-merge). For the previous major's support line, see below.
+3. Publish the advisory: ecosystem NuGet, every affected package, the affected and patched version ranges, a CVE when it is warranted, and credit for the reporter unless they decline.
+4. Deprecate the affected versions of every affected package on nuget.org (Manage package → Deprecation, the critical-bugs reason, alternate package: the patched version).
+5. Tell the reporter that the fix and the advisory are out.
+
+## Support for the previous major version
+
+Fixes go to the latest minor of the latest major only. When `2.0.0` is released, `1.x` still gets **security fixes for 6 months**, from a support branch `release/1.x` made from the last `v1.*` tag. Before that release, the branch needs `^refs/heads/release/1\.x$` in `publicReleaseRefSpec` (`version.json`), a trigger in the release workflow, the publishing environment's branch rule, CI triggers and ruleset protection for PRs into it, and a change to ADR-0008, which today makes `main` the only public ref ([#119](https://github.com/milten89/OpenUrzednik.NET/issues/119)). A `1.x` security fix then goes from a `hotfix/…` branch made from `release/1.x` into `release/1.x`, and is released from there.
 
 ## Dev-only dependencies vs. the published package