From 2cb0f9cd8f7167dc421cfbd869ca09c885d17fcd Mon Sep 17 00:00:00 2001 From: S Nitesh Singh Date: Mon, 23 Aug 2021 16:54:01 +0530 Subject: [PATCH] rename product security committee to security response committee --- SECURITY_CONTACTS | 2 +- content/en/docs/reference/issues-security/security.md | 8 ++++---- content/en/releases/patch-releases.md | 2 +- content/en/releases/release-managers.md | 6 +++--- 4 files changed, 9 insertions(+), 9 deletions(-) diff --git a/SECURITY_CONTACTS b/SECURITY_CONTACTS index 64a1ca5415..77910dc182 100644 --- a/SECURITY_CONTACTS +++ b/SECURITY_CONTACTS @@ -1,6 +1,6 @@ # Defined below are the security contacts for this repo. # -# They are the contact point for the Product Security Committee to reach out +# They are the contact point for the Security Response Committee to reach out # to for triaging and handling of incoming issues. # # The below names agree to abide by the diff --git a/content/en/docs/reference/issues-security/security.md b/content/en/docs/reference/issues-security/security.md index 43b01a4172..7fe91a037a 100644 --- a/content/en/docs/reference/issues-security/security.md +++ b/content/en/docs/reference/issues-security/security.md @@ -29,7 +29,7 @@ To make a report, submit your vulnerability to the [Kubernetes bug bounty progra You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md). -You may encrypt your email to this list using the GPG keys of the [Product Security Committee members](https://git.k8s.io/security/README.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure. +You may encrypt your email to this list using the GPG keys of the [Security Response Committee members](https://git.k8s.io/security/README.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure. ### When Should I Report a Vulnerability? @@ -47,13 +47,13 @@ You may encrypt your email to this list using the GPG keys of the [Product Secur ## Security Vulnerability Response -Each report is acknowledged and analyzed by Product Security Committee members within 3 working days. This will set off the [Security Release Process](https://git.k8s.io/security/security-release-process.md#disclosures). +Each report is acknowledged and analyzed by Security Response Committee members within 3 working days. This will set off the [Security Release Process](https://git.k8s.io/security/security-release-process.md#disclosures). -Any vulnerability information shared with Product Security Committee stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed. +Any vulnerability information shared with Security Response Committee stays within Kubernetes project and will not be disseminated to other projects unless it is necessary to get the issue fixed. As the security issue moves from triage, to identified fix, to release planning we will keep the reporter updated. ## Public Disclosure Timing -A public disclosure date is negotiated by the Kubernetes Product Security Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Product Security Committee holds the final say when setting a disclosure date. +A public disclosure date is negotiated by the Kubernetes Security Response Committee and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, the solution is not well-tested, or for vendor coordination. The timeframe for disclosure is from immediate (especially if it's already publicly known) to a few weeks. For a vulnerability with a straightforward mitigation, we expect report date to disclosure date to be on the order of 7 days. The Kubernetes Security Response Committee holds the final say when setting a disclosure date. diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index a802ad3a8c..c7597e332f 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -59,7 +59,7 @@ Towards the end of the twelve month, the following will happen: During the two-month maintenance mode period, Release Managers may cut additional maintenance releases to resolve: -- CVEs (under the advisement of the Product Security Committee) +- CVEs (under the advisement of the Security Response Committee) - dependency issues (including base image updates) - critical core component issues diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index 803e35cd71..0b68ca0b87 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -27,7 +27,7 @@ The responsibilities of each role are described below. | --- | --- | --- | --- | --- | | [release-managers@kubernetes.io](mailto:release-managers@kubernetes.io) | [#release-management](https://kubernetes.slack.com/messages/CJH2GBF7Y) (channel) / @release-managers (user group) | Public | Public discussion for Release Managers | All Release Managers (including Associates, Build Admins, and SIG Chairs) | | [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | N/A | Private | Private discussion for privileged Release Managers | Release Managers, SIG Release leadership | -| [security-release-team@kubernetes.io](mailto:security-release-team@kubernetes.io) | [#security-release-team](https://kubernetes.slack.com/archives/G0162T1RYHG) (channel) / @security-rel-team (user group) | Private | Security release coordination with the Product Security Committee | [security-discuss-private@kubernetes.io](mailto:security-discuss-private@kubernetes.io), [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | +| [security-release-team@kubernetes.io](mailto:security-release-team@kubernetes.io) | [#security-release-team](https://kubernetes.slack.com/archives/G0162T1RYHG) (channel) / @security-rel-team (user group) | Private | Security release coordination with the Security Response Committee | [security-discuss-private@kubernetes.io](mailto:security-discuss-private@kubernetes.io), [release-managers-private@kubernetes.io](mailto:release-managers-private@kubernetes.io) | ### Security Embargo Policy @@ -79,7 +79,7 @@ Release Managers are responsible for: answering questions and suggesting appropriate work for them to do This team at times works in close conjunction with the -[Product Security Committee][psc] and therefore should abide by the guidelines +[Security Response Committee][src] and therefore should abide by the guidelines set forth in the [Security Release Process][security-release-process]. GitHub Access Controls: [@kubernetes/release-managers](https://github.com/orgs/kubernetes/teams/release-managers) @@ -215,6 +215,6 @@ Example: [1.15 Release Team](https://git.k8s.io/sig-release/releases/release-1.1 [handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md [k-sig-release-releases]: https://git.k8s.io/sig-release/releases [patches]: /patch-releases.md -[psc]: https://git.k8s.io/community/committee-product-security/README.md +[src]: https://git.k8s.io/community/committee-product-security/README.md [release-team]: https://git.k8s.io/sig-release/release-team/README.md [security-release-process]: https://git.k8s.io/security/security-release-process.md