This page will help you understand the life cycle of a manually-reported external security bug in the Chromium project. Internally reported and fuzzer-found bugs follow a similar lifecycle, though specific details vary. The process can be visualized at a high level using the state diagram below, and further explanation is provided in the paragraphs that follow.
A security bug begins when a reporter responsibly discloses a bug in the Chromium issue tracker. The new bug is placed in a queue of other incoming security bugs, and it is view-restricted to the reporter and select individuals on a need-to-know basis.
Bug reports that include specific steps to reproduce, analysis, proofs of concept, and/or suggested patches are encouraged. Please also check the FAQ to learn about issues that are frequently reported.
After the bug is filed, a security sheriff will evaluate the report. The sheriff does several tasks:
The primary job of the sheriff is to route valid and actionable reports of security bugs to the Chromium developer who is best poised to fix the issue.
After the issue is assigned, there may be discussion between the developer(s) involved, members of the security team, and the original reporter.
mainThe developer will author a fix and a regression test for the security issue The CL description should mention the bug number in a Bug: or Fixed: footer. Once the CL lands, it will not yet be widely available to users, since it is only in the main branch. Unless further steps are taken (see below), the fix will roll out as part of the normal release process.
Reporters are welcome to include a suggested patch in the report or to upload a CL with the fix. In that case, the developer assigned to the bug can help code review and land it.
Once the CL has landed, the developer should set the bug‘s status to Fixed. When the bug moves into the Fixed state, the security team’s automation systems begin processing the bug report. In particular, the tools will add merge request labels, based on the severity and impact assessed by the sheriff during triage.
A member of the security team or a security technical program manager (TPM) will make the final determination as to whether backports of the fix should occur to Stable and/or pre-Stable Chrome release channels.
If approved for backporting, the developer will cherry pick the CL to the release branches identified by the security TPM.
Members of the security team meet regularly as a panel to assess vulnerability rewards for externally reported security bugs. The individuals on the panel will take into account the severity and impact of the bug, the quality of the bug report, whether a patch/fix was proposed with the report, and other mitigating circumstances. The VRP panel will assign any reward amount for the bug.
After the VRP panel meets, the reporter will be notified of the VRP reward decision through the bug report, and a label will be applied with the VRP reward amount.
At the time that the security fix is shipped to a Stable channel release, a security TPM will assign the issue a CVE number. CVE numbers need to point to a publicly accessible artifact, and Chrome uses the releases blog (see below) for this purpose.
The Chrome Release team releases an update of Chrome containing the security fix. If the fix is included in a Stable channel release of Chrome, it will be listed and acknowledged in the security fix notes on the Chrome Releases blog. Security issues will be highlighted with a short description, any reward amount, the CVE number, and acknowledging the reporter as requested (if they have consented to such).
Except in rare circumstances where the bug report has been embargoed, 14 weeks after the issue is marked Fixed, security automation opens the bug for public disclosure. At that time, the reporter can consider their obligations under responsible disclosure to be fulfilled.