Bug database labels are used very heavily for security bugs. We rely on the labels being correct for a variety of reasons, including driving fixing efforts, driving release management efforts (merges and release notes) and also historical queries and data mining.
Because of the extent to which we rely on labels, it is an important part of the Security Sheriff duty to ensure that all security bugs are correctly tagged and managed. But even if you are not the Security Shepherd, please fix any labeling errors you happen upon.
Any issue that relates to security should have one of the following:
Security_Severity-{Critical (S0), High (S1), Medium (S2), Low(S3), Unknown / Not Yet Assessed (S4)}: Designates the severity of a vulnerability according to our severity guidelines.
Priority: P#: Priority should generally match Severity (but should be higher if there is evidence of active exploitation):
Found In: MMM#: Designates which milestones of Chrome are impacted by the bug. Multiple milestones may be set in the Found In field, but the most important one is the earliest affected milestone. See ChromiumDash for current releases.
Security_Impact-{Head, Beta, Stable, Extended, None} hotlists: Derived from milestones set in the Found In field,, this hotlist specifies the earliest affected release channel. Should not normally be set by humans, except in the case of Security_Impact-None (hotlistID: 5433277) which means that the bug is in a disabled feature, or otherwise doesn't impact Chrome: see the section below for more details.
Issue access level & collaborator groups{collaborators= security@chromium.org, collaborators=security-notify@chromium.org, Limited Visibility + Google, SecurityEmbargo hotlist}: settings that restrict access to the bug. Meaning and usage guidelines are as follows:
reward-{topanel, unpaid, na, inprocess, #} hotlists: Hotlists used for tracking bugs nominated for our Vulnerability Reward Program.
reward_to-external (hotlistID: 5432589): If a bug is filed by a Google or Chromium user on behalf of an external party, use reward_to-external to ensure the report is still properly credited to the external reporter in the release notes. IF, however, the reporter is an individual with an email address you should set the Reporter field to reflect the email address of the external reporter. If the reporter was an organization or entity with a specific email address, then do not alter the Reporter field and use the reward-to_external hotlist. Despite its name, you should add this label whether or not the reporter is in scope for the vulnerability rewards program, because external reports are credited in the release notes irrespective.
M-# field: Target milestone for the fix.
Chromium ‘Component Tags’: For bugs filed as Type=Vulnerability, we also want to track which Chromium component(s) the bug is in.
ReleaseBlock field = Stable: When we find a security bug regression that has not yet shipped to stable, we use this label to try and prevent the security regression from ever affecting users of the Stable channel.
OS-{Chrome, Linux, Windows, ...}: Denotes which operating systems are affected.
Merge: field{Request-?, Approved-?, Merged-?}: Security fixes are frequently merged to earlier release branches.
Security Release: #-M###: Denotes which exact patch a security fix made it into. This is more fine-grained than the M-# label. Release-0-M105 denotes the initial release of an M105 release to Stable channel.
CVE field: -####-####: For security bugs that get assigned a CVE, we update the CVE field for appropriate bug(s) with the CVE number for easy searching. Type=Vulnerability bugs should always have Severity of S0-S3, Found In - ### set, Security_Impact hotlist, OS, Priority, M, Component Tags, and an Assigner set.
Security_Impact-None says that the bug can‘t affect any users running the default configuration of Chrome. It’s most commonly used for cases where code is entirely disabled or absent in the production build.
Other cases where it's OK to set Security_Impact-None:
chrome://flags entry. (In particular, if a bug can only affect those who have set #enable-experimental-web-platform-features, it is Security_Impact-None.--future, --es-staging or --wasm-staging or other experimental flags that are disabled by default.Cases where it's not OK to set Security_Impact-None:
It‘s important to get this right, because this label influences how rapidly we merge and release the fix. Ask for help if you’re not sure.
Some Security_Impact-None bugs may still be subject to VRP rewards, if those bugs are found in code that we're likely to enable in the future.
It can be hard to know which OS(s) a bug applies to. Here are some guidelines:
foo_{win,linux,mac,...}.cc, it's specific to the named platform.foo.mm) is particular to macOS and iOS. (But note that most of our Objective-C++ is particular to macOS or iOS. You can usually tell by the pathname.)ui/message_center/views) is used on Windows, Linux, Chrome OS, and perhaps Fuchsia (?). Views for macOS is increasingly a thing, but Cocoa code (e.g. ui/message_center/cocoa) is particular to macOS.Once you've landed a complete fix for a security bug, please immediately mark the bug as Fixed. Do not request merges: Sheriffbot will request appropriate merges to beta or stable according to our guidelines. However, it is really helpful if you comment upon any unusual stability or compatibility risks of merging.
(Some Chromium teams traditionally deal with merges before marking bugs as Fixed. Please don't do that for security bugs.)
Please take the opportunity to consider whether there are any variants or related problems. It‘s very common for attackers to tweak working attack code to exploit a similar situation elsewhere. If you’ve even the remotest thought that there might be equivalent patterns or variants elsewhere, file a bug with type=Bug-Security. It can be nearly blank. The important thing is to record the fact that something may need doing.
Security labels guide the actions taken by Blintz. The source of truth for the actual rule set is go/chrome-blintz-source (sorry, Google employees only). The motivation behind these rules is to help automate the security bug life cycle so security shepherds and security engineers in general spend less time updating bugs and can do more useful work instead.
The following sections describe the current set of rules relevant to security bugs. The list below only describes rules that change the labels described above. There are additional rules for sending nag messages and janitorial tasks; check the Chrome blintz source for details.
Only bugs that affect stable should carry a release designator, this rule removes release designators that are set on bugs not affecting stable.
Each bug should be on exactly one Security_Impact-X and it should be one of the 5 valid Security_Impact hotlists (None, Extended, Stable, Beta, Head). This rule a bug from any invalid and excess Security_Impact hotlists.
Based on Found In # milestone set in the field this rule assigns corresponding Security_Impact-X hotlists if they are incorrect or absent. Security_Impact-None is never changed.
Bugs that are set with milestones earlier than the current milestone will be updated to set the field to the current milestone and Security_Impact-Extended.
Bugs that carry a Security_Impact-X hotlist but are missing a milestone field being set will be updated so that the M-# field reflects the corresponding to the respective milestone.
If there's a high or medium severity security regression in beta or ToT, update the ReleaseBlock field to Stable to prevent that regression from being shipped to users.
Similarly, critical security regressions are marked ReleaseBlock: Beta.
Adjust Priority P# according to the priority rules for severity labels described above. If there is evidence of active exploitation then a higher priority should be used.
Remove **security@chromium.org, security-notify@chromium.org and security-notify@webrtc.org from Collaborator Groups and Update Issue Access level to Default Visibility for security bugs that have been closed (Fixed, Verified, Duplicate, WontFix,Invalid) more than 14 weeks ago, making them publicly accessible. The idea here is that by 14 weeks, important security fixes will have shipped in a Stable channel update and allowing users time to update.
While Issue Access level remains Limited Visibility removes security@chromium.org as Collaborator field / Add Collaborator Groups and replaces updates with security-notify@chromium.org for fixed security bugs. Rationale is that while fixed bugs are generally not intended to become public immediately, we'd like to give access to external parties depending on Chromium via security-notify@chromium.org. (Collaborator for WebRTC bugs is instead updated to security-notify@webrtc.org).
Fixed security bugs that affect stable or beta and are critical or high severity will automatically trigger a merge request for the current beta branch, and perhaps stable if also impacted.
No need to stop a release if the bug doesn't have any consequences.
Given the importance and volume of field, hotlists, and visiblity settings, an example might be useful.