ドキュメントとトラッキングのプロジェクトであり、パッケージ管理システムをより安全にすることを目的としています。関連する問題の非常に大まかなリストについては、イシューを参照してください。
| 言語 | 名前 | 階層 | 管理策 | Packman リーダー | Packman ページ |
|---|---|---|---|---|---|
| JavaScript | npm | 1 | npm | ||
| Ruby | RubyGems | 1 | rubygems | ||
| Python | PyPi | 1 | pip/pypi | ||
| Java | Maven Central | 2 | maven central | ||
| Java | Android Central | ? | |||
| .Net | NuGet | 2 | nuget | ||
| Docker Hub | Docker | 1 | |||
| Golang | go get | 1 | golang | ||
| PHP | Composer | ? | |||
| Cocoa | Cocoa Pods | ? | |||
| Swift | Swift Package Manager | 1 | swiftpm | ||
| Rust | Cargo | 2? | rustcargo |
以下のセクションでは、上記の表で参照されている各管理策について詳しく説明します。
強力な認証とは、システムが以下を要求することを意味します：
新しいコードをパッケージマネージャーに公開できることは強力な機能であるため、メンテナのパスワードを推測するだけで簡単に実行できないことを確認することが重要です。MFAの実装
この要件を満たすには、パッケージマネージャーがコミュニティからセキュリティ情報を受け取る方法と、そのようなフィードバックを処理するためのプロセスを持っている必要があります。security@のような公開メールアドレスと、フィードバックを確実に受け取り応答する仕組みがあれば、この要件を満たします。
パッケージ自体が問題を特定したり、問題を通知されたりする場合があります。プラットフォームは、パッケージメンテナがセキュリティ問題のあるリリースを報告し、以下のことを行えるようにサポートすべきです：
パッケージは、よく知られたパブリックリポジトリ（bitbucket.org、github.com）内の明示的なコードバージョン（タグ？）に何らかの方法で紐付けられる必要があります。
パッケージが更新された場合、そのパッケージのすべてのメンテナに通知されるべきです。
パッケージにセキュリティ問題が特定された場合、コンシューマがそれらを確認する方法があるべきです。これは、コンシューマが既知の問題を確認できるコマンドである可能性があります。
開発者がコードに署名できるようにする必要があります。署名が行われた場合、パッケージマネージャーは署名を検証し、それをパッケージのコンシューマに配布する方法を提供すべきです。
パッケージマネージャーは、ダウンロードしたパッケージの整合性を検証する方法を提供します。
なし - 整合性検証は行われない 部分的 - 整合性検証が弱い方法で行われる* はい - 十分に安全な方法で検証が行われる
プラットフォームは、重要なライブラリの潜在的な問題を積極的に特定するための静的コード解析を提供できます。
プラットフォームは、パッケージが依存するライブラリ（上流パッケージ）の脆弱性を追跡し、該当する場合にメンテナに通知できます。
パッケージマネージャーは、パッケージインストール時にコードを実行すべきではありません。
パッケージマネージャーは、依存関係を使用しているプロジェクトに関する情報を収集すべきではありません。
パッケージ管理システムには、プロジェクトのロールに関するガイドが必要であり、それには継承計画と積極的な参加の条件を含めるべきです。
パッケージ管理システムのメンテナは、プロジェクトのロールをレビューしてメンテナがアクティブであることを確認するプロセスを持つべきです。
ライブラリのコンシューマは、特定のライブラリへの関心や承認にタグを付けることができるようにすべきです。これにより、ビルドが特定の方法でタグ付けされたライブラリのみを使用することを保証できます（例：コードレビュー済みとマーク）。
パッケージマネージャーは、認証資格情報/トークン/セッションがパッケージコンテンツの一部として漏洩するのを防ぐための何らかの制御を提供します。
なし - 制御はなく、ユーザー自身で保護する必要がある 部分的 - コメントを挿入 はい - 資格情報/トークンは公開がブロックされるか、パッケージの公開によってトリガーされる自動化された方法で取り消されます。ユーザーには、何らかのアクションが行われたことを通知されるべきです。
| 管理策 | Tier 1 | Tier 2 | Tier 3 |
|---|
| 強力な認証 | ☐ | ☑ | ☑ |
| アーティファクト公開のためのMFA | ☐ | ☑ | ☑ |
| セキュリティ連絡先 | ☐ | ☑ | ☑ |
| パッケージがセキュリティ問題を通知可能 | ☐ | ☑ | ☑ |
| コードパッケージをソースコードに紐付け | ☐ | ☑ | ☑ |
| 認証情報の公開防止 | ☐ | ☑ | ☑ |
| 更新通知 | ☐ | ☑ | ☑ |
| コード署名 | ☐ | ☐ | ☑ |
| 整合性検証 | ☐ | ☐ | ☑ |
| コード解析（静的） | ☐ | ☐ | ☑ |
| コード依存関係分析 | ☐ | ☐ | ☑ |
| パッケージマネージャーがコードを実行しない | ☐ | ☐ | ☑ |
| パッケージマネージャーが情報を収集しない | ☐ | ☐ | ☑ |
| プロジェクトロールガイド | ☐ | ☐ | ☑ |
| プロジェクトロールレビュー | ☐ | ☐ | ☑ |
| アカウントレベルのライブラリタグ付け | ☐ | ☐ | ☐ |
