ソフトウェアサプライチェーンのセキュリティ

ソフトウェアを含むサプライチェーンの脆弱性は、コロナ禍以降、注目を浴びています。ビジネス活動のオンライン化が進む今の時代は、個人データの漏洩、金銭的損失、政府による罰則、修復不可能なブランドへのダメージをもたらす侵害やハッキングという形で脆弱性を悪用しようとする悪意あるアクターからソフトウェアサプライチェーンを確実に保護することが重要です。

この記事では、ソフトウェアサプライチェーンのセキュリティについてさらに詳しく説明します。組織にとっての重要性や、Snyk を使ったソフトウェアサプライチェーンの安全保護についても解説します。

現代のほとんどのソフトウェアでは、オープンソースコードやサードパーティコンポーネントが使用されています。つまり、そのソフトウェアを販売・公開している企業以外の開発者が作ったものが含まれているのです。他社製のコードやコンポーネントを使えば、開発サイクルはゼロの状態から作るよりも時短化されますが、一方でセキュリティリスクも伴います。ソフトウェアサプライチェーンのセキュリティが極めて重要なのはそのためです。

スコープには、開発プロセスで使用されたサードパーティソフトウェアのコンポーネントやオープンソースのライブラリのセキュリティ評価が含まれ、そのすべてに脆弱性やマルウェアなどのサイバーハザードがないことを保証します。ソフトウェアサプライチェーンのセキュリティとは、ソフトウェアのライフサイクル全体を通じて整合性と機密性を守る包括的なアプローチです。

ソフトウェアサプライチェーンセキュリティが重要な理由

ソフトウェアサプライチェーンへの脅威は極めて現実的なものです。2022 年の報告書によると、ソフトウェアサプライチェーンへの攻撃は過去 3 年間で実に 742% も増加しています。最近の事例をいくつか挙げます。

• SolarWinds 攻撃: 2020 年 12 月、大企業の IT 管理ソフトウェアのプロバイダーである SolarWinds のネットワークに、ロシア政府が関与するハッカー集団が侵入しました。ハッカーはソフトウェアアップデートにマルウェアを挿入し、SolarWinds を利用する数千社の顧客企業 (行政法人や民間企業を含む) にそのマルウェアを分散した結果、ハッカーは各社のネットワークにアクセスできるようになりました。

• ShadowHammer 作戦: 2019 年、ハッカーは侵害されたソフトウェアアップデートを使用して、ShadowHammer と呼ばれるマルウェアを ASUS 製パソコン全体に配布しました。この攻撃の被害者は 100 万人にものぼると言われています。 

• Huawei: 米国当局は、中国の通信会社 Huawei が提供し、そのシステム内の組織が使用するソフトウェアが、中国政府によってスパイ行為やその他の悪意のある目的に利用されている可能性があると警告しました。

その他の例については、サプライチェーンへの攻撃ガイドをお読みください。

ソフトウェアサプライチェーンのセキュリティは、サイバー攻撃の阻止や攻撃の影響の軽減のほか、開発時点でアプリケーションに脆弱性が含まれることを防ぐこともできます。堅牢なセキュリティは、マルウェアや脆弱性、セキュリティ上のその他の脅威など、悪意のあるコンポーネントや侵害されたコンポーネントがソフトウェアの開発・導入プロセスに入り込まないよう保護できます。サプライチェーンを保護することで、規制や業界標準への準拠が保証されると同時に、開発・デプロイされるソフトウェアに対する信頼や自信も高まります。

サプライチェーンのセキュリティの問題は国家安全保障にとって非常に重要であるため、米国大統領ジョー・バイデンは 2022 年 9 月に、米国の行政機関が購入するソフトウェアを保護するために公布された NIST ガイドラインを強調する大統領令 M-21-30 を発令しました。この大統領令により、証明書フォームには次の内容を含めることが義務付けられました。

• ソフトウェア制作者の名前

• ソフトウェア名

• 安全な開発慣行に遵守していることを宣誓するベンダーまたは代理店の声明

ソフトウェアサプライチェーン攻撃とは？

ソフトウェアサプライチェーンへの攻撃は、攻撃者がソフトウェア開発サプライチェーンの脆弱性を標的にして、ソフトウェアに悪意のあるコードやマルウェアを挿入することで発生します。こうした攻撃は、初期のコーディングやテスト段階から配布やインストール段階まで、ソフトウェア開発中いつでも発生する可能性があります。悪意のあるアクターは、ソフトウェアに埋め込んだマルウェアを起動してコンピューティングリソースや機密情報を盗むことも、稼働を中断することも、システム全体を乗っ取ることもできます。 

攻撃者は、ソフトウェアサプライチェーンの脆弱性を標的とするため、さまざまなベクトル (方法や戦術) を使用する可能性があります。ベクトルには以下のような例が挙げられます。

• サードパーティのコンポーネント: 悪意のあるアクターはサードパーティのコンポーネント (ライブラリやフレームワークなど) を標的とし、ソフトウェアにマルウェアを挿入する機会を伺います。

• 侵害された開発ツール: 悪意のあるアクターは、マルウェアを埋め込む機会を伺うため、コンパイラやビルドシステム、その他の開発ツールをターゲットにします。

• 侵害された開発者アカウント: 悪意のあるアクターは、GitHub やその他のコード共有プラットフォーム上の脆弱性など、開発者アカウント内の脆弱性を悪用する機会を伺います。

• 侵害されたソフトウェアアップデートインフラ: 悪意のあるアクターは、ShadowHammer 作戦で見られたように、ソフトウェアアップデートインフラスを標的にしてマルウェアを配布することがよくあります。

• ソーシャルエンジニアリング: 悪意のあるアクターは、従業員や開発者をだまして機密情報やシステムへのアクセスを聞き出すこともあります。

ソフトウェアサプライチェーンへの攻撃を軽減するための 4 つのベストプラクティス

ソフトウェアサプライチェーンのセキュリティを確保することは、用途が内部か外部かを問わず、ソフトウェアを開発・展開する組織にとって不可欠です。ソフトウェアサプライチェーンへの攻撃リスクを軽減するため、すぐに実行すべき 4 つのベストプラクティスを一覧にまとめました。次のとおりです。 

1. 依存関係かく乱攻撃を軽減する

2. オープンソースパッケージによる任意のインストールコマンドを無効化する

3. ソフトウェアサプライチェーン全体で多要素認証を有効にする

4. 機密情報の漏洩を防止する

1. 依存関係かく乱攻撃を軽減する

悪意のあるアクターは企業のソフトウェアサプライチェーンの弱点を悪用するため、依存関係かく乱攻撃を仕掛けるのは簡単です。防御方法には以下のような手段が考えられます。

• 名前空間でスコープを使用する: スコープを使用したパッケージは、パッケージの名前空間をロックし、それを特定のユーザーや組織にマッピングします。これにより、ユーザーの本来意図したパッケージが上流リポジトリで代替されることがなくなるため、依存関係かく乱攻撃攻撃を軽減できます。 

• 明示的なアップストリームレジストリ定義にリポジトリ固有の設定を使用する: pip や npm などのパッケージマネージャーは、明示的に指示されていない場合、最善を尽くしてパッケージ情報を検索して解決しようとします。マネージャーは、パッケージの新しいバージョンを見つけるためにパブリックレジストリ (npmjs、PyPI など) を検索し、悪意のあるパッケージを誤って挿入してしまうことがあります。Artifactory や Verdaccio などの内部パッケージリポジトリやプロキシを使用する場合、非公開パッケージのリクエストを公開レジストリにプロキシしていないことを確認する必要があります。

npmjs の共同創設者であるアイザック・シュルーター氏 (Isaac Schlueter) は依存関係かく乱攻撃に対する上記の対策として、いくつかの詳細な事例と設定のリファレンスをまとめています。ソフトウェアサプライチェーンへの攻撃に関するこれらの不安を軽減するガイドラインを提供する Microsoft のホワイトペーパーもお読みください。

2. オープンソースパッケージによる任意のインストールコマンドを無効化する

npm などの一部のパッケージマネージャーは、パッケージのインストールまたはアンインストールが任意のコマンドを実行できるようになっています。このデフォルト設定は、多くの悪意のあるパッケージによって兵器化されています。攻撃のもう 1 つの手段は、依存関係ツリーを利用したり、コマンド行でのパッケージ名の入力ミスを利用したりすることによって、悪意のあるパッケージをインストールさせるタイポスクワッティング攻撃です。 

依存関係の名前は取り違えることが多くあります。例として、以下のうちどれが悪意のあるパッケージで、どれが本物のパッケージかを判断してみてください。

coffeescript

cofeescript

依存関係かく乱攻撃のベクトルにだまされやすいのも納得できるでしょう。重要なのは、パッケージを軽はずみでインストールしたり、やみくもにコピー＆ペーストしたりするのではなく、最初にパッケージをよく調べて精査することです。パッケージの健全性は、Snyk Advisorで評価することをおすすめします。

依存関係かく乱攻撃とは何ですか？

最も一般的で簡単な攻撃ベクトルの 1 つは、依存関係かく乱攻撃です。悪意のあるアクターはこの手法を使用して、組織がソフトウェアの依存関係を管理する方法の脆弱性を悪用しようとします。攻撃者は、正規のパッケージに似た名前を使用して、オープンソース パッケージの悪意のあるバージョンをパブリックパッケージ管理システム (npm または PyPI) にアップロードします (タイポスクワッティングまたはブランドジャッキングとも呼ばれます)。開発者が悪意のあるバージョンのパッケージを誤って更新またはインストールし、システムを危険にさらす可能性があります。

3. ソフトウェアサプライチェーン全体で多要素認証を有効にする

オープンソースコミュニティの善良な市民である私たちは、かつてないほど相互に依存しています。自らの信頼性や管理するソフトウェアの信頼性を高めるため、認証の重要性が増しています。開発者は 2FA を有効にしない場合のリスクを理解しているので、まず 2FA を有効にするだろうと思うかもしれませんが、残念なことに、そうした配慮はなされていないことがわかっています。 

2017 年末からこの機能が存在していたもかかわらず、2020 年 1 月の時点で npmjs で 2FA を有効にした開発者の割合は 10% 未満として公に報告されました。 

そのためソフトウェア環境で仕事をしている方には、npmjs、RubyGems、Docker、GitHub などのレジストリやエコシステムにおけるアカウントのセキュリティ対策を強化し、多要素認証を有効にすることを強く推奨します。

4. 機密情報の漏洩を防止する

オープンソースソフトウェアの人気に伴い、開発者とコントリビューターはオープンに共同作業をしています。これはイノベーションにとっては素晴らしいことですが、機密情報にとっては不注意から漏洩の可能性があるため好ましくありません。機密情報はいったん共有されてしまうと隠すのが非常に難しいため、機密情報の公開は避けるよう注意してください。次のような措置を講じることができます。 

• 機密情報をリポジトリや設定、またはコードに保存しない。詳細については、10 GitHub security best practices (GitHub のセキュリティベストプラクティス 10 選) を参照してください。各セキュリティプラクティスについて詳しく調べることができます。

• 公開レジストリに保存される可能性がある、あるいは機密性が高い可能性がある情報を含むパッケージまたは Docker イメージは公開しないでください。10 npm security best practices (npm のセキュリティベストプラクティス 10 選) のガイドラインに従うことで、適切な .npmignore の設定で npm パッケージを設定できます。

さらに詳しく知りたい場合は、ビデオプレゼンテーション「ソフトウェアサプライチェーンのセキュリティリスクを軽減する方法」をご覧ください。

サプライチェーンのセキュリティは AppSec と DevSecOps にどのように関係しますか？

サプライチェーンセキュリティ、AppSec (アプリケーションセキュリティ)、DevSecOps (開発、セキュリティ、オペレーション) はすべてソフトウェアの開発、配布、管理を行う上でコンポーネントやシステムの安全を守るために関連しています。 

• サプライチェーンセキュリティ: ソフトウェアと、その開発や配布で使用するコンポーネントが信頼できるソースから提供され、脆弱性がないことを保証します。

• AppSec: ソフトウェアそのものと、そのソフトウェアを実行するシステムを保護する一方で、ソフトウェアが処理するデータも保護します。 

• DevSecOps: ソフトウェアの開発、テスト、導入フェーズの早い段階でセキュリティチームとそのプロセスを導入することで、ソフトウェア開発プロセスにセキュリティを統合します。潜在的なセキュリティ上の懸念に早期に対処することが目的です。

サプライチェーンのセキュリティ、AppSec、DevSecOps を連携させることで、製品またはシステムの全体的なセキュリティを確保すると考えてください。

サプライチェーンのセキュリティを自動化する

ソフトウェアと、その開発や配布で使用するコンポーネントの保護に関わるプロセスとタスクを自動化することで、強力なサイバーセキュリティ体制の維持に役立ちます。自動化は、セキュリティ上の脅威を効率的かつ効果的に特定して軽減するだけでなく、システムやコンポーネント全体にセキュリティコントロールを常に確実に適用することで、人的エラーに関連するリスクを軽減します。

サプライチェーンのセキュリティの自動化されたテクノロジには、次のようなものがあります。

• 自動脆弱性スキャン: サードパーティのソフトウェアとコンポーネントを自動的にスキャンして、既知の脆弱性やセキュリティの脅威を検出するツール。スキャンツールは、セキュリティチームが設定したポリシーを使用して、アプリケーションに侵入しようとする重大な脆弱性を管理、警告、ブロックします。

• 自動化された依存関係の管理: 製品 (ライブラリやレームワークなど) の依存関係を自動的に追跡・管理し、依存関係に既知の脆弱性や新たに発見された脆弱性が含まれている場合に開発者に警告するツール。

• 自動化されたサプライチェーン分析: ソフトウェアサプライ製品の潜在的なセキュリティリスク (信頼できないサードパーティコンポーネントなど) を自動的に分析するツール。

• 自動化された設定管理: システム (ソフトウェア、サーバー、クラウドリソースなど) のセキュリティ設定を自動的に管理・強制するツール。

Snyk でソフトウェアサプライチェーン攻撃を軽減する

Snyk は、アプリケーションに組み込んだオープンソースパッケージやコンテナを含むコードベースに侵入している脆弱なパッケージや悪意のあるパッケージを特定、修正、防止し、ソフトウェアサプライチェーンを強化するのに役立ちます。 

オープンソースセキュリティ

Snyk は率先して調査し、責任を持って開示し、組織がコードベースに取り込まれたオープンソースの依存関係内の悪意のあるパッケージを検出・修正できるよう支援します。2020 年だけでも、Snyk はオープンソースのレジストリから 700 件以上の悪意のあるパッケージを検出しています。 

Snyk は、これらの悪意のあるパッケージを発見、検出し、ユーザーの修正を支援してきました。たとえば、npmjs の electron-native-notify 依存関係の攻撃や strong_password の Ruby gem でのリモートコード実行などがあります。また、Snyk のセキュリティリサーチチームは最近、悪意のある SDK を通じて数千件のモバイルアプリケーションに影響を与えた SourMint の広告詐欺とデータ流出に関する調査結果を発表しました。

Snyk ではパッケージマニフェストファイルをスキャンし、アプリケーションに組み込んでいるすべてのパッケージを一覧表示する完全な深くネストされた依存関係ツリーを構築できます。これには推移的依存関係も含まれます。次に、依存関係を Snyk インテリジェンス脆弱性データベースと関連付けられ、Snyk で既知の悪意のあるパッケージの参照が特定された場合、関連するパッケージに脆弱性としてフラグが付けられます。 

SDLC での Snyk の導入方法に応じて、ビルドまたは CI プロセスが通らないようにする、通知を送信する、Jira チケットを発行するなど、ワークフローに合わせた仕方で悪意のあるパッケージやコンテナベースのイメージを使用させない仕組みを自動化できます。

ソフトウェア部品表 (SBOM)

ソフトウェア部品表 (SBOM) とは、ソフトウェアの開発に使用されるコンポーネントと、そのソフトウェアサプライチェーン関係の正式な記録とされています。SBOM は、ソフトウェアプロダクションライフサイクルの早い段階で脆弱性を発見する機会を提供し、脅威が発生する前にその機会を無効にします。

Snyk は、SBOM の構築を自動化し、企業が使用するオープンソースコンポーネントと依存関係を追跡しやすくしました。また、Snyk のサプライチェーンセキュリティソリューションではこれらの各コンポーネントをスキャンして潜在的な脆弱性を発見し、それに対する実用的な修正案を提示することもできます。SBOM の構築方法に関する投稿をご覧ください。

コンテナセキュリティ

Snyk はベースイメージで継承されているか、Linux パッケージマネージャー経由でユーザーの指示によりインストールしたかにかかわらず、コンテナに存在するパッケージを検出できます。Snyk Container は、ベースイメージやコンテナーに追加されたパッケージ (または依存関係) で脆弱性が検出されたかどうかを確認し、問題を修正する具体的なアドバイスを提供します。ベースイメージについては、Snyk Container がワンクリックで修正し、ベースイメージのより安全なバージョンにすばやく変換できるようにします。また、ユーザーの指示については、より安全なパッケージバージョンを選択するのに役立ちます。Snyk Container は、新しく発見された脆弱性についてコンテナイメージをモニタリングし、すでにビルドされたイメージで脆弱性が発見された場合に警告を発し、通常のビルドワークフローと同じ修正アドバイスを提供します。

Snyk は、さまざまな Linux パッケージマネージャーの外部にインストールされたその他のバイナリも検出します。たとえば、特に厄介なパッケージが一般的なコンテナのベースイメージに侵入したが、パッケージマネージャーを経由してインストールされなかったとします。この場合は、Snyk の検出機能を使ってパッケージを見つけることができます。ただし、これはマルウェアの検出に代わるわけではありません。 

ソフトウェアサプライチェーンセキュリティにおいて次に課題となるものとは？

ソフトウェアサプライチェーン攻撃のリスクを軽減するには、組織がリスクを内部化する意図的な措置を講じる必要があります。これには、ソフトウェア開発の性質の変化と、それによってもたらされる新たな攻撃ベクトルについての理解が関与します。また、開発チームの全員にリスクとその予防策を教育することも意味します。 

Snyk では、エコシステム全体で悪意のあるパッケージを常に研究・発見しており、サイバー脅威は時間の経過とともにさらに蔓延していることを完全に確信しています。使用するソフトウェアが増えるほど、ソフトウェアの脅威も増加します。これらのリスクを理解することは、リスクを予防・軽減するための第一歩です。

サイバーセキュリティ体制を強化する方法の詳細については、「NPM によるサプライ チェーン攻撃の防止」を参照してください。