Include more specific GPG recomendation usage.
Add generalised rules for vulnerabilties.
Signed-off-by: Andrew Kampjes <a.kamp...@gmail.com>
---
SECURITY.md | 41 +++++++++++++++++++++++++++++------------
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/SECURITY.md b/SECURITY.md
index d558d44..c85e594 100644
--- a/SECURITY.md
+++ b/SECURITY.md
@@ -23,25 +23,33 @@ What is a vulnerability?
------------------------
All vulnerabilities are bugs, but not every bug is a vulnerability.
+Vulnerabilites compromise one or more of:
+
+ * Confidentiality (Personal and company data/secrets).
+ * Integrity (trustworthyness and correctness).
+ * Availability (Uptime and service).
+
Here are some examples of vulnerabilities to which one would expect to
apply this process:
- * A crafted packet that causes a kernel or userspace crash.
+ * A crafted packet that causes a kernel or userspace crash
+ (Availability).
* A flow translation bug that misforwards traffic in a way likely
- to hop over security boundaries.
+ to hop over security boundaries (Integrity).
* An OpenFlow protocol bug that allows a controller to read
- arbitrary files from the file system.
+ arbitrary files from the file system (Confidentiality).
* Misuse of the OpenSSL library that allows bypassing certificate
- checks.
+ checks (Integrity).
* A bug (memory corruption, overflow, ...) that allows one to
modify the behaviour of OVS through external configuration
- interfaces such as OVSDB.
+ interfaces such as OVSDB (Integrity).
- * Privileged information is exposed to unprivileged users.
+ * Privileged information is exposed to unprivileged users
+ (Confidentiality).
If in doubt, please do use the vulnerability management process. At
worst, the response will be to report the bug through the usual
@@ -53,8 +61,17 @@ Step 1: Reception
To report an Open vSwitch vulnerability, send an email to the
ovs-security mailing list (see "Contact" at the end of this document).
-A security team member should reply to the reporter acknowledging that
-the report has been received.
+A security team member should reply to the reporter within 24 hours
+acknowledging that the report has been received.
+
+Reporters may ask for a GPG key while initiating contact with the
+security team to deliver more sensitive reports.
+If the reporter has used GPG while disclosing, further vulnerability
+details should also be discussed using GPG.
+
+Please don't report security vulnerabilities to the ovs-dev list,
+ovs-bug list or github issues to allow the team ovs security team
+to responsibly fix the vulnerability.
Please consider reporting the information mentioned in
REPORTING-BUGS.md, where relevant.
@@ -132,11 +149,11 @@ vSwitch user who is interested and can be considered
trustworthy
enough could be included. To become a downstream stakeholder, email
the ovs-security mailing list.
-If the vulnerability is public, skip this step.
+If the vulnerability is already public, skip this step.
-Step 5: Full Disclosure
------------------------
+Step 5: Public Disclosure
+-------------------------
When the embargo expires, push the (reviewed) patches to appropriate
branches, post the patches to the ovs-dev mailing list (noting that
@@ -151,7 +168,7 @@ The security advisory should be GPG-signed by a security
team member
with a key that is in a public web of trust.
-Contact
+Contact
=======
Report security vulnerabilities to the ovs-security mailing list:
--
1.9.1
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
