Chromium‎ > ‎Chromium Security‎ > ‎

Security Sheriff

What's a security sheriff?

A Security Sheriff is a member of a rotation that occurs in 1-week time slots. During their 1-week time slot, the sheriff has various important responsibilities:

  • Look at every incoming security bug report and ensure it is accurately triaged, and actively progressing towards getting fixed.
  • Look at open security bug reports and check that progress is occurring.
  • Ensure that all incoming queries to the and the get a reply (by someone; not necessarily the sheriff themselves).
  • Ensure accurate label management on bugs, for example applying the correct Merge and Restrict-View labels when a bug transitions to Fixed.
  • Generally keep an eye on all bug traffic in case anything needs actioning or replying to.
  • Stay sharp, keep in shape (hand-stand pushups are standard), and remember you may be called upon during emergencies.

I'm the security sheriff, what do I do?

Do as much as you can for the week to triage, shepherd, and wrap up open security bugs. What follows are the details of what that entails, but it practically means whacking out all the items from the burn down list (prioritized from top to bottom) in our security dashboardIf you're ever stuck or in doubt, ask for help on #chrome-security! 

Diagnose the issue.

  • If the report is invalid, then remove the Restrict-View-SecurityTeam label and mark it WontFix.
  • If the report is a duplicate, mark it Duplicate, and if the issue this is a duplicate of is public, remove the Restrict-View-SecurityTeam label.
  • If the report is primarily a privacy issue, then send it to the privacy team:
    • add the Cr-Privacy label so that it enters their triage queue
    • cc any security team members, including yourself, who may be interested in the privacy issue
    • change the Restrict-View-SecurityTeam label to Restrict-View-ChromePrivacy
      • Note that security team members don't automatically have privacy bug access, so this will probably make the issue inaccessible to you.
  • If the report is asking about why something is or is not on the Safe Browsing list:
    • assign it to zbutler@, who will triage it for the Safe Browsing team
    • remove the Restrict-View-SecurityTeam label and add the Restrict-View-Google label 
    • change Type-Bug-Security label to Type-Bug
    • add the Cr-Security label
  • If the report is a potentially valid bug but is not a security vulnerability, then:
    • remove the Restrict-View-SecurityTeam label
    • change Type-Bug-Security label to Type-Bug (or whatever Type is appropriate)
    • add the Security_Severity-None label to indicate the bug was already reviewed by the Security Team
    • add appropriate Cr-* labels or CCs to ensure it does get triaged
    • add the Cr-Security or Cr-Security-UX label if the security team should still track the issue (e.g. security features).
  • If the report smells like a vulnerability, keep going.

Verify (and label!) the bug.

Step 1. Reproduce legitimate sounding issues.

If you can't reproduce the issue, ask for help on #chrome-security, or find an area owner to help.

Tips for reproducing bugs
Step 2. Assess the severity.
Severity guidelines are here. If it's a critical vulnerability, act quick! We aim to get users patched in < 30 days. Remember that if something requires an unusual configuration or complicated user interaction, the severity rating should be lowered.

Much of Chrome's development and release process depends on bugs having the right labels. Labels are important! Check out all the security-specific labels we use to track bugs here.

Labels to double check (that should already be there if the bug was filed using the Security template):
  • Restrict-View-SecurityTeam
  • Type-Bug-Security
Mandatory labels to add:
  1. Security_Severity-{Critical, High, Medium, Low} (Note: Security_Severity-None is not valid for legitimate security vulnerabilities.)
  2. Security_Impact-{Head, Beta, Stable, None} (Note: if a bug affects both the beta and stable channels, assign only the earliest label.)
  3. Pri-{0, 1, 2, 3}
  4. OS-{All, Android, Chrome, Linux, Mac, Windows}
  5. M-{<milestone>} (Check the severity guidelines for which milestones to apply, and OmahaProxy for current milestones.)
  6. Cr-* (Helpful for making sure we have the right owner and ccs on a bug.)
And then add the general bug labels too (described here):
  • Update the bug status: Untriaged, Available, Assigned, or Started (as appropriate).
  • Apply the following labels as needed: OS-*, Internals-*Crash.
    • If it involves the user, mark it as Cr-Security-UX so that the Enamel team can track it. Example topics are: spoofing, phishing, permissions.
  • Any changes that will be merged to the beta branch must be labeled as ReleaseBlock-Stable.
  • Ensure the comment adequately explains any status changes; severity, milestone, and priority assignment generally require explanatory text.

Some initial follow-up or hand-off may be required
  • Report suspected malicious URLs to SafeBrowsing.
  • Report suspected malicious file attachments to SafeBrowsing and VirusTotal.
  • Make sure the report is properly forwarded when the vulnerability is in an upstream project, the OS, or some other dependency.
  • For vulnerabilities in services Chrome uses (e.g. Omaha, Chrome Web Store, SafeBrowsing), make sure the affected team is informed and has access to the necessary bugs.

Find an owner to fix the bug.

That owner can be you! Otherwise, this is one of the more grey areas of sheriffing. With experience, you'll figure out good goto people for certain areas. Until then, here are tips:
  • If you can narrow the bug to a specific file, use git blame
  • Search in the issue tracker for people that fixed similar bugs or bugs in similar areas of the code base (Cr-*) recently. For example, let's say you were trying to figure out a good person to assign an Cr=Content-Fonts issue. Look for "status=fixed, verified" and query by when the issues were closed after (i.e. w/ in the last 30 days == closed-after:today-30). Alternatively, if you go to, on the "Current Mstone" tab you have a view of all the work open by Mstone label.  When you click on a white area in a row, the details panel on the bottom will tell you the folks who have recently fixed issues w/ those labels (along w/ Pri and assigned/unassigned distributions).
  • If you can identify source code files associated with the bug, names in the OWNERS file can provide a good starting point.
  • Ask on #chrome-security for help
Sometimes, finding an owner isn't enough to ensure that a bug will get fixed. Check the stale bug list on the security dashboard and try resolve some of the problems that might be blocking these issues. If you get in touch with a bug owner off of the issue tracker, be sure to have them update the bug so that future sheriffs are aware of the status.

Wrap up the fixed issue.

  1. Change Restrict-View-SecurityTeam to Restrict-View-SecurityNotify (so people on can get access to the bug).
  2. For any Security_Severity-{Critical, High, Medium} bugs that Security_Impact-{Beta, Stable}, add Merge-Requested so that the fix gets merged into the next release. Exercise discretion according to security severity and risk associated with the bug fix; you can ask the patch author whether any risky code paths are affected. The actual merging and drafting of release notes is taken care of by the security release management role.
  3. If you think a bug should be considered in our vulnerability rewards program, add reward-topanel.