エクサフォース・ブログ | Npm provenance: bridging the missing security layer in JavaScript libraries

最近のセキュリティインシデント人気者を巻き込む宝くじプレイヤー図書館は、NPMエコシステムのセキュリティの脆弱性を改めて浮き彫りにしました。NPM は出自証明のような強固なセキュリティ機能を提供していますが、ダウンロードされるパッケージの多くはこうした重要なセキュリティ対策を利用していません。

NPM プロビナンスとは何ですか?

NPM Provenance は、公開されたパッケージとそのソースコードリポジトリとの間に検証可能な接続を作成するセキュリティ機能です。導入された去年。有効にすると、パッケージが GitHub Actions または Gitlab ランナーを使用して特定の GitHub リポジトリコミットからビルドされたことを暗号で証明できます。これにより、悪意のある攻撃者が人気のあるパッケージの侵害版を公開してしまうようなサプライチェーン攻撃を防ぐことができます。ただし、このセキュリティはビルド環境自体の整合性に依存していることに注意することが重要です。GitHub/GitLab アカウントや CI/CD パイプラインが侵害された場合でも、悪意のあるコードの出所証明書が生成される可能性があります。そのため、強力なアクセス制御、監査ログ、定期的なセキュリティレビューによってソース管理と CI/CD インフラストラクチャを保護することが依然として重要です。

NPM のセキュリティモデルにおける重大なギャップ

Diagram of current NPM software supply chain showing security gaps: missing provenance, attestation, tag verification, and client checks

サーバー側の制限事項

NPM レジストリには現在、重要なサーバー側の強制メカニズムがありません。

1。出所は必須ではありません

パッケージは認証なしで公開できます
特定のパッケージや組織に出所要件を強制する方法はない
レジストリは検証の有無にかかわらずパッケージを受け入れます

2。ポリシーコントロールが欠けている

組織はパッケージ公開の要件を設定できません
git branch protection のように特定のパッケージ名やパターンの出所を強制する機能はない
ビルドソースの信頼性の自動検証なし

3。バージョンコントロール

出所が一致しないとバージョン更新を防ぐメカニズムがない
メジャーバージョン更新に対してより厳しい要件を課すことはできません

クライアント側の検証ギャップ

npm/yarnクライアントツールには、重要なセキュリティ制御もありません。

1。インストールプロセス

2。セキュリティ機能が欠けている

出所情報を必要とする組み込みフラグはありません
組織全体に認証ポリシーを適用できない
単一パッケージ認証を検証する方法がない

3。パッケージ.json の制限事項

ザ・ロッティ・プレイヤー・インシデント

最近の妥協案は 宝くじプレイヤー 図書館は、何がうまくいかないかをはっきりと思い出させてくれます。攻撃タイムライン:

攻撃者がメンテナの NPM アカウントにアクセスした
パッケージの悪質なバージョンを公開しました
ユーザーは、ピン留めされていない依存関係の更新と直接の CDN リンクを通じて、侵害されたバージョンを自動的に受け取りました。
影響を受けるシステムで悪質なコードが実行される

出自証明がレジストリまたはクライアントレベルで実施されていれば、この攻撃は防げたはずです。

Provenance を使用するパッケージが増えないのはなぜですか?

NPM Provenanceの採用率が低い理由には、以下のようないくつかの要因があります。

認識のギャップ:多くのメンテナはこの機能に慣れていない
実装オーバーヘッド:GitHub Actions ワークフローの変更が必要
レガシーシステム:既存のビルドパイプラインには大幅な更新が必要な場合があります
誤った安心感:2FAのような他のセキュリティ対策への依存
執行の欠如:レジストリ要件が欠けているため、導入を迫られることはない

Diagram of a recommended secure NPM model showing build, registry, client, and CDN security with provenance, OIDC, and SRI validation

に出所を有効にする NPM パッケージの場合:

または、パッケージ.jsonで実行してください

パッケージの出所確認

npm コマンド audit はパッケージの完全性と信頼性をチェックできますが、個々のパッケージを検証することはできません。一度に検証できるのは、プロジェクト内のすべてのパッケージだけです。

NPM の認証が無効です

npm CLIはこれを行う簡単な方法を提供していないので、簡単な方法を書きました脚本個々のパッケージの整合性と認証を確認します。このスクリプトを使うと、各パッケージを簡単に検証できます。

このスクリプトは、クライアント側の GitHub Workflow で使用することも、アップストリームパッケージの認証を継続的にチェックするための監視ツールとして使用することもできます。

クライアント側スクリプトの整合性検証

NPM Provenanceはパッケージエコシステムの保護に役立ちますが、CDNリンクを介してJavaScriptを直接読み込むWebアプリケーションには追加のセキュリティ対策が必要です。はサブリソースインテグリティ (SRI) メカニズムは、外部からロードされたリソースの暗号化検証を行います。Lottie-Player による攻撃は、一般的でありながら危険な行為が 3 つあり、特に壊滅的な被害をもたらしました。

1。最新のタグを使う

2。整合性チェックが行われていません

3。フォールバック戦略なし

SRIは、期待されるファイルコンテンツの暗号化ハッシュを提供することで機能します。ブラウザー:

リソースをダウンロードする
ハッシュを計算します
指定されたインテグリティ値と比較します
不一致がある場合は実行をブロックします

整合性チェックの検証に失敗すると、ブラウザはサンプルエラーを含むJavaScriptの実行を許可しません

Screenshot showing a webpage with accordion UI and browser console errors for invalid SRI hash blocking Bootstrap CSS from CDN

エコシステムに関する推奨事項

1。パッケージメンテナ:

出自証明をすぐに有効にする
README ファイルへの出自状況の文書化
自動化された検証済みのビルドには GitHub Actions を使う

2。パッケージユーザー:

新しい依存関係を追加する前に、出自状況を確認してください
出自が有効になっているパッケージを優先します。次のような Web サイトをチェックしてください。トラスティPKG 活動、出所などに基づいてその信頼性を理解する
既存の依存関係を監視して来歴を把握する

3。プラットフォームプロバイダー:

NPM レジストリ UI で出自状況をより見やすくする
出所を一括検証するためのツールを提供
影響の大きい荷物には出所を義務付けることを検討してください
サーバー側の強制メカニズムの実装
クライアント側検証ツールの追加

4。NPM レジストリ

組織レベルの出自要件を追加
人気のあるパッケージに必須認証を実装する
出自検証用の API エンドポイントの提供
パッケージ承認プロセス/ワークフローを提供

結論

NPM エコシステムのセキュリティは、世界中の何百万ものアプリケーションに影響を与えます。現在、レジストリレベルとクライアントレベルの両方で強制メカニズムが欠如しているため、重大なセキュリティリスクが生じています。出自証明は可能ですが、体系的に実施できないため、エコシステムはサプライチェーン攻撃に対して脆弱なままになります。

NPM チームは、サーバー側とクライアント側の両方の強制メカニズムの実装を優先すべきです。それまでは、コミュニティは手作業による検証とベストプラクティスに頼らなければなりません。パッケージ管理者は出自証明をすぐに有効にすべきであり、ユーザーはより優れたセキュリティ管理と検証ツールを求めるべきです。

NPMのインフラストラクチャを改善するために協力して初めて、より安全なJavaScriptエコシステムを構築できます。ExaForceでは、オープンソースのライブラリが出版プロセスで出自証明を採用できるよう支援することで、最初の一歩を踏み出すことに全力を注いでいます。