Get a Review

There are two types of reviews: an open source compliance review, which is mandatory; and a security review, if the code meets the requirements.

  1. Open source compliance review
  2. Language specific guidance
  3. Third-Party security review

Open source compliance review

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

  • //third_party/OWNERS
    • add third-party-*removed* to your CL’s reviewers field. An auto-assigner is used to assign someone from a third-party-*removed* group
    • see the instructions in the actual //third_party/OWNERS file
  • 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.

You should get a reply to your initial review within one business day.

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.

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.

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 uses VOMIT, a tool that automatically files bugs for popular //third_party packages when significant security advisories are released. These bugs are filed in under Security > Vomit > Google3 with all package custodial OWNERS copied on the bug. When this tool is extended to all of //third_party, this section will be updated. Until that time, all 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, ping emailremoved@ 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.

Except as otherwise noted, the content of this page is licensed under CC-BY-4.0 license. Third-party product names and logos may be the trademarks of their respective owners.