For 3rd party libraries that don't clearly meet the following guidelines, please start a discussion in the team chat room explaining your use case and how you’ve used the checklist. TLs can jump in and provide guidance based on the context and information you provide.

General Guidelines

Acceptable open source license

• Apache License 2.0 and MIT licenses are no-brainer
• Try to avoid other licenses. If you have to, refer to the Google third-party licenses guideline and seek input from your TLs.

Well-supported projects (signals)

• Sponsored by credible organizations (including Google), foundations, or individuals
• No critical vulnerabilities
• Non-trivial number of GH stars
• Active community, reasonable backlog (issues) size
• Recent commits and responsiveness on PRs

Minimal transitive dependencies

• Look at the entire dependency graph, not just the direct dependency
• Each dependency represents reliability and security risk

Embrace the standard library

• Most modern languages have a rich standard library
• Prefer built-ins and local helpers over an external dependency (no left-pad)

A tool to help you check - OSSF Scorecard

Install OSSF scorecard. It provides many checks beyond vulnerabilities but not every score weighs the same. The tentative priority order is:

License = Vulnerabilities > Code-Review = CI-Tests > Branch-Protection = Dangerous Workflow > > Maintained

Go Libraries

No framework

Go discourages frameworks (see some good reasons in this article), especially when such a framework requires a programming style or structure that's incompatible with Go standard library. E.g. Gin for HTTP serving. Usually, once you buy into such a framework, it's much harder to get rid of it later on.

Check vulnerabilities

Check vulnerabilities with https://pkg.go.dev/vuln/. Don't use libraries with critical vulnerabilities.

Java / Python

Check out https://cloud.google.com/assured-open-source-software?