docs/security/security-issue-guide-for-devs.md
If you have just been assigned a security bug, don’t panic! Security bugs are a fact of life in Chromium, and the project has a team of people and robust processes to help analyze and get security issues fixed. This document is meant to help Chromium developers handle their first (few) security bug(s). You may also want to review the Life of a Security Issue to understand how you as a developer fit into the larger security bug life cycle.
Chromium has public commitments to fix security issues within certain timeframes. Please treat security issues as high-priority interrupts to your work, especially if they are High Severity (S1) (P1) or Critical Severity (S0) (P0). 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!
Incoming security bugs are analyzed and triaged by a robot (the Chrome Security Sheepdog) based on OWNERS, recent commits and OOO status when available. Your first responsibility is to ensure you are the right assignee, or if the issue should properly be handled by someone else. Please quickly take a look at the issue and make this determination. If you are the wrong person, please CC folks that should be involved, and assign to one of them if the code and stacks on the bug point towards a better owner.
Try not to simply unassign yourself as this will produce work for another human, but if you have no idea (or are leaving the project) you can unassign yourself and the bug will enter the shepherd’s queue. Remember that people cannot see security issues unless they are CC'd in. (Feel free to CC people in!)
Critical, High and Medium severity security issues must be assigned to someone, this is Chromium policy, so if you feel you are the wrong assignee try not to simply remove yourself, instead work to find an alternative assignee.
Some bugs involve discussion with the reporter and/or members of the security team. For example, the issue may be in a feature or system that the shepherd is not well-equipped to reproduce, and they may ask you for help in determining if 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 issue tracker, as much as you need in order to identify and fix the issue.
Please do not adjust any of the security metadata 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.
This is the normal part of the job! Write a fix and a regression test, upload the CL, and get it reviewed by the appropriate code owner. The shepherd who assigned you the bug does not need to be included on the CL. Once the CL has landed, please immediately mark the bug as Fixed. That status change will kick off the security team’s automation to ensure the fix is released to users in a timely fashion.
A word on CL descriptions: Do not hide or obscure the fact that the CL is fixing a security bug; it is okay to mention that the CL fixes a use-after-free. However, the best CL description isn’t “[component] Fix uaf” – it is better to describe what lifetimes are being corrected, as well as the faulty underlying assumption that led to the bug. As an example, this CL fixes a use-after-free and describes the lifetime issue and change.
After the bug has been marked Fixed, automation (or a member of the security team) will request merge to the applicable release branches using child bugs of the initial issue. Please respond to these quickly and merge to release branches to ensure that fixes reach people using Chrome as fast as possible.
After the reported bug has been fixed and possibly merged, consider if the same bug may exist in other places. For example:
base::Unretained in an unsafe manner,
check the surrounding code for other usages that may be unsafe.DCHECK to an early return or CHECK, look for
similar incorrect DCHECKs.Do:
Don’t: