Update Chrome Security docs to reflect the new issue tracker behavior
Change-Id: Iaeb797d925b18a1bda8c815420d0987f090ea1bc Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5262658 Reviewed-by: Alex Gough <ajgo@chromium.org> Commit-Queue: Grace Park <pgrace@chromium.org> Reviewed-by: Brendon Tiszka <tiszka@chromium.org> Cr-Commit-Position: refs/heads/main@{#1255863}
This commit is contained in:
Grace Park
committed by
Chromium LUCI CQ
Chromium LUCI CQ
parent
6c1b5cfadd
commit
e65d317468
docs/security
@ -10,8 +10,8 @@ cycle.
|
||||
|
||||
Chromium has [public commitments](severity-guidelines.md) to fix security issues
|
||||
within certain timeframes. Please treat security issues as high-priority
|
||||
interrupts to your work, especially if they are **Severity-High** or
|
||||
**Severity-Critical**. However, the expectation is that you handle security
|
||||
interrupts to your work, especially if they are **High Severity (S1)** or
|
||||
**Critical Severity (S0)**. However, the expectation is that you handle security
|
||||
issues within your normal working hours, not after-hours, weeknights, or on
|
||||
vacation. Everyone shares the responsibility of keeping our users safe!
|
||||
|
||||
@ -28,8 +28,10 @@ shepherd assigned you the bug because either:
|
||||
|
||||
In either case, if you are not the correct owner, please suggest a more
|
||||
appropriate person and re-assign it to that person. Or, if you do not know the
|
||||
correct owner, set the bug’s status back to **Untriaged**, so that it reenters
|
||||
the shepherd’s queue.
|
||||
correct owner, remove yourself from the Assignee field so that the bug
|
||||
re-enters the shepherd’s queue. Setting a component alone will not grant view
|
||||
access or alert the component owners, so the shepherd's queue is the best
|
||||
way to ensure the bug is properly triaged.
|
||||
|
||||
In the case where the shepherd is asking you technical questions, they will
|
||||
further triage the bug after considering your responses.
|
||||
@ -47,14 +49,14 @@ the bug is valid. The shepherd may also try to determine if the bug is mitigated
|
||||
meaning that the security impact is smaller or greater than described by the
|
||||
reporter. As the developer, you may have questions about certain preconditions
|
||||
assumed by the reporter. We encourage you to interact with the reporter and the
|
||||
shepherd, directly in the bug tracker, as much as you need in order to identify
|
||||
shepherd, directly in the issue tracker, as much as you need in order to identify
|
||||
and fix the issue.
|
||||
|
||||
Please do _not_ adjust any of the [security labels](security-labels.md) on the
|
||||
bug (namely **Security\_Severity** and **Security\_Impact**). If you think a bug
|
||||
is not a security issue or its severity should be downgraded, discuss it with
|
||||
the security team and let them adjust the labels. However, you can adjust the
|
||||
**FoundIn** label if you know the versions a bug affects.
|
||||
Please do _not_ adjust any of the [security metadata](security-labels.md) on the
|
||||
bug (namely the **Severity** field and **Security\_Impact** hotlists). If you think a
|
||||
bug is not a security issue or its severity should be downgraded, discuss it with
|
||||
the security team and let them adjust the metadata. However, you can adjust the
|
||||
**Found In** field if you know the versions a bug affects.
|
||||
|
||||
## 3. Fix the bug
|
||||
|
||||
@ -81,7 +83,8 @@ team) will request merge to the applicable release branches. Once the merge
|
||||
questionnaire is posted to the bug, please respond to the questions.
|
||||
|
||||
If the merge is approved, it is your responsibility to merge the CL to the
|
||||
approved branches.
|
||||
approved branches. The merge approval will show up as the 'Merge' custom field as
|
||||
"Approved-<Milestone>".
|
||||
|
||||
## 5. Think about patterns
|
||||
|
||||
@ -110,5 +113,5 @@ bug may exist in other places. For example:
|
||||
|
||||
* Panic
|
||||
* Communicate with the reporter about the issue outside of the bug tracker
|
||||
* Adjust the [security labels](security-labels.md) like **Security\_Severity**
|
||||
or **Security\_Impact**
|
||||
* Adjust the [security labels](security-labels.md) like the **Severity** field
|
||||
or **Security\_Impact** hotlists.
|
||||
|
||||
@ -11,7 +11,7 @@ included in the update.
|
||||
|
||||
## Chrome Updates
|
||||
|
||||
Almost all updates have security fixes. Every two weeks, Chrome releases a new
|
||||
Almost all updates have security fixes. Every week, Chrome releases a new
|
||||
version that materially improves security. The Chrome Security team believes the
|
||||
best option for security is to apply all updates to Chrome as soon as they are
|
||||
available. We recommend against and do not support using the security release
|
||||
@ -28,8 +28,8 @@ Security team.
|
||||
|
||||
Chrome releases [stable milestones][release-cycle] every four weeks (MXXX), with “refresh”
|
||||
releases in-between milestones. Milestones are refreshed with updates that can
|
||||
contain security fixes and functional bug fixes for high-impact bugs. There is a
|
||||
planned security refresh update two weeks into every milestone, with all of the
|
||||
contain security fixes and functional bug fixes for high-impact bugs. There are
|
||||
planned security refreshes weekly for every milestone, with all of the
|
||||
security fixes since the previous release. Chrome may have unscheduled updates
|
||||
between milestones to fix critical security issues, address breaking functional
|
||||
bugs, or patch known in-the-wild exploits. Updates and rapid response are part
|
||||
@ -54,8 +54,8 @@ of users running the Beta version of Chrome.
|
||||
|
||||
You can read more details and best practices on the [Chrome Update Management
|
||||
Strategies][update-strategy] technical doc. Enterprises can also reach out to their [support
|
||||
representatives][ent-support] for help, or [file an issue][crbug] if they identify a bug in a new
|
||||
version of Chrome.
|
||||
representatives][ent-support] for help, or [file an issue][issue-tracker] if they identify a
|
||||
bug in a new version of Chrome.
|
||||
|
||||
**How do I prioritize updates that patch vulnerabilities known to be under
|
||||
exploitation in the wild (zero-days)?** Don't---this strategy puts you at risk.
|
||||
@ -88,7 +88,7 @@ We've spent years building advanced release infrastructure in order to increase
|
||||
the number of security updates you receive, and the frequency that we can send
|
||||
them out. This keeps you a step ahead of bad actors.
|
||||
|
||||
**Updating every two weeks (or more) is a lot of work. How can my IT department
|
||||
**Updating every week (or more) is a lot of work. How can my IT department
|
||||
keep up?** Chrome is designed to be easy for IT admins to manage and update. If
|
||||
you're finding that it's a lot of work to keep up with Chrome's update schedule,
|
||||
there's a good chance that there's an easier way to accomplish your goals.
|
||||
@ -122,7 +122,7 @@ notes for the corresponding desktop release.
|
||||
[ent-rel-notes]: https://support.google.com/chrome/a/answer/7679408
|
||||
[update-strategy]: https://support.google.com/chrome/a/answer/9982578
|
||||
[ent-support]: https://chromeenterprise.google/browser/support/
|
||||
[crbug]: https://crbug.com
|
||||
[issue-tracker]: https://issues.chromium.org
|
||||
[cisa-patches]: https://www.cisa.gov/tips/st04-006
|
||||
[chrome-versions]: https://www.chromium.org/developers/version-numbers/
|
||||
[rel-dash]: https://chromiumdash.appspot.com/releases?platform=Windows
|
||||
|
||||
Reference in New Issue
Block a user