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 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. The Chrome Vulnerability Rewards Program (VRP) policies page has information about the expected characteristics of baseline and high-quality security bug reports. Please also check the FAQ to learn about issues that are frequently reported.
After the bug is filed, a security shepherd will evaluate the report. The shepherd does several tasks:
The primary job of the shepherd 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. The CL description should be as complete as possible and does not need to hide that the CL fixes a security issue. In general the CL should include a regression test - in limited cases where the issue can easily be triggered from a JavaScript sample the test can be landed later.
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 update merge request the Merge fields with the appropriate merge request tags, based on the severity and impact assessed by the shepherd during triage.
VRP reports also are updated with the reward-topanel hotlist by the automation. This allows the report to be included in the VRP Panel queue for evaluation and consideration of a potential VRP reward at a future VRP Panel session.
The appropriate members of the security team 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 team member who approved the merge.
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 the vrp-reward field will be updated to reflect the VRP reward amount.
Payments are not handled by the security team. A member of the Google finance team working on VRP payments (p2p-vrp) will reach out to arrange payment. The reporter must first be enrolled in a payment system Google uses to issue payments. The p2p-vrp team will assist the reporter in the enrollment process. Once the reporter is enrolled, all potential future VRP payments will be processed automatically without any action required by the reporter.
At the time that the security fix is shipped to a Stable channel release, a security team member 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, a 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 coordinated disclosure to be fulfilled.