From 191cd9c877d681d7901ad3a704d1d86335b63e7b Mon Sep 17 00:00:00 2001 From: Tiger Kaovilai Date: Wed, 22 Jul 2026 03:08:23 -0400 Subject: [PATCH] Drop embargo policy; no pre-disclosure distributor list for Velero @reasonerjt: "I think at this moment perhaps we are good not having embargo list for velero." Removes the Embargo Policy section and the early/private draft-advisory step, since there's no governance backing private pre-disclosure to distributors anymore. Disclosure is now report -> fix -> single public GitHub security advisory. Signed-off-by: Tiger Kaovilai --- SECURITY.md | 18 +++--------------- 1 file changed, 3 insertions(+), 15 deletions(-) diff --git a/SECURITY.md b/SECURITY.md index 4e72b5522..27182f041 100644 --- a/SECURITY.md +++ b/SECURITY.md @@ -66,9 +66,8 @@ The Security Team will respond to vulnerability reports as follows: 4. If a vulnerability is acknowledged and the timeline for a fix is determined, the Security Team will work on a plan to communicate with the appropriate community, including identifying mitigating steps that affected users can take to protect themselves until the fix is rolled out. 5. The Security Team will also create a [CVSS](https://www.first.org/cvss/specification-document) using the [CVSS Calculator](https://www.first.org/cvss/calculator/3.0). The Security Team makes the final call on the calculated CVSS; it is better to move quickly than making the CVSS perfect. Issues may also be reported to [Mitre](https://cve.mitre.org/) using this [scoring calculator](https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator). The CVE will initially be set to private. 6. The Security Team will work on fixing the vulnerability and perform internal testing before preparing to roll out the fix. -7. Ahead of the fix landing, the Security Team may provide early disclosure by privately sharing a draft [security advisory](https://github.com/velero-io/velero/security/advisories) with known downstream distributors, so they can plan for the vulnerability patch ahead of the fix and later test the fix and provide feedback to the Velero team. -8. A public disclosure date is negotiated by the Security Team and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation or patch 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 distributor coordination. The timeframe for disclosure is from immediate (especially if it’s already publicly known) to a few weeks. For a critical vulnerability with a straightforward mitigation, we expect the report date for the public disclosure date to be on the order of 14 business days. The Security Team holds the final say when setting a public disclosure date. -9. Once the fix is confirmed, the Security Team will patch the vulnerability in the next patch or minor release, and backport a patch release into all earlier supported releases. Upon release of the patched version of Velero, we will follow the **Public Disclosure Process**. +7. A public disclosure date is negotiated by the Security Team and the bug submitter. We prefer to fully disclose the bug as soon as possible once a user mitigation or patch is available. It is reasonable to delay disclosure when the bug or the fix is not yet fully understood, or the solution is not well-tested. The timeframe for disclosure is from immediate (especially if it’s already publicly known) to a few weeks. For a critical vulnerability with a straightforward mitigation, we expect the report date for the public disclosure date to be on the order of 14 business days. The Security Team holds the final say when setting a public disclosure date. +8. Once the fix is confirmed, the Security Team will patch the vulnerability in the next patch or minor release, and backport a patch release into all earlier supported releases. Upon release of the patched version of Velero, we will follow the **Public Disclosure Process**. ## Public Disclosure Process @@ -82,7 +81,7 @@ The Security Team will also publish any mitigating steps users can take until th ## Security Notification Template -Pre-disclosure notifications (e.g. via a draft security advisory shared with downstream distributors) and public advisories will include, at minimum: +Public advisories will include, at minimum: * Purpose and summary of the notification. * Vulnerability name, along with its CVE identifier if one has been assigned. @@ -101,17 +100,6 @@ Pre-disclosure notifications (e.g. via a draft security advisory shared with dow * Use cncf-velero-security@lists.cncf.io to report security concerns to the Security Team, who uses the list to privately discuss security issues and fixes prior to disclosure. -## Embargo Policy - -This embargo policy applies to everyone who receives vulnerability information ahead of public disclosure, including Security Team members, Velero maintainers, and any downstream distributor notified early. This information must not be made public, shared, or even hinted at anywhere beyond those who need to know within your specific team, unless you receive explicit approval to do so from the Security Team. This remains true until the public disclosure date/time agreed upon with the Security Team. This information cannot be used for any reason other than to get the issue fixed for your organization's users. - -Before you share any information with members of your team who are required to fix the issue, these team members must agree to the same terms, and only be provided with information on a need-to-know basis. - -In the unfortunate event that you share information beyond what is permitted by this policy, you must urgently inform the Security Team (cncf-velero-security@lists.cncf.io) of exactly what information was leaked and to whom. If you continue to leak information and break the policy outlined here, you will be excluded from future early disclosures. - - - - ## Confidentiality, integrity and availability We consider vulnerabilities leading to the compromise of data confidentiality, elevation of privilege, or integrity to be our highest priority concerns. Availability, in particular in areas relating to DoS and resource exhaustion, is also a serious security concern. The Security Team takes all vulnerabilities, potential vulnerabilities, and suspected vulnerabilities seriously and will investigate them in an urgent and expeditious manner.