npm Organization でパッケージを管理する際、developers チームの特性を理解しておくことが重要です。特に企業で運用する場合、IT 管理者と開発者を適切に分離しないと、パッケージの Collaborators に意図しないメンバーが表示されてしまいます。
npm 公式ドキュメント によると、developers チームには以下の特徴があります。
公式ドキュメント には以下のように明記されています。
Note: You cannot remove the developers team.
削除できない理由は以下の通りです。
企業で npm Organization を運用する場合、以下のような構成になることが多いでしょう。
@your-company (Organization)
├── IT 管理者（Organization Owner/Admin）
├── 開発チーム A（パッケージ A を開発）
├── 開発チーム B（パッケージ B を開発）
└── その他のメンバー（パッケージを利用するだけ）
このとき、developers チームの自動追加により以下の問題が発生します。
npm のパッケージページには Collaborators が表示されます。developers チームにパッケージへのアクセス権がある場合、Collaborators として「developers チーム」が表示され、結果として 実際の開発者が誰なのか分かりにくく なります。
パッケージの開発に関わっていない IT 管理者や、他のチームのメンバーも developers チームに含まれているため、責任の所在が不明確になってしまいます。
この問題を解決するには、publish 用のチームを別途作成 し、developers チームからパッケージへのアクセス権を削除します。
対象パッケージに対する developers チームの権限を read-only に変更します。
# CLI でパッケージ単位で権限を変更
npm access grant read-only @your-company:developers @your-company/your-package※ この操作はパッケージ単位での設定です。Organization 全体のデフォルト設定は Web UI から行います。
パッケージごと、またはプロジェクトごとに publish 用のチームを作成します。
# チームの作成
npm team create @your-company:package-a-publishers
# メンバーの追加
npm team add @your-company:package-a-publishers developer1
npm team add @your-company:package-a-publishers developer2npm access grant read-write @your-company:package-a-publishers @your-company/package-a手順 1 で read-only に変更している場合、この手順は不要です。
完全にアクセス権を削除する場合は以下のコマンドを使用しますが、private package の場合は注意が必要です。
npm access revoke @your-company:developers @your-company/package-a※ private package で developers から権限を完全に revoke すると、developers チームのメンバーは パッケージのインストールすらできなくなります。多くの場合、revoke ではなく read-only を維持する運用が安全です。
新しいパッケージを npm publish すると、デフォルトで developers チームに書き込み権限が付与 されます。そのため、新規パッケージを作成するたびに上記の手順 1〜3 を実行する必要があります。
CI/CD パイプラインに組み込むか、パッケージ作成時のチェックリストに含めておくと、対応漏れを防げます。
以下のようなチーム構成を推奨します。
@your-company (Organization)
├── developers（デフォルト、全メンバー、read-only）
├── package-a-publishers（パッケージ A の開発者のみ）
├── package-b-publishers（パッケージ B の開発者のみ）
└── admins（IT 管理者、Organization 管理用）
この構成により以下が実現できます。
この運用方法は、セキュリティの基本原則である「最小権限の原則」に基づいています。OWASP の npm Security Cheat Sheet でも、サプライチェーン保護のベストプラクティスとして以下のように推奨されています。
Restrict, scope and rotate CI and publisher tokens. Bind publisher tokens to workflows or IP ranges and minimize privileges.
GitHub Actions や GitLab CI/CD と連携する場合は、Trusted Publishing の利用も検討してください。長寿命のトークンを使用せず、CI/CD ワークフローから直接 publish できます。
企業では GitHub Organization と npm Organization を SSO で連携させているケースが多いです。この場合、GitHub 上のチーム構造を npm に同期できる機能があります。
GitHub 連携を使用している場合は、GitHub 側でチームを管理し、npm 側に自動同期させることで、チーム管理の手間を削減できます。ただし、developers チームの挙動は変わらないため、本記事で説明した権限の分離は引き続き必要です。
GitHub Packages でも同様の権限管理が可能です。
Organizations can disable automatic inheritance of access permissions for all new packages scoped to their organization.
リポジトリの権限を自動継承するか、パッケージごとに個別設定するかを選択できます。
npm Organization の developers チームは便利な機能ですが、企業運用では以下の点に注意が必要です。
解決策として、publish 用のチームを別途作成 し、developers チームのアクセス権を read-only に制限することで、パッケージの Collaborators に実際の開発メンバーだけを表示できます。
この運用方法は最小権限の原則に則っており、セキュリティ面でも推奨されるアプローチです。
以上、npm Organization の developers チームと publish チームの分離について調査した、現場からお送りしました。