0

[docs] Add note for use of SecurityEmbargo label in security sheriff

docs.

I saw a use of this tag during martinkr@'s sheriffing shift that I
didn't see referenced in the sheriffing documents, but which made good
sense to me and should probably be standard practice (adding this label
for potential malware samples).  Updating sheriffing docs accordingly.

Change-Id: Ia08ba9ffe41fe85d10e86a3a56764a413a3c4549
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4246662
Commit-Queue: Julia Hansbrough <flowerhack@google.com>
Reviewed-by: Martin Kreichgauer <martinkr@google.com>
Cr-Commit-Position: refs/heads/main@{#1105422}
This commit is contained in:
Julia Hansbrough
2023-02-15 01:20:15 +00:00
committed by Chromium LUCI CQ
parent aabb1aabb7
commit bdf785698c

@ -336,8 +336,10 @@ was filed using the Security template):
* **Restrict-View-SecurityTeam**
* **Type-Bug-Security**
* **If the reporter wants to remain anonymous or if the bug description or
comments contain PII**, add **Restrict-View-SecurityEmbargo**.
* If you want to prevent the bug from becoming unrestricted after it has been
closed, add **Restrict-View-SecurityEmbargo**. This should be done if the
reporter wishes to remain anonymous, if the description or comments contain
PII, or if the bug contains malware samples.
* **Security_Severity** - your responsibility as Sheriff.
* **FoundIn** - your responsibility as Sheriff.
* **reward_to** - if the bug was filed internally on behalf of somebody