依存関係に注意せよ!マリシャスnpmパッケージからの防御

現代のソフトウェアプロジェクトは，そのほとんどがオ，プンソ，スのコ，ドで構成されています。Log4Shellの脆弱性が発見された後,それらのコードを本当に管理しているのは誰か,ソフトウェアのサプライチェーンにおけるセキュリティ問題を検出して修正する責任は誰にあるのか,という疑問が大きな関心事となりました。

最近では，颜色と骗子という人気のNPMパッケ，ジが，メンテナによって意図的に破壊されました。この開発者であるMarak Squires氏は,これらのパッケージを使えなくする変更を加え,これらを使用しているアプリケーションを意図せぬ動作をさせるようにしました。実装された意図された欠陥は外観上のものであり(訳注:非ASCII文字を含めることで米国国旗を無限に表示させるという“欠陥”),基本的には被害にあった多数のツールを緊急に修正する必要があったという程度の被害ですが,このシナリオはより深く,より問題があることを示しています。恐ろしいことに,これと同様に簡単に彼は“悪意ある危険なコード”を仕込むことができ得たわけで,今回の欠陥バージョンのパッケージをダウンロードしたことが判っている何十万ものマシン上でそれが実行され得たのです。

深く悩むべき事実は,多くの状況において,開発者にはほとんど見えない方法で,新しいコードがリポジトリからプルされ,プロジェクトで使用され,マシン上で実行される可能性があるということです。公開リポジトリから入手したコードを信頼するという前提は,多くのパッケージマネージャに深く根ざしていますが,この信頼はあまりに性善説に立ちすぎているかもしれません。今回の事件は,何年もかけて築き上げた信頼,がいつの日か破られる可能性があり,堅牢なパッケージの新バージョンでさえ信頼できないことを示しています。

NPMパッケジのンストルに潜むリスク

最近の開発手法論でもたらす可能性のあるリスクを説明するために,npmパッケージをインストールするプロセスを検証し,アプリケーションがnpmレジストリから悪意あるパッケージを誤ってプルし得ることを見てみましょう。

プロジェクトで特定のバ，ジョンのNPM依存関係の使用を強制する一般的な方法は，package-lock.jsonファ@ @ルを使用することで，許可されるラ@ @ブラリのバ@ @ジョンを指定します。可能な限りpackage-lock。Jsonを使用し，依存関係のバ，ジョンを正確に指定することを強くお勧めします。しかし,あまり知られていないことですが,現在のnpmインストーラは,パッケージをグローバルにインストールする場合(npmをオプション- gまたは全球と共に実行)，包锁。Jsonファeprルを尊重せず，package.jsonファイルで指定された依存関係に応じて,パッケージの依存関係の最新バージョンを優先的にダウンロードします。これが,package-lock。Jsonによる保護を想定していたにもかかわらず，アプリケーションが意図せぬバージョンの颜色パッケージを使用してしまうことになった原因です。

任意のnpmパッケージ(依存関係)の最新バージョンを検証せずにインストールすることは,悪意がある可能性(骗子や颜色の例のように,新バージョンで良からぬ変更がなされた場合等)からのみならず,依存関係を使用するコードを壊す可能性もあることから危険です(APIが変更された場合等)。

npmパッケ，ジ用のOSS，，ルをJFrogが新たに公開

これらの事例を受けて,JFrogセキュリティリサーチチームは,欠陥のある可能性のあるnpmパッケージのインストールを検知・防止することを目的とした3のossルを公開しました。

• package_checker:パッケジの特定のバジョンが信頼できるかどうかを確認するルです。サプライチェーン攻撃に使用されるパッケージの兆候を調査し,新しくリリースされたバージョンの潜在的なリスクを特定するために使用できます。チェック対象となる項目は以下の通りです。
  • バージョン番号の著しいギャップ(例:骗子npmパッケージのように,5.5.3から6.6.6にジャンプするような場合)
  • 長期間メンテナンスされていなかったパッケ，ジのアップデ，ト
  • npmに表示されるバージョンと,リンク先のGitHubリポジトリとの不一致(特定のコードがリリースされたことが隠蔽されている可能性がある)
  • バージョン公開からの経過日(公開直後のバージョンは十分な検証が済んでおらず,悪意のあるコードが含まれている可能性)

このツールは,開発者が依存関係のアップデートを決定する前に,使用パッケージの新バージョンを能動的にテストしたり,社内で使用しているパッケージの新バージョンをすべて組織的に監視したりするために使用できます。

• npm-secure-installer:npm安装の安全なラッパ，です。npm-shrinkwrapロックファ▪▪ルを含まないパッケ▪▪ジのグロ▪バル▪▪ンスト▪▪ルを拒否します。
  谷歌のSLSAの重要な要件の1は，依存関係の気密性です。まり，依存関係は不変の参照にロックダウンされます。npmは，npm安装の初回実行時に自動的に作成されるpackage-lock。Jsonを使用することで，これを達成しています。しかし,npmを使用してグローバルツールをインストールする場合,npmはどのプロジェクトからも実行されないため,package-lock。Jsonファeconrルが存在していても使用されません。幸いnpmはこのシナリオのために特別に設計された收缩包装アプローチを提供します。
  npm-secure-installerは，安全なアプロ，チを自動化します。パッケージにnpm-shrinkwrapマニフェストがあることを確認してからインストールを実行します。
  このルは，開発者のワを安全にするために，npm安装の代わりに使用することができます。
• package_issues_history:問題のあるパッケージのアップデートを監視する試験的なツールで,特定のパッケージバージョンに重大な変更が加えられていることが判明する前に,それらを発見することを目的としています。破壊的,あるいは悪意のある変更は様々な方法で生じる可能性があり,極端な(そして恐らく稀な)場合を除いて,良性の変更を誤検知しないような変更ルールを定義することは困難です。あるパッケージへの破壊的,あるいは悪意ある変更による唯一の確かな結果は,それに依存するパッケージの問題ということになるはずです。このツールに実装されている提案手法は,特定パッケージに依存しているプロジェクトで,バージョン更新後の数日間に作成されたGitHubの“问题”を追跡するというものです。人気のあるライブラリの場合,依存するプロジェクトの数が多いため,重大な変更に伴うは“问题”,その変更と無関係のものと比べて極端に増加します。下のグラフは、颜色パッケージとその依存ライブラリの“问题”作成率から,どのバージョンのアップデートが他よりも“问题”が多いについての重要なことを明確に示しています。

常に最新に

これらのツールは,現代のソフトウェアサプライチェーンが直面するいくつかの問題を明らかにし,それを解決するための方法論を明らかにするための正しい方向への一歩であると考えています。JFrogは,最新のソフトウェアセキュリティの脅威に対処するための情報やオープンソースツールを提供して開発者コミュニティをサポートすることに加え,開発者やセキュリティチームにJFrog x光による高度なソフトウェアサプラ▪▪チェ▪▪ンセキュリティ機能を提供します。悪意あるパッケージの高度な検出を含むx光の製品アップデートについては,引き続きフォローしてください。