You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: SECURITY.md
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,5 @@
1
1
<!--security-start-->
2
+
2
3
## Security Announcements
3
4
4
5
Join the [kubestellar-security-announce](https://groups.google.com/u/1/g/kubestellar-security-announce) group for emails about security and major API announcements.
@@ -16,7 +17,6 @@ You can also email the private [kubestellar-security-announce@googlegroups.com](
16
17
- You think you discovered a vulnerability in another project that KubeStellar depends on
17
18
- For projects with their own vulnerability reporting and disclosure process, please report it directly there
18
19
19
-
20
20
### When Should I NOT Report a Vulnerability?
21
21
22
22
- You need help tuning KubeStellar components for security
@@ -34,4 +34,5 @@ As the security issue moves from triage, to identified fix, to release planning
34
34
## Public Disclosure Timing
35
35
36
36
A public disclosure date is negotiated by the KubeStellar 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 KubeStellar maintainers hold the final say when setting a disclosure date.
0 commit comments