Outsourced Software Development Security Requirements for Google Partners

This guide is for third parties writing code specifically for or on behalf of Google and is to be used along with project specific requirements.

Summary

Requirements

  1. Host source code in your allocated project repository
  2. If you are developing a web application:
    • Follow the Google web application security requirements
    • Launch your site on AppEngine (note: the AppEngine Flexible Environment cannot be used at this point)
    • Use AppEngine Datastore; if this is not possible for technical reasons, check with Google security before using alternatives such as Cloud SQL
    • Write your application code in one of Python, Java, TypeScript, or Go, as directed by your outsourcing contact. Code developed in any language other than these will not be accepted under any circumstances.
    • Make sure the application is exclusively available over SSL
  3. Fix security bugs in a timely manner
  4. Have your product feature complete and available for test well before launch date
  5. If you use Google Analytics ensure no PII is captured and standards are followed
  6. Be very careful when handling PII

Recommendations

Security Requirements

Code developed for Google is expected to be secure and free of security vulnerabilities. Industry-standard guidelines for secure software development should be followed. If developing a web application, the application and all libraries and frameworks used must comply with Google's Web Application Security Requirements. This should include items described in the Defense in Depth section of the requirements.

Incident Response

If a security vulnerability is discovered in the application, a fix addressing the issue must be developed and deployed as quickly as possible. The severity and impact of the problem will determine exact timelines however it is expected that patches will be produced within 48 hours of notification. A fix is considered delivered once it is checked into the Google-provided code repository and a notification sent to the Googlers in charge of the project.

Standard Libraries

All open source and closed source libraries used by the project need to be approved by the Googler in charge of the project. Whenever possible use libraries hosted or provided by Google. We recommend using public Google APIs and frameworks such as Google Closure for javascript code, or Soy and AngularJS as templating frameworks rather than third party libraries or frameworks. If you use non-packaged or hosted libraries, check the non-minified code into the code repository, and ensure you have a process in place to deal with security patches and updates to the library.

Host the source code in a Google Git repository

All code developed for Google or used by the application must be checked into a Google-provided code repository. This is necessary for the security review process and will assist with triage or fixes in case of an incident. If you are not a GSuite customer you will need to pre-register your company email address here. To minimize the risk of credential theft it is required that you enable 2-step-verification on the accounts used for the project.

It is recommended to use the provided repository as the working repository, however at a minimum, the currently deployed version of the application must be checked in at any given time. Please do not dump the entire application source code in a single commit into the repository. Providing meaningful version history and commit messages can be incredibly helpful in the security review and speed things up significantly. This can be accomplished by treating the Google-provided repository as a separate remote origin and periodically push revisions.

The code in the repository should be self-sufficient and not have external dependencies. Building and deploying the code from the repository should be simple and well-documented.

Quality Code and Documentation

It is expected that any code developed for Google is high quality, well documented, tested and readable. If your project involves unmanaged platforms (such as Google Compute Engine instances) or deals with PII then we recommend that you submit a comprehensive design document, and ask for feedback early in the security review process.

Code should follow Google’s style guides, so the code is consistent with what is developed internally. Inline comments as well as class, variable and function names must be in English.

Google engineers must have their code reviewed by a second developer. It is strongly recommended that you follow the same guidelines and establish a process for code reviews.

Google expects that core functionality for applications include unit tests as a software engineering best practice. In particular, security relevant functionality (e.g. access control related functionality, input validation, escaping etc.) must include unit tests to ensure that they function as expected.

The unit tests should be in a separate file from the code under test to reduce clutter in the codebase.

Google uses a security scanner to find common vulnerabilities like XSS. The tool is currently in trusted tester mode, and we strongly encourage our partners to sign up and scan their applications. Once signed up as a trusted tester, our partners are free to scan their other Google AppEngine projects as well!

Prohibited Practices

Though we want to give as much flexibility as possible to developers, there are certain practices not in line with Google internal standards. Specifically, we cannot allow any outsourced development that uses one or more of the following.

  • Login pages within the application (all authentication should be handle via OAuth2 or Login with Google+)
  • A server-side language other than Python, Java, or Go. This prohibition includes, but is not limited to, the use of languages (e.g. Clojure, JRuby) that are in turn compiled to one of Google's canonical languages at a source or bytecode level
  • Applications using browser plugins such as Flash, Silverlight, Java, etc. (HTML5 is almost always a better choice)
  • Use of flash cookies, pseudo-cookies, unique browser fingerprinting or other techniques that circumvent browser privacy controls

Google Analytics

When using Google Analytics:

  • Do not capture personally identifiable information, including non-resettable mobile identifiers
  • Work with your Google contact to use the internal version of Google Analytics
  • Use of some Analytics features such as GA+DCLK (e.g. audience reporting, remarketing), userid overrides, and session stitching require additional review
  • Always anonymize IP addresses in Analytics

Personally identifiable Information (PII)

Google takes the protection of user data very seriously. Any application that stores or processes personal information must be reviewed by the Google security team and, potentially, the Google privacy team. Even something as simple as a name, email or user associated IP address may be considered PII and must be appropriately protected. For the purposes of designing security controls, data may be considered PII if it can be used to help identify an individual. When in doubt ask your main Google contact to check with the privacy team.

A simple rule of thumb is that unless you really need the data, do not collect or store it. If you must store PII please contact your Google liaison as there are pre-approved solutions such as Formbox which may be suitable.