Snykで悪意あるパッケージやサプライチェーン攻撃を防ぐ

オープンソースパッケージは、現代のソフトウェア開発に欠かせない存在であり、私たちの周りで見られる開発の急速な進歩を支えています。アプリケーションに新しい機能を加えたい開発者にとって、車輪の再発明をする意味はありません。誰かが時間をかけて開発し、同じ機能を提供するパッケージをインストールすればよいのではないでしょうか。

しかし実際には、オープンソースパッケージはアプリケーションに悪意あるコードを配布し、サプライチェーンセキュリティを脅かすための格好の手段でもあります。その理由は簡単です。攻撃者にとって、狙いやすく見返りも大きいからです。パッケージはセキュリティチェックなしにレジストリへ公開され、人気プロジェクトの場合は週に何百万回もダウンロードされますが、コードベースに取り込まれる際も同じようにほとんど精査されません。

npm、PyPI、RubyGemsなどのレジストリでは、ここ数年、悪意あるパッケージが数多く確認されています。つまり、特定のエコシステムだけが他より脆弱というわけではありません。これは現代のソフトウェア開発に内在するセキュリティ上の弱点であり、セキュリティチーム、そして何より開発者が認識し、対処しなければなりません。

この記事では、ソフトウェアサプライチェーン攻撃で悪意あるパッケージがどのように利用されるのかを簡単に解説し、Snykがその防止にどう役立つかをご紹介します。

ソフトウェアサプライチェーン攻撃における悪意あるパッケージ

ソフトウェアサプライチェーン攻撃は、ソフトウェア製品に悪意あるコードを混入させ、サプライチェーンの下流にある依存システムをさらに侵害することを目的とします。ただし、攻撃対象や具体的な手法はさまざまで、その形態も多岐にわたります。

たとえばSolarWinds攻撃の標的は、ソフトウェアのビルドプロセスとソースコードでした。最近のKaseya攻撃では、既存のソフトウェアが標的となりました。そして近年、オープンソースパッケージが狙われるケースも増えています。この種のソフトウェアサプライチェーン攻撃では、npm、PyPI、Ruby Gemsなどのパッケージリポジトリに登録されたパッケージへ悪意あるコードが注入されます。開発者がパッケージの真正性や完全性を疑わずに信頼していると、手動で、あるいは自動ビルドプロセスの一環として、知らないうちに悪意あるパッケージをダウンロードしてインストールしてしまいます。

攻撃者にとって、この手法は非常に効果的です。オープンソースパッケージは1日に何百万回もダウンロードされるため、格好の配布手段となります。2018年に発生したevent-stream攻撃は、悪意あるパッケージを利用したソフトウェアサプライチェーン攻撃がどれほど広範囲に及ぶかを示す顕著な事例です。この攻撃では、まず攻撃者が広く利用されていたevent-streamパッケージの管理権を獲得し、悪意あるパッケージflatmap-streamに依存するよう改変しました。当時、event-streamは1,600のパッケージで使われ、週に150万回ダウンロードされていました。

パッケージに悪意あるコードを注入する方法

攻撃方法の1つは、悪意あるコードを含む新しいパッケージを作成することです。既存のパッケージに似た名前を付ける方法（タイポスクワッティング）や、元のメンテナーが公開を取り下げたパッケージの名前や識別子を再利用する方法（「use after free」攻撃）があります。2つ目の方法は、ソースコードやビルド中、またはパッケージリポジトリ内に悪意あるコードを注入し、既存のパッケージに感染させることです。悪意あるコードを含む、一見問題のなさそうなプルリクエストがプロジェクトのメンテナーによってマージされるだけで成立します。3つ目は、代替リポジトリやリポジトリミラーに悪意あるパッケージをアップロードする方法です。

悪意あるパッケージがプロジェクトの依存関係ツリーに入り込むと、悪意あるコードが実行される経路はいくつかあります。パッケージのインストール中にインストールスクリプトが実行されるケースもあれば、実行時に悪意あるコードを呼び出す必要があるケースもあります。

Snykで悪意あるパッケージのリスクを軽減

では、悪意あるパッケージから身を守るにはどうすればよいのでしょうか。

エコシステムごとに、悪意あるパッケージがコードベースへ侵入するのを防ぐ具体的な対策があります。たとえばJavaScriptについては、こちらのチートシートでベストプラクティスを解説しています。アプリケーションセキュリティソリューションであるSnykは、開発の早い段階だけでなく、後の工程でも悪意あるパッケージを特定できる機能を提供します。

デューデリジェンスを開発の早い段階にシフトする

アプリケーションセキュリティを開発の早い段階にシフトすることは、今や事実上の標準です。最も効果的なチームは、IDEを使ったローカル開発環境など、可能な限り早い段階からセキュリティテストを自動化しています。しかし、セキュリティ対策や悪意あるパッケージの特定は、最初のコードを書く前、つまり計画・調査の段階から始めることもできます。

プロジェクトに取り込むソフトウェアを調査する際、デューデリジェンスを行うことは常に有効なベストプラクティスです。しかし、特定のパッケージを詳しく調べるのは簡単ではありません。理想的には、パッケージをインストールするかどうかを判断するために必要な情報、つまりパッケージの安全性やセキュリティに関する情報を、パッケージレジストリがすべて提供してくれるはずです。しかし実際には、レジストリにはパッケージの健全性やセキュリティに関する情報が不足しています。

Snyk Advisorは、プロジェクトで使用するパッケージの選定に役立つ無料のオンライン調査ツールです。パッケージ選定時に考慮すべき重要な要素を基に、ヘルススコアを表示します。たとえば、リリース頻度やリポジトリの活動状況から、パッケージがどれほど保守されているかを分析します。また、パッケージの人気度や、プロジェクトを支えるコミュニティの強さも分析します。

もちろん、Snyk Advisorはパッケージのセキュリティ状況も評価します。セキュリティデータはSnyk Intel Vulnerability Databaseに基づいており、パッケージが悪意あるものかどうかも含まれています。以下の例では、npmパッケージlyft-dataset-sdkが、依存関係の混乱を引き起こす目的で利用される可能性のある悪意あるパッケージとしてSnyk Advisorに検出されています。このパッケージは、Lyftが公開したPythonパッケージと同じ名前のため、その依存関係が定義されたコードベースに容易に侵入するおそれがあります。

Snyk Vulnerability Databaseでも悪意あるパッケージが検出されるため、調査プロセスの一環として活用できます。

以下のタイポスクワッティングの例では、auth-clientという名前のgemが悪意あるものとしてマークされています。このgemの作者は、既存の安全なRubyパッケージ（例：auth_client、authclient）に非常によく似た名前を意図的に使用しています。開発者が依存関係の名前を入力ミスし、トロイの木馬化されたパッケージをダウンロードすることを狙っています。

SDLC全体を通じて悪意あるパッケージに対処する

徹底的に調査しても、悪意あるパッケージを見逃す可能性はあります。SnykはSDLCのさまざまな段階でセキュリティテストを実施し、こうしたパッケージをできるだけ早く特定します。

Snykで監視しているGitプロジェクトでは、コントリビューターが新しいプルリクエストを作成すると、Snyk Vulnerability Databaseに照らしてチェックされます。悪意あるパッケージが検出された場合、セキュリティテストは失敗し、パッケージの情報とテストが失敗した理由が表示されます。

すでにバックログにある悪意あるパッケージはどうでしょうか。何百、何千もの脆弱性がある中で、悪意あるパッケージによって持ち込まれた問題を1つ見つけるのは、経験豊富なチームにとっても大変な作業です。

SnykはSnyk UIでも悪意あるパッケージを検出します。Snykで監視しているプロジェクトでは、脆弱性のPriority Scoreに悪意あるパッケージの情報が反映されます。脆弱性のCVSSスコア、修正プログラムの有無、ソーシャルメディアで話題になっているか、既知のエクスプロイト、脆弱性の新しさ、到達可能性など、ほかの評価要素も加味されます。これにより、該当する問題をすばやく特定し、優先順位を付けて修正できます。

早期に対策を講じる

攻撃者にとって、セキュリティチェックなしにパッケージをレジストリへ簡単にアップロードできること、そして開発スピードを維持するためにパッケージへの依存が高まり続けていることは、この攻撃を非常に魅力的なものにしています。

これは、今日のアプリケーション開発に内在するセキュリティ上の弱点です。開発者やセキュリティ担当者は、使用するパッケージを選ぶ調査の初期段階から、開発中の後続段階まで、悪意あるパッケージを特定できる必要があります。

ソフトウェアサプライチェーンセキュリティについて詳しくはこちら。