Get a Review

Third-party code may require several different kinds of review:

We use go/gwsq to automatically assign reviewers, and sometimes it has false positives..

Open Source Compliance Review

IMPORTANT: Reviews should be 1 CL per Package. (Exception: If multiple package upgrades require synchronization, they can be bundled into a single CL.)

The initial submission of third-party code requires reviews from:

  • //third_party/OWNERS
    • third-party-*removed* should be automatically added to your CL's reviewers field. go/gwsq is used to auto-assign someone from the third-party-*removed* group
  • Language-specific owners
    • some languages require language-specific reviewers (listed in //third_party/<language>/OWNERS). These reviewers will be automatically assigned when the CL is mailed out.
  • At least one other member of the package's OWNERS file.
    • this serves as a check for things that the third-party or language-specific OWNERS might not catch, and that at least one other person in the OWNERS file acknowledges that they are responsible for the package.

You should receive a reply to your initial review request within two business days. (Reviewers are global, so depending on time zones and local holidays, sometimes it might take slightly longer.) If you do not receive a review in a timely manner, please contact emailremoved@.

Subsequent changes don't require third-party-removed approval. You can modify the code as much as you want.

NOTE: If your CL needs a third-party review but the auto-assigner doesn't make an assignment, you can add emailremoved@ to the CL's reviewers field to force an assignment.

When to Escalate for LICENSE Review

If an unrecognized license text is present, i.e., a commercial license, an unrecognized variation of an open source license or a public domain dedication, then the third party reviewer will add 'license-escalation' to your CL's reviewers field to review the license and determine whether it can be checked in.

license-escalation reviews CLs Monday through Thursday, and aims for a two business day turnaround. If you need to contact them, please email emailremoved@.

IMPORTANT: Do not remove license-escalation from a review once it has been added. It may only be removed by the license-escalation reviewer or the third-party-owner who initially added it.

Third-party security review


Third-party code is a hot spot for security vulnerabilities. It's important that you keep your third-party code up to date and patch security vulnerabilities when they are announced.

In general, you do not need to explicitly request a review. Google's security team is monitoring new packages in //third_party via our third party package tracker.

When new packages are checked in, automation will reach out to you and other OWNERS for any necessary information to start the consultation process.

The security team has documented a set of suggested best practices at their team page, which cover recommendations around BUILD visibility, update cadence, sandboxing/fuzzing, and more.

OWNERS are responsible for monitoring and addressing security vulnerabilities

NOTE: Package custodial OWNERS are responsible for keeping their code up to date and free of known security bugs.

When you submit or update your code, be mindful of security-related mailing lists for the project and relevant vulnerabilities to update your package. To assist with this process, the security team operate a number of tools your package can integrate with to receive vulnerability monitoring.

For packages that the tools do not support, package custodial OWNERS must make efforts to ensure that they are aware of new versions or releases of the //third_party code they are responsible for.

Getting a security review

When adding a new package, or using a package from //third_party, that could be used to process user content or otherwise carries any security risk, reach out to the security team with some information about what the package does, what kind of data it will be processing, and what environments you plan to run it in. If it's a part of a more complex project, file a ticket at go/securityreview for the entire thing so that the security team can review the implications. This happens asynchronously, so it typically won't delay your launch. If security team has any concerns, you may be asked to add a security section to the METADATA file, provide a secure interface, or limit build visibility.


We allow cryptocurrency libraries in //third_party, but you must import them and incorporate them in Google products in accordance with go/bitcoin-policy.

gwsq false positives

The go/gwsq configuration may sometimes assign a reviewer when one isn't necessary. We prefer this overtriggering because we'd rather catch problems before they get checked in.

If you are sure that a CL has been assigned a third-party or language specific reviewer and it doesn't need one, you may remove that reviewer from the R= and WANT_LGTM=.

If you're not sure, leave the reviewers there. Third-party reviewers are very good at determining if a review is necessary or not, and will remove themselves quickly if they find such cases.

If you have a suggestion for how to improve our assignment heuristics, or found a case that's totally wrong, you can file a bug.