The Chrome OS security team maintains a security sheriff rotation to ensure that incoming security bugs are triaged promptly and fixed according to our security severity guidelines. Each sheriffing shift lasts a week, from Tuesday to Monday of the following week. You are not expected to sheriff during the weekend.
Open the spreadsheet at go/chromeos-security-bugs. Identify the cells that are red. This happens for bugs that don‘t have owners, that are not assigned to a component, or don’t have an Impact, Milestone, or Severity flag; or bugs that haven't seen an update in a while.
Attempt to reduce the amount of red in the spreadsheet. Find owners for un-owned bugs, assign proper components to bugs without components. Triage Impact, Milestone, and Severity for bugs. Make sure progress is happening on High+ severity bugs.
Consider ensuring that all bugs in the spreadsheet are assigned to a component. This contributes to Chrome OS wide efforts to organize open bugs. If no specific component is immediately obvious for the bug, Security can be a reasonable “landing” component. For third-party packages, OS>Packages can be a reasonable component, but prefer assigning bugs to functional componentes related to the team that owns the package. Most of these components will still live inside the larger OS component, so that can narrow the search.
If you see a bug reported in a third-party package, check the security-sensitive package list. If the package is in the list, make it a priority to update the package before your shift ends. You can often find newer versions of portage packages in upstream Gentoo. Do not worry if the version you need to resolve a security issue isn't marked stable. There are instructions for upgrading packages in the portage-stable mirror.
Sometimes a security bug might be in an unused feature of a third party package. If this is the case, you can often disable features during the configuration step (example).
When a full-chain exploit comes in, the current sheriff owns the issue for the lifetime of the chain. If more than one chain comes in a given sheriff week, the next sheriff owns the next chain, and so on and so forth. Refer to the security sheriff rotation to find the next sheriff.
When a full-chain exploit comes in, the objective is to break the chain: to fix enough bugs that the exploit as submitted no longer works.
The sheriff should handle a full-chain exploit by breaking the exploit down into its component bugs: each link in the chain should get a separate bug in crbug.com. This allows making faster progress on individual bugs and therefore breaking the chain faster and allowing easier merge of the fixes into release branches.
The exit criteria for a full-chain exploit are:
Once these two requirements are met, the main issue for the full-chain exploit can be marked as Fixed. Individual sub-bugs don't necessarily need to be closed before marking the main bug as fixed, as long as the exploit chain is successfully broken.