Security Sheriff

A Security Sheriff is a member of a rotation that occurs in 1-week time slots. (Here is the rotation schedule.) Each week as a primary and secondary sheriff, and during their rotation both have various important responsibilities:

Note: external emails will always come in on security@chromium.org as chrome-security@google.com is a google-only list, but both need to be triaged.

Ensure accurate label management on bugs, for example applying the correct Merge and Restrict-View labels when a bug transitions to Fixed.

Change bugs status to fixed for those that developer forgets to close. Make sure to read bug comments where developer might point out that it needs more cls, etc, and wait 24 hours before closing clusterfuzz bugs, to give clusterfuzz a chance to close it automatically.

Look at open security bug reports and check that progress is occurring.

Generally keep an eye on all bug traffic in case anything needs actioning or replying to.

Click here to get to the sheriff dashboard, which should display all the incoming bug reports that need to be addressed.

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 dashboard. If you're ever stuck or in doubt, ask for help on #chrome-security!

add the Security component or the Team-Security-UX label if the security team should still track the issue (e.g. security features).

If the report doesn't have enough information, ask the reporter for more information, add the Needs-Feedback label and wait for 24 hours for a response.

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 IRC (#chrome-security), or find an area owner to help.

Tips for reproducing bugs

https://clusterfuzz.com/v2/upload-testcase allows you to upload files to reproduce crashes on various platforms and will identify revision ranges when the regression was introduced. If a test case requires multiple files, they can be uploaded together in a zip or tar archive.

If you run into issues with a reproducible ClusterFuzz test case (like missing symbols, or if anything else seems off), try uploading the test case again using a different job type with a more mature tool (e.g. ASan on Linux). It may give more complete information.

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.

Bug chains are typically composed of several individual security bugs and should be split into a new bug for each potential fix required, so this allows each team to work on fixing their part of the chain. In cases like this, leave the main bug as the severity/priority of the full chain, and mark child bugs as being blockers of the parent bug each with their own separate severity. Each child bug can have its own priority. Examples of this in action are 352369 and 453937.

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

If the reporter wants to remain anonymous, add Restrict-View-SecurityEmbargo.

Mandatory labels to add:

Security_Severity-{Critical, High, Medium, Low}

Security_Impact-{Head, Beta, Stable, None} (Note: if a bug affects both the beta and stable channels, assign only the earliest label. Security_Impact-None applies to issues that to not impact chrome directly, or are disabled.)

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:

Try to determine the correct component before continuing on. It's not enough on its own, but it's a good starting point. Many components will automatically apply some CCs who may be able to help you out. If it's a crash bug, see if ClusterFuzz is able to provide one (will appear in the same card as the culprit CL).

For crashes, check to see if ClusterFuzz provides a culprit CL. Before you assign a bug based on this, do a quick sanity check to ensure the CL could have caused the bug. If the result seems wrong, apply the Test-Predator-Wrong label to the bug and keep going.

If you're able to narrow this to a specific regression range, usually from ClusterFuzz for crash bugs, do a quick pass over the git log to see if any CLs stand out. If you aren't sure, don't be afraid to add CCs to the bug and ask!

At this point, you'll probably need to dive in and attempt to root cause the bug, which is another complicated grey area that you'll figure out with experience. Try not to spend too much time for this on any given bug, as some cases will simply be too difficult without a deep understanding of certain portions of the codebase.

If you can narrow the bug to a specific file or block of code, or if something stands out as suspicious, try to assign an owner based on git blame or add some CCs based on OWNERS files

If not, consider searching in the issue tracker for people that fixed similar bugs or bugs in similar areas of the code base, such as issues with the same components, recently. For example, let's say you were trying to figure out a good person to assign a 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>today-30).

A few components have their own triage processes or points of contact who can help.

V8 bugs? Look for V8 rolls within the regression range, then look within the CLs of those rolls to find possible culprits. If you are unable to find the culprit CL, assign to the V8 ClusterFuzz Sheriff for triage. Note that V8 CHECK failure crashes can have security implications, so don't triage it yourself and instead assign it to V8 ClusterFuzz Sheriff. He or she can make an informed decision on whether it is a security vulnerability or not and whether it is safe to strip the security tags (Type=Bug-Security, Restrict-View-SecurityTeam).

Skia bugs? If you made it this far and still aren't sure, assign them to hcm@chromium.org. Be careful while triaging these! The place where we're crashing isn't necessarily the place where the bug was introduced, so blame may be misleading.

URL spoofing issues, especially related to RTL or IDNs? See go/url-spoofs for a guide to triaging these.

Make sure that the person you assign to handle a bug is not OOO. And, generally, explicitly CC more than 1 person on the bug, if possible, and preferably people from more than 1 geographic region. (See the OWNERS file(s) that affect(s) the relevant area of code.)

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.

Q: Why isn’t setting the component alone good enough?
A: CC’s are critical because just assigning to a component is ineffective because the Component’s team cannot see the issues unless they have the Security View permissions.

Using the Permission API Kill Switch.

If you find a vulnerability in a Permission API and need to use the Global Permissions Kill Switch, then follow the instructions here.

Wrap up the fixed issue.

Change Restrict-View-SecurityTeam to Restrict-View-SecurityNotify (so people on security-notify@chromium.org can get access to the bug).

For any Security_Severity-{Critical, High, Medium} bugs thatSecurity_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.

Chrome's Vulnerability Rewards ProgramTPM adds the reward-topanellabel by mass modification, but do label any bugs reported by a @chromium.org email that should be rewarded - e.g. "I'm filing this on behalf of" or the like.