多くの一般的なパッケージマネージャーは、侵害されたリポジトリが悪意のあるコードを注入することに対して十分に保護できていません。暗号化ハッシュと署名でこれを解決できますが、多くのパッケージマネージャーは脆弱なままです。テストされた25のマネージャーの半数未満が、デフォルトで改ざんをチェックするロックファイルを使用しており、ダウンロードされたすべてのパッケージの整合性を検証したのは2つだけでした。開発者の侵害が悪用しにくくなると、攻撃者はパッケージリポジトリを標的にする可能性が高いです。暗号化ソリューションは複雑であり、多くの実装は設計上の選択やリソースの制限により不十分です。検証のためにロックファイルに暗号化ハッシュを含めることは一般的なアプローチですが、その実装はパッケージマネージャーによって異なります。Goのようにデフォルトでパッケージの整合性を検証したのは数少ないマネージャーであり、他のマネージャーは追加の設定が必要であったり、統合的な検証が欠けていました。安全なハッシュ配布の必要性を回避する署名検証も、一貫性のない実装でした。Goはデフォルトで署名を検証した唯一のマネージャーであり、他のマネージャーは追加の設定が必要であったり、署名サポートが欠けていました。テストにより、暗号化設計とセキュリティレベルに大きなばらつきがあることが明らかになりました。Dockerとmitmproxyを使用したテストハーネスが開発され、悪意のあるリポジトリからの攻撃をシミュレートしました。このハーネスは、侵害されたサーバーに対してパッケージマネージャーのセキュリティを動的に評価しました。HTTPSはパッケージマネージャーによって広く使用されていますが、暗号化されていないHTTPを使用するcpanminusは注目すべき例外です。ハッシュ関数はファイルの整合性を確保することを目的としていますが、課題は正しいハッシュがパッケージマネージャーにどのように伝えられるかです。Vcpkgは、検証のためにソースコードに保存された事前計算されたコンテンツハッシュを使用します。ロックファイルは、パッケージマネージャーが正しいハッシュを学習するためのより一般的な方法です。Bun、npm、Cargoなどのパッケージマネージャーは、自動整合性チェックのためにハッシュを含むロックファイルを使用します。PipやCondaなどの一部のマネージャーは、実験的またはオプションのロックファイルサポートを提供していますが、MavenやComposerなどの他のマネージャーは専用のロックファイルを欠いています。驚くべきことに、一部のロックファイルには、Pubやpnpmのようにデフォルトで不一致が無視される可能性があり、侵害を防げないハッシュが含まれています。ConanとCocoaPodsは、暗号化整合性検証のためではなく、識別子としてハッシュを使用しています。