Principles for Package Repository Security

Authors: Jack Cable (CISA), Zach Steindler

Last updated: Feb 2024


The Securing Software Repositories Working Group (WG) of the OpenSSF has identified a taxonomy of package repositories and a set of principles for their security capabilities. This is intended to offer a set of best practices that package repositories should strive to adhere to.

By package repository (sometimes also called package registry) we’re referring to the service that stores and indexes packages, enabling users and clients to download packages. Often users and clients use a CLI tool to download packages, and some ecosystems have multiple popular CLI tools in use. Most of these security capabilities focus on the package repository, but there’s also a section on security capabilities the CLI tooling can implement.

We include the below taxonomy because not all security advice applies to all package repositories. For example, https://proxy.golang.org/ does not manage user accounts, and so has no need of documented account recovery.

The roadmap of security capabilities can then be used by package repositories to assess gaps, put together fundable improvement lists (like Python Packaging WG), or write specific grant proposals that reference this guidance.

This is v0.1 of this document. You can give feedback for v0.2 at https://github.com/ossf/wg-securing-software-repos/pull/38.

Taxonomy of Package Repositories

Security capabilities will differ based on the services that the package repository offers. For instance, if the package repository has user accounts, it will need to enforce authentication securely. In this section, we lay out the various relevant aspects of package repositories.

Does the package repository …

… have user accounts?

… accept built packages, do builds on behalf of users, or only host source code?

Security Capabilities of Package Repositories

We define 4 levels of security maturity:

These levels are split into four tracks enumerated in the below sections: Authentication, Authorization, General Capabilities, and CLI Tooling. All tracks may not apply to all package repositories, as detailed above. Having these tracks allows package repositories to assess their security across various dimensions.


Applies to: package repositories that have user accounts.


Applies to: package repositories that have user accounts and accept built packages.

General Capabilities

Applies to: all package repositories

CLI Tooling

Applies to: all package management ecosystems, although here we are primarily focused on the CLI tooling instead of the registry itself.

Resources / Inspiration

Note: CISA does not endorse any commercial entity, product, company, or service, including any entities, products, or services linked within this document. Any reference to specific commercial entities, products, processes, or services by service mark, trademark, manufacturer, or otherwise, does not constitute or imply endorsement, recommendation, or favoring by CISA.