package-lock.jsonファイルについて次のことを読みました。
このファイルは、ソース リポジトリにコミットすることを目的としており、さまざまな目的に使用されます。
- チームメイト、デプロイ、および継続的インテグレーションがまったく同じ依存関係をインストールすることが保証されるように、依存関係ツリーの単一の表現を記述します。
- ディレクトリ自体をコミットすることなく、ユーザーが node_modules の以前の状態に「タイムトラベル」できる機能を提供します。
- 読み取り可能なソース管理の差分により、ツリーの変更をよりわかりやすくするため。
- また、npm が以前にインストールされたパッケージの繰り返しのメタデータ解決をスキップできるようにすることで、インストール プロセスを最適化します。
NPMJS docs package-lock.json descriptionを参照してください。
しかし、同じリンクによる別のフラグメントでは、次のように表示されます。
威厳§
これは、このリソースの標準サブリソース整合性です。
- バンドルされた依存関係の場合、ソースに関係なく、これは含まれません。
- レジストリ ソースの場合、これはレジストリが提供する整合性です。提供されていない場合は、shasum で SHA1 が提供されます。
- git ソースの場合、これはクローン元の特定のコミット ハッシュです。
- リモート tarball ソースの場合、これはファイルの SHA512 に基づく整合性です。
- ローカル tarball ソースの場合: これは、ファイルの SHA512 に基づく整合性フィールドです。
NPMJS ドキュメント package-lock.json の依存関係の整合性を参照してください。
Standard Subresource Integrity (SRI) へのリンクをたどると、次のことがわかりました。
1.1。目標
- サードパーティ サービスの侵害は、スクリプトを含むすべてのサイトの侵害を自動的に意味するものではありません。コンテンツ作成者は、ロードするコンテンツに対する期待を指定できるメカニズムを持ちます。たとえば、特定の URL を持つスクリプトではなく、特定のスクリプトをロードできます。
W3C サブリソースの整合性を参照してください
だから、NPMJSドキュメントのpackage-lock.jsonの説明で、セキュリティの目的が言及/リストされていないのはなぜだろうと思っています。個人的には、package-lock.json を使用してアプリケーションのセキュリティを向上させるというアイデアも気に入っています (ロックされている実際の依存関係を慎重に確認し、VCS リポジトリにチェックインされているロック ファイルを変更すると同時に、package.jsonにいくつかの変更を加えて、アプリに侵入することによる改ざんされた依存関係)。
しかし、おそらく私は何かを見逃しており、何らかの理由でロックファイルを上記で説明したセキュリティ目的に使用することはできません.