お探しのnpmパッケージはこれではありません

開発者として、これまでデジタルエージェンシーの案件や個人プロジェクト、スタートアップ、フリーランスの仕事を通じて、多くのアプリケーションを構築し、デプロイしてきました。期限の厳しいスケジュールやクライアントの期待、納期を考えると、npmでオープンソースパッケージをインストールする際、セキュリティが最優先事項になることはあまりありませんでした。その結果、既知の脆弱性が入り込んだデプロイをやり直したり、後処理したりすることになり、スケジュールがさらに延び、クライアントを失望させることも少なくありませんでした。

今年の初め、500を超える悪意あるパッケージが、アプリケーション内で依存関係の混乱を引き起こすためにnpmエコシステムへ公開されました。これらのパッケージは、望ましくないコードや機能を直接注入するか、直接または依存関係にあるオープンソースライブラリを介して悪意あるコードを持ち込みました。

初期の『スター・ウォーズ』映画のように、これらの悪意あるパッケージはジェダイのマインド・トリックでアプリケーションに侵入しようとしていました。こうした事例が増加するなか、デプロイを保護するために必要な時間を確保し、適切な予防措置を講じることが重要です。

依存関係へのコード注入からアプリケーションを守る方法をいくつか見ていきましょう。

事前の入念な確認

開発のあらゆる段階で、アプリケーションが何を使用しているのかを把握することが重要です。npmエコシステムの脆弱性の約80%は、依存関係に含まれる脆弱な経路から発生しています。だからこそ、事前の入念な確認が欠かせません。セキュリティを維持するには、選択したオープンソースパッケージがどのように作られ、どのようなサポート体制があるのかを理解する必要があります。

その方法の一つは、npmのパッケージページやGitリポジトリを使って、ライブラリの機能を確認することです。リリース数やサポート状況、パッケージが必要とする依存関係の種類を把握できます。

もう一つ便利な方法は、Snyk Advisorを利用することです。パッケージの健全性や、その履歴のなかで見つかった脆弱性について、有用な情報を得られます。

Snyk Advisorのページの優れた点の一つは、プロジェクト全体を包括的に把握できることです。コミュニティ、人気度、セキュリティ、メンテナンス状況に基づく健全性スコアも確認できます。

このページでは、週ごとのダウンロード数などの人気度統計、コミュニティによるコミット数、未解決の課題数を示す便利な時系列グラフも確認できます。エコシステムでの採用状況に加え、コミュニティの活動度を把握するのに役立ちます。

これらのグラフを見ると、プロジェクトでセキュリティ上の問題が発生した際、コミュニティがどれほど迅速に連携して修正に取り組めるかがわかります。

依存関係ツリーの作成

たった一度のnpm installで、Nodeアプリケーションに何百ものライブラリが追加されることがあります。たとえばElectronには主な依存関係が3つあり、その一部には独自の依存関係があるため、Electronベースのアプリに自動的に追加されます。

依存関係ツリーを使えば、ライブラリや依存関係を通じて追加されたパッケージを見つけられます。さらに重要なのは、アプリケーションで使用しているコンポーネントを特定し、SBOM（ソフトウェア部品表）の作成を容易にできることです。

依存関係ツリーを作成する方法はいくつかあります。たとえば、次のような方法です。

ビジュアルマッピングツールを使う

ビジュアルマッピングツールは、アプリケーションが使用しているすべてのオープンソースコンポーネントを視覚的に表示できるため、依存関係マップの作成に便利です。

私が使ったことのあるビジュアルマッピングツールの一つがnpmgraph.anです。単一のnpmライブラリから2Dの依存関係ツリーを作成できます。生成後、依存関係を表すツリーのノードをクリックすると、左側のパネルに詳細情報が表示されます。

コマンドラインでnpmを使う

グローバルライブラリのSnyk CLIのインストールから、ライブラリや依存関係の一覧の生成まで、npmの柔軟性には感心します。

ツリーを表示するには、package manifestがあるプロジェクトのルートディレクトリに移動し、npm listと入力します。npmベースのアプリケーションが使用している最上位のライブラリが、グラフではなくテキストで表示されます。npm list [package]と入力すれば、特定のパッケージについてさらに詳しい情報を確認することもできます。

ただし、先ほどのコマンドではネストされた依存関係は表示されません。表示するには--depthタグを使います。たとえば、npmプロジェクトのルートディレクトリでnpm list --depth=5を実行すると、より詳細なツリーが表示されます。

npm list [package] --depth=5を使えば、特定のパッケージの深さを指定することもできます。この方法の難点は、ツリー内をたどるのが難しいことです。特に依存関係マップが大規模な場合、どこを見ているのかわからなくなりがちです。

Snyk Open Sourceを使う

この方法では、コマンドラインのツリー表示とビジュアルマッピングを組み合わせ、さらに脆弱性検出も行えます。

まずSnykの無料アカウントに登録してサインインします。次に、アプリが保存されているリポジトリをSnykに接続し、スキャンを実行します。Add Projectボタンをクリックし、接続するリポジトリを選択してください。

リポジトリの接続手順に従い、Snykにリポジトリへのアクセスを許可します。

便利なヒント：ほとんどのプラットフォームでは、リポジトリがパブリックでもプライベートでもスキャンできます。

接続したら、ツリーを作成するアプリのリポジトリを検索して選択します。次に、右上のAdd selected repositoriesボタンをクリックして、スキャンを開始します。

スキャンが完了すると、検出結果の概要が表示されます。ドロップダウン矢印をクリックして最上位の項目を展開すると、スキャンで検出された各項目の内訳を確認できます。

今回確認するのは、npmのパッケージマニフェストpackage.json内にあるいくつかの項目です。package.jsonの行をクリックして一覧を展開すると、特定のライブラリで検出された脆弱な経路や、推奨される修正に関する追加情報などを確認できます。

ここからジェダイの魔法が本格的に始まります。Dependenciesタブをクリックすると、プロジェクトの依存関係一覧が表示されます。右上のツリー構造アイコンをクリックすると、ライブラリ間の関係や脆弱性が検出された場所などの詳細を確認できます。

これで、脆弱な経路がどこから始まっているのかを確認できる、インタラクティブなライブラリと依存関係のツリーが完成です。

Snykで依存関係ツリーを作成する最大のメリットは、継続的にスキャンできることです。新たな脆弱性が見つかると通知され、バージョンアップやカスタムパッチなどの修正方法も提案されます。脆弱性を検出した際に、より迅速に修正できるよう、リポジトリへのプルリクエストを自動で作成する設定も可能です。

オープンソースとともにあらんことを

オープンソースコンポーネントを定期的に確認することは、アプリケーションのセキュリティを維持するうえで重要です。依存関係ツリーは、使用しているものを理解するための優れた出発点ですが、Snyk Open Sourceのようなソフトウェア構成分析（SCA）ツールでアプリケーションを継続的にスキャンすることも欠かせません。