Using higher priority for actively exploited bugs.

This change notes that, for bugs being actively exploited in the wild,
we should use a higher priority such that they are fixed and merged as
rapidly as possible.

The change deliberately does not specify the priority to use in this
case, as this should be an extremely rare event and be subject to
extensive discussion. However, it does go so far as to say we 'should'
use a higher priority, which for a medium or high bug typically means it
would end up being Pri-0. That seems like it would typically, but not
always, be the right thing to do, so it feels like it gives the right
guidance.

Change-Id: Ied0ad4c9ab61425b748f4e8c78e7ea0a46bb060e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1841509
Commit-Queue: Adrian Taylor <adetaylor@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Cr-Commit-Position: refs/heads/master@{#703315}

docs/security/security-labels.md

@@ -25,7 +25,8 @@ that.)
 * **Security_Severity-**{**Critical**, **High**, **Medium**, **Low**,
 **None**}: Designates the severity of a vulnerability according to our
 [severity guidelines](severity-guidelines.md).
-* **Pri-#**: Priority should generally match Severity:
+* **Pri-#**: Priority should generally match Severity (but should be higher if
+  there is evidence of active exploitation):
   * **Security_Severity-Critical**: **Pri-0**.
   * **High** and **Medium**: **Pri-1**.
   * **Low**: **Pri-2**.
@@ -175,7 +176,8 @@ Similarly, critical security regressions are marked **ReleaseBlock-Beta**.
 ### Adjust **Pri-#** To Match Severity
 
 Adjust **Pri-#** according to the priority rules for severity labels described
-above.
+above. If there is evidence of active exploitation then a higher priority should
+be used.
 
 ### Drop **Restrict-View-{SecurityTeam,SecurityNotify}** From Old And Fixed Bugs