X-Git-Url: http://git.cascardo.eti.br/?a=blobdiff_plain;f=SECURITY.md;h=08a6ed8b4f6541147ffb2b7e58a2b61a78a11227;hb=8b8ef592521e32d0e32581bf39c5d2a5cd445977;hp=f2695ea3c9526eb99db5ad84c9fd415e1774573e;hpb=48beaa8575378db40b41d0bafd90185b36368146;p=cascardo%2Fovs.git

diff --git a/SECURITY.md b/SECURITY.md
index f2695ea3c..08a6ed8b4 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.
+Vulnerabilities compromise one or more of:
+
+    * Confidentiality (personal or corporate confidential data).
+    * Integrity (trustworthiness 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
@@ -59,6 +67,9 @@ the report has been received.
 Please consider reporting the information mentioned in
 REPORTING-BUGS.md, where relevant.
 
+Reporters may ask for a GPG key while initiating contact with the
+security team to deliver more sensitive reports.
+
 The Linux kernel has its own vulnerability management process:
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/SecurityBugs
 Handling of vulnerabilities that affect both the Open vSwitch tree and
@@ -132,11 +143,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
@@ -144,11 +155,14 @@ they have already been reviewed and applied), post the security
 advisory to appropriate mailing lists (ovs-announce, ovs-discuss), and
 post the security advisory on the Open vSwitch webpage.
 
+When the patch is applied to LTS (long-term support) branches, a new
+version should be released.
+
 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: