From 84e0cf98ee6023d5025075b5adcdfa74579e16de Mon Sep 17 00:00:00 2001 From: Andrzej Ochodek Date: Fri, 30 Oct 2026 15:07:59 +0100 Subject: [PATCH] Publish the versioning, support and security policy SECURITY.md states the supported versions, the reporting channels (GitHub private vulnerability reporting, then security@ochodek.net), a 14-day acknowledgement, a 90-day fix target, and disclosure through a GitHub Security Advisory plus deprecation on nuget.org; SECURITY.pl.md covers how to report. The README gives the support rules, and RELEASE-PROCESS gets a security-fix checklist and the 6-month support line for the previous major version. Co-Authored-By: Claude Opus 5.5 --- README.md | 2 ++ SECURITY.md | 25 +++++++++++++++++++++++-- SECURITY.pl.md | 11 ++++++----- docs/RELEASE-PROCESS.md | 18 +++++++++++++++--- 4 files changed, 46 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index f17ee51..870d5ce 100644 --- a/README.md +++ b/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 diff --git a/SECURITY.md b/SECURITY.md index 9722b38..a7dd529 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -2,9 +2,22 @@ 🇵🇱 [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: @@ -12,6 +25,14 @@ Please include: - 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. diff --git a/SECURITY.pl.md b/SECURITY.pl.md index e814abc..b32ec83 100644 --- a/SECURITY.pl.md +++ b/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). diff --git a/docs/RELEASE-PROCESS.md b/docs/RELEASE-PROCESS.md index 44af4e6..b4db638 100644 --- a/docs/RELEASE-PROCESS.md +++ b/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` 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