From b9faafefb6018b938ba88d3697dfb95cb45f82d4 Mon Sep 17 00:00:00 2001 From: Zvonko Kaiser Date: Fri, 27 Jun 2025 09:41:11 -0400 Subject: [PATCH] Create SECURITY.md, SECURITY_CONTACTS MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Explicit SECURITY.md that reflects Kata’s rolling-release model (monthly cadence, no long-term branches) and sets clear expectations for reporters and downstream users. With the SECURITY.md in place we need also the SECURITY_CONTACTS Signed-off-by: Zvonko Kaiser --- README.md | 2 +- SECURITY.md | 79 +++++++++++++++++++++++++++++++++++++++++++++++ SECURITY_CONTACTS | 13 ++++++++ 3 files changed, 93 insertions(+), 1 deletion(-) create mode 100644 SECURITY.md create mode 100644 SECURITY_CONTACTS diff --git a/README.md b/README.md index 6db98ed2da..3a2f0d1689 100644 --- a/README.md +++ b/README.md @@ -105,7 +105,7 @@ Please raise an issue [in this repository](https://github.com/kata-containers/kata-containers/issues). > **Note:** -> If you are reporting a security issue, please follow the [vulnerability reporting process](https://github.com/kata-containers/community#vulnerability-handling) +> If you are reporting a security issue, please follow the [vulnerability reporting process](SECURITY.md) ## Developers diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000000..3c72536e2b --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,79 @@ +# Security Policy + +Kata Containers is a **rolling-release** project: every monthly release replaces the previous one, and only the _current_ release series receives security fixes. There are **no long-term-support branches**. + +--- + +## Reporting a Vulnerability +### How to report + +- **Keep it private first.** + Please **do not** open a public GitHub issue or pull request for security problems. + +- **Use GitHub’s built-in security advisory workflow.** + See GitHub’s official guide: + [Creating a repository security advisory](https://docs.github.com/en/code-security/security-advisories/working-with-repository-security-advisories/creating-a-repository-security-advisory#creating-a-security-advisory) + +### What happens after you submit + +We follow the OpenSSF vulnerability-handling guidelines. +The table below shows the target timelines we hold ourselves to once we receive your report. + +| Stage | Target time | Notes | +|-------|-------------|-------| +| **Initial acknowledgement** | ≤ 14 calendar days | Maintainers confirm receipt and start triage. | +| **Triage & CVSS-v3.1 scoring** | ≤ 30 days | We assign severity and plan remediation. | +| **Fix availability** | Next scheduled monthly release
(or an out-of-band patch for Critical/High issues) | We may cut a `vX.Y.Z` patch if waiting a month poses undue risk. | + +--- + +## Supported Versions + +| Release | First published | Security-fix window | +|---------|-----------------|---------------------| +| **Latest monthly release** | see `git tag --sort=-creatordate \| head -n 1` | Actively maintained | +| Any prior release | — | **Unsupported** – please upgrade | + +> **Why no backports?** +> Kata’s architecture evolves quickly; back-porting patches would re-introduce the very maintenance burden we avoid by using a rolling model. + +--- + +## Disclosure Process & Fix Delivery + +1. We develop the fix on a private branch. +2. Once validated, we coordinate embargo dates with downstream consumers when appropriate. +3. The fix ships in **either**: + * Common: The next regular monthly release (e.g., `v3.19`) when impact is moderate and waiting does not materially increase risk, **or** + * Exception: A point release (e.g., `v3.18.1`) if the vulnerability affects only the current series. +4. After the fix is public, we request a CVE ID (if not already issued) and publish details. + +--- + +## Security Advisories & Release Notes + +* Each patch or monthly release includes a **Security Bulletin** section in its GitHub *Release Notes* summarizing: + * affected components & versions, + * CVE identifiers (if assigned), + * severity / CVSS score, + * mitigation steps, + * upgrade instructions. + +* We do **not** publish separate “stable-branch” advisories because unsupported branches receive no fixes. + +--- + +## Frequently Asked Questions + +**Q: I run `v3.16` – will you patch it?** +A: No. Upgrade to the latest monthly release. + +**Q: Can I get early access to embargoed fixes?** +A: Only project members under the disclosure agreement (see [SECURITY_CONTACTS](SECURITY_CONTACTS)) receive advance patches. + +**Q: Where can I discuss the vulnerability once it is public?** +A: Open/continue a GitHub issue **after** the advisory is published, or use `#kata-containers` on Slack with a link to the advisory. + +--- + +*Last updated:* 2025-06-27 diff --git a/SECURITY_CONTACTS b/SECURITY_CONTACTS new file mode 100644 index 0000000000..4e256b39b7 --- /dev/null +++ b/SECURITY_CONTACTS @@ -0,0 +1,13 @@ +# Copyright (c) 2025 Kata Containers Authors +# +# SPDX-License-Identifier: Apache-2.0 +# +# Defined below are the security contacts for this repo. +# +# They are the contact point for the Product Security Committee to reach out +# to for triaging and handling of incoming issues. +# +# DO NOT REPORT SECURITY VULNERABILITIES DIRECTLY TO THESE NAMES, FOLLOW THE +# INSTRUCTIONS AT [SECURITY.md](SECURITY.md) + +@kata-containers/architecture-committee