Robert Sesek | e4d979b | 2022-07-11 23:22:14 | [diff] [blame] | 1 | # Life of a Security Issue |
| 2 | |
| 3 | This page will help you understand the life cycle of a manually-reported |
| 4 | external security bug in the Chromium project. Internally reported and |
| 5 | fuzzer-found bugs follow a similar lifecycle, though specific details vary. The |
| 6 | process can be visualized at a high level using the state diagram below, and |
| 7 | further explanation is provided in the paragraphs that follow. |
| 8 | |
| 9 |  |
| 10 | |
| 11 | <pre style="display:none" data-note="Source code for sequence diagram. Gitiles will not display this."> |
| 12 | <!-- |
| 13 | https://mermaid.live/edit#pako:eNqNU71uwjAQfpWTh070BTJUqgKd2goBYiEdLvZBLBw79Q9thHj3OpAgklCJJUpy39_d2UfGjSCWMEffgTSnqcSdxTLTmcfgjQ5lTrb5qtB6yWWF2sOCKmP9-P-SeLDS17Cii8RtcUoHUqY6s2Kp03h-eenRklYd8rBrcL3iGLyyMTD9B756JvDqnNzpFhihn8YTmAPZazeTG_QmNdoF5dFLo78ujGt5IBx8YSygFqCaR_oORkOJckQaRP9Au2_yADrI2Jv8JZGxi1W_j1Ej5Bxso2eOfN9kd8OAfUZakLU1VJLv78mPgq0Xc5ijJnUP203rOtEnqLAGSz9oxUOEdD17IMQ85Eq6IgorQkfRxnUAHVfnBqeoZ7Q5k7mqQUjHlXEUV8gmrCQb9yLicT9mGuLQfUElZSyJr4K2GBfebOAUoaES6GkmpDeWJVtUjiasuRHLWnOWeBuoA7VXpkWd_gADszf5 |
| 14 | --> |
| 15 | |
| 16 | sequenceDiagram |
| 17 | autonumber |
| 18 | participant Reporter |
| 19 | participant Security Team |
| 20 | participant Developer |
| 21 | |
| 22 | Reporter->>Security Team: Report bug |
| 23 | Security Team->>Security Team: Triage bug |
| 24 | Security Team->>Developer: Assign bug |
| 25 | |
| 26 | Note over Reporter,Developer: [Consultation] |
| 27 | |
| 28 | Developer->>Developer: Author and land CL on main |
| 29 | Developer->>Security Team: Mark bug as "Fixed" |
| 30 | |
| 31 | Security Team-->>Developer: Assess for backports |
| 32 | |
| 33 | Developer-->>Developer: Cherry pick |
| 34 | |
| 35 | Security Team->>Security Team: VRP Panel |
| 36 | Security Team->>Reporter: Assign & pay reward |
| 37 | Security Team->>Reporter: Assign CVE |
| 38 | Security Team->>Security Team: Publish release & security notes |
| 39 | |
| 40 | Reporter-->>Reporter: [Publicly disclose] |
| 41 | </pre> |
| 42 | |
| 43 | ## 1. Report bug |
| 44 | |
| 45 | A security bug begins when a reporter [responsibly |
| 46 | discloses](https://www.chromium.org/Home/chromium-security/reporting-security-bugs/) |
| 47 | a bug in the [Chromium issue |
| 48 | tracker](https://code.google.com/p/chromium/issues/entry?template=Security%20Bug). |
| 49 | The new bug is placed in a queue of other incoming security bugs, and it is |
| 50 | view-restricted to the reporter and select individuals on a need-to-know |
| 51 | basis. |
| 52 | |
| 53 | Bug reports that include specific steps to reproduce, analysis, proofs of |
| 54 | concept, and/or suggested patches are encouraged. Please also check the |
| 55 | [FAQ](faq.md) to learn about issues that are frequently reported. |
| 56 | |
| 57 | ## 2. Triage bug |
| 58 | |
Liza Burakova | f3d929b6 | 2023-05-01 16:31:12 | [diff] [blame^] | 59 | After the bug is filed, a [security shepherd](shepherd.md) will evaluate the |
| 60 | report. The shepherd does several tasks: |
Robert Sesek | e4d979b | 2022-07-11 23:22:14 | [diff] [blame] | 61 | |
| 62 | - Validate that the bug reproduces |
| 63 | - Searching for any duplicate reports |
| 64 | - Tag the bug with components |
| 65 | - Assess the bug's [severity](severity-guidelines.md) |
| 66 | - Determine the versions affected |
| 67 | - Assign the bug to a developer |
| 68 | |
| 69 | ## 3. Assign bug |
| 70 | |
Liza Burakova | f3d929b6 | 2023-05-01 16:31:12 | [diff] [blame^] | 71 | The primary job of the shepherd is to route valid and actionable reports of |
Robert Sesek | e4d979b | 2022-07-11 23:22:14 | [diff] [blame] | 72 | security bugs to the Chromium developer who is best poised to fix the issue. |
| 73 | |
| 74 | After the issue is assigned, there may be discussion between the developer(s) |
| 75 | involved, members of the security team, and the original reporter. |
| 76 | |
| 77 | ## 4. Author and land a CL on `main` |
| 78 | |
Grace Park | 4507763 | 2023-01-28 00:58:42 | [diff] [blame] | 79 | The developer will author a fix and a regression test for the security issue |
| 80 | The CL description should mention the bug number in a |
| 81 | [`Bug:` or `Fixed:` footer](../contributing.md#cl-footer-reference). |
Robert Sesek | e4d979b | 2022-07-11 23:22:14 | [diff] [blame] | 82 | Once the CL lands, it will not yet be widely available to users, since it is |
| 83 | only in the `main` branch. Unless further steps are taken (see below), the fix |
| 84 | will roll out as part of the normal [release |
| 85 | process](../process/release_cycle.md). |
| 86 | |
| 87 | Reporters are welcome to include a suggested patch in the report or to [upload a |
| 88 | CL](../contributing.md) with the fix. In that case, the developer assigned to |
| 89 | the bug can help code review and land it. |
| 90 | |
| 91 | ## 5. Mark bug as *Fixed* |
| 92 | |
| 93 | Once the CL has landed, the developer should set the bug's status to *Fixed*. |
| 94 | When the bug moves into the *Fixed* state, the security team's automation |
| 95 | systems begin processing the bug report. In particular, the tools will add |
| 96 | [merge request](../process/merge_request.md) labels, based on the severity and |
Liza Burakova | f3d929b6 | 2023-05-01 16:31:12 | [diff] [blame^] | 97 | impact assessed by the shepherd during triage. |
Robert Sesek | e4d979b | 2022-07-11 23:22:14 | [diff] [blame] | 98 | |
| 99 | ## 6. Assess for backports |
| 100 | |
| 101 | A member of the security team or a security technical program manager (TPM) will |
| 102 | make the [final |
| 103 | determination](https://www.chromium.org/Home/chromium-security/security-release-management/) |
| 104 | as to whether backports of the fix should occur to Stable and/or pre-Stable |
| 105 | Chrome release channels. |
| 106 | |
| 107 | ## 7. Cherry pick |
| 108 | |
| 109 | If approved for backporting, the developer will [cherry |
| 110 | pick](../process/merge_request.md#landing-an-approved-merge) the CL to the |
| 111 | release branches identified by the security TPM. |
| 112 | |
| 113 | ## 8. VRP Panel |
| 114 | |
| 115 | Members of the security team meet regularly as a panel to assess [vulnerability |
| 116 | rewards](vrp-faq.md) for externally reported security bugs. The individuals on |
| 117 | the panel will [take into account](https://g.co/chrome/vrp) the severity and |
| 118 | impact of the bug, the quality of the bug report, whether a patch/fix was |
| 119 | proposed with the report, and other mitigating circumstances. The VRP panel will |
| 120 | assign any reward amount for the bug. |
| 121 | |
| 122 | ## 9. Assign and pay reward |
| 123 | |
| 124 | After the VRP panel meets, the reporter will be notified of the VRP reward |
| 125 | decision through the bug report, and a label will be applied with the VRP reward |
| 126 | amount. |
| 127 | |
| 128 | ## 10. Assign CVE |
| 129 | |
| 130 | At the time that the security fix is shipped to a Stable channel release, a |
| 131 | security TPM will assign the issue a [CVE](https://www.cve.org/) number. CVE |
| 132 | numbers need to point to a publicly accessible artifact, and Chrome uses the |
| 133 | releases blog (see below) for this purpose. |
| 134 | |
| 135 | ## 11. Publish release & security notes |
| 136 | |
| 137 | The Chrome Release team releases an update of Chrome containing the security |
| 138 | fix. If the fix is included in a Stable channel release of Chrome, it will be |
| 139 | listed and acknowledged in the security fix notes on the [Chrome Releases |
| 140 | blog](https://googlechromereleases.blogspot.com/). Security issues will be |
| 141 | highlighted with a short description, any reward amount, the CVE number, and |
| 142 | acknowledging the reporter as requested (if they have consented to such). |
| 143 | |
| 144 | ## 12. Publicly disclose |
| 145 | |
| 146 | Except in rare circumstances where the bug report has been embargoed, 14 weeks |
| 147 | after the issue is marked *Fixed*, security automation opens the bug for public |
| 148 | disclosure. At that time, the reporter can consider their obligations under |
| 149 | responsible disclosure to be fulfilled. |