本文の内容は、2021年11月9日にÁlvaro Iradierが投稿したブログ(https://sysdig.com/blog/software-supply-chain-security/）を元に日本語に翻訳・再構成した内容となっております。
ソフトウェア開発における新たな脅威は、特定の企業だけに関わるものではありません。ソフトウェアのサプライチェーン全体が攻撃者の標的となっており、一つが失敗すればすべてが影響を受けるため、各リンクのセキュリティ確保に全力を尽くすことが非常に重要となっています。
サプライチェーン活動には、素材、コンポーネント、リソースを完成品に変換し、最終顧客に届けるまでの各ステップが含まれます。
各ステップは、それ自体が複雑なプロセスであり、セキュリティインシデントを引き起こす可能性があります。
ソフトウェアサプライチェーンとは
ソフトウェアのサプライチェーンは、他の活動や産業と似ています。あるリソースが消費され、一連のステップやプロセスを経て変換され、最終的に製品やサービスとしてお客様に提供されます。ソフトウェアでは、一般的なライブラリ、コード、ハードウェア、およびコードを最終的な成果物に変換するツールが素材となります。この成果物は、ユーザー向けのアプリケーション、サービス（同じサプライチェーンループからの再スタート）、または依存関係にある別の製品の一部として含まれる別のパッケージ成果物のいずれかとしてデプロイされます。
サプライチェーンは長く、非常に複雑になる可能性があります：
依存関係の簡単な例お客様に提供する最終的な「Webアプリケーション」を作成するためには、ソースコードを変換（コンパイル）し、サードパーティのサービスから情報を取得する必要があります。ソースコード自体は、別のコードから生成された外部ライブラリなどに依存しています。
ソフトウェアサプライチェーン攻撃は、このチェーンに何らかの悪意のある要素が入り込むことで起こります。
サプライチェーンのいずれかのリンクで攻撃が成功すると、侵害されたコードやコンポーネントは、まったく気づかれずに下流に伝播し、さまざまな段階で大混乱を引き起こします。
実際、このような攻撃の多くは、最終的な顧客を搾取するために、中間段階でマルウェアや脆弱性を注入してソフトウェアベンダーを危険にさらすことに焦点を当てており、致命的な結果をもたらします。
あなたの会社や製品は、ソフトウェアのサプライチェーン全体の中の一部分に過ぎないため、サプライチェーンに関連するセキュリティ対策は、3つの異なるポイントに適用することができます：
- 入力：ライブラリやパッケージの依存関係、サードパーティ製のツール、ソフトウェア、サービス、または公開されているものや民間のベンダーから提供されているものなど、消費しているあらゆる成果物。
- アウトプット：成果物の完全性を保証し、下流のコンポーネントを検証する方法を提供する。
- プロセスとインフラストラクチャー：ネットワーク、アイデンティティ、クレデンシャル、署名キー、リポジトリ、およびプロセスを保護する。
サプライチェーン攻撃とは
ソフトウェアのサプライチェーンの定義については、コード、ライブラリ、サービスを例に挙げて説明しました。しかし、もう少し深く掘り下げて、ソースコードに焦点を当ててみましょう。
ソースコードの例チェーン上の任意のリンクにズームインして、さらなる詳細を見ていきます：
この例では、ソースコードはプライベート gitリポジトリに格納されています。これはインフラの一部である場合もあれば、ベンダーが提供するSaaSである場合もありますし、コンパイラツール、ベースコンテナイメージレジストリーなども含まれます。
依存関係の中には、Docker HubやQuay.ioのようなパブリックリポジトリでホストされているものもあり、それらが危険にさらされる可能性もあります。また、私たちはアプリケーションをコンテナイメージとして公開リポジトリでも公開しています。
チェーンの中のいくつかのコンポーネント（青）は、あなたのプライベートなソースコードのgitリポジトリ、アプリケーションコード自体、そして生成される最終的なバイナリやコンテナイメージのように、あなたの傘の下にあります。しかし、それ以外の多くのコンポーネントやサービス（緑色）は、公共のサービスやリソースであったり、他社が提供しているものであったりして、あなたの管理下には全くありません。
したがって、ソフトウェアサプライチェーンの攻撃は、お客様を直接標的にすることもあれば、上流の要素（外部依存関係や提供されたサービスなど）を標的にすることもあり、お客様は、攻撃を直接受けるか、侵害されたリソースの供給者となることで被害者となります。
サプライチェーンにおける感染プロセスサプライチェーン攻撃の例
サプライチェーンへの攻撃の傾向は、年間4～5倍の指数で増加しており、昨年は数千件の攻撃がありました。最も多いのは、依存関係の混乱やタイポスクワッティングに関連したもので、次いで悪意のあるソースコードインジェクションがあります。幸いなことに、すべての攻撃が新聞に載るほど大きな影響を与えるわけではありませんが、最も関連性の高い最近の攻撃をいくつか分析してみましょう。他にも、CNCFの「Catalog of Supply Chain Compromises」には、さまざまなタイプのサプライチェーン攻撃の例がたくさん集められています。
CodeCov
CodeCov社のDockerイメージに流出した認証情報により、攻撃者はbashスクリプトを変更することができました。このスクリプトが顧客にダウンロードされて実行された結果、顧客の認証情報が漏えいし、攻撃者が顧客のgitリポジトリにアクセスできるようになりました。Monday.com、Hashicorp、Twilio、Confluentなどの複数の顧客が影響を受けました。
Solarwinds
攻撃者はSolarwinds社のネットワークに侵入し、同社のビルドプロセスに悪意のあるソフトウェアを注入することに成功しました。このマルウェア（APT29、Nobeliumに関連）は、Orion（ネットワーク管理システム）の製品アップデートの一部としてバンドルされていました。ビルドプロセスの一環として、この成果物はデジタル署名された後、何百人もの顧客によってダウンロードされました。このマルウェアが顧客のネットワークで実行されると、攻撃者は顧客の情報をスパイして盗み出しました。
この事件は、サプライチェーン攻撃がいかに下流に伝播し、複数の顧客に影響を与えるかを示すものでもあります。侵害されたOrionソフトウェアの一部として、Mimecast（クラウドサイバーセキュリティサービス企業）のメールサーバのTLS証明書の秘密鍵が流出しました。これにより、攻撃者はメールサーバに対して中間者攻撃を行い、顧客の電子メールにアクセスすることができました。
漏洩したソフトウェアは、潜在的に数千人の顧客のネットワーク内で数週間から数ヶ月間稼働していたため、Solarwinds社の攻撃の本当の影響を知ることはできないかもしれません。
Solarwindsの背後にいる攻撃者は、最近、サプライチェーンの異なる部分で同様の攻撃を再現しようとしています。たとえば、顧客に代わってクラウドサービスやその他のテクノロジーをカスタマイズ、デプロイ、管理するリセラーやその他のテクノロジーサービスプロバイダなどです。
Kaseya
Solarwinds社の攻撃とよく似ていますが、このケースでは、攻撃者はKaseyaシステムのゼロデイ脆弱性を利用しました。システムをコントロールすると、リモート管理・監視ツールであるVSAを使って、顧客のシステムでリモートコマンドを実行しました。Apple XcodeとXcodeGhost
この攻撃では、正規のXcodeプロジェクト「TabBarInteraction」のトロイの木馬化したバージョンがパブリックリポジトリで公開されました。この偽バージョンのプロジェクトを使用する開発者は、プロジェクトのビルドごとに誤ってスクリプトを実行していました。このスクリプトは、C2（command and control）サーバへの接続を開きました。
他にも、悪意のあるコードを含んだXcodeのリパッケージ版が中国のファイルホスティングサービスにアップロードされた例があります。これらのミラーサイトから危険なバージョンをダウンロードした開発者は、修正されたオブジェクトファイルを手にすることになります。このオブジェクトファイルは、iOSアプリケーションを作成する際に、最終的な実行ファイルにリンクされます。少なくとも2つのよく知られたアプリケーションがAppleの公式AppStoreに到達し、Appleの認証とコードレビューを無事通過しました。
NPMパッケージ ua-parser-js
2021年10月22日、ごく一般的なNPMパッケージであるua-parser-jsの開発者は、一部の攻撃者がLinuxおよびWindows用のマルウェアを含むパッケージの危険なバージョンをアップロードし、データ（少なくともパスワードとブラウザからのCookie）を盗むことができることを発見しました。この ua-parser-js ライブラリは、Facebook を含む多くのソフトウェアや企業のサプライチェーンの一部であり、何百万台ものコンピュータに搭載されているユーザー向けのアプリケーションの一部に使用されています。
ユニコードとコードコンパイラ – 目に見えない脆弱性
ケンブリッジ大学の研究者たちは、Unicodeなどのテキストエンコーディング規格の微妙な違いを利用して、ソースコードを標的とした新しいサプライチェーン攻撃を発見したと主張しています。Unicodeの仕組みでは、コメントやコードの一部に特殊な文字を追加することで、コードの「論理的エンコーディング」を表示とは異なる順序で動作させることができます。これにより、人間には正しく見えるコードの中に悪意のあるコードを隠し、審査手続きを回避することが可能になります。しかし、パニックに陥る前に、この問題はそれほど新しくて目に見えないものではないかもしれないこと、そしてコード提供者への信頼を確立し、適切なレビューを行うことで防ぐことができることをご理解ください。
Huaweiの追放
最後に、この例はソフトウェアサプライチェーンの攻撃として知られているものではなく、サプライチェーンのすべてのリンクにおいてプロバイダを信頼することの重要性を示すものとして掲載しています。ハードウェアのサプライチェーンも標的になる可能性があります。米国政府は何年にもわたって、中国製ネットワーク機器のセキュリティ上の脅威について、世界中の人々や米国企業に警告を発してきました：入手可能な機密情報および非機密情報に基づいて、HuaweiとZTEは外国国家の影響を受けていないとは言えず、したがって米国および当社のシステムに対するセキュリティ上の脅威となっています。
この警告は、情報が不足しており、セキュリティ上の懸念を満たすことができないことに基づいており、システムにバックドアが存在するという実際の証拠に基づいているわけではないようです。
ですから、本当の証拠は得られないかもしれませんが、信頼性の欠如は深刻で、Huaweiは2019年5月、米国で活動するあらゆる組織との取引を禁止されました。
サプライチェーンの分類法（と論争の場）
ソフトウェアのサプライチェーンのどの段階をターゲットにした攻撃も、「サプライチェーン攻撃」のカテゴリーに入ることに誰もが同意しているわけではありません。欧州連合サイバーセキュリティ機関（ENISA）は、「Threat Landscape for Supply Chain Attacks」レポートの中で、「サプライチェーン攻撃を特徴づけ、その後の分析を構造化するための分類法を提案する」としています：
しかし、同じレポート上で彼らはこう付け加えています：
“顧客が攻撃されていない、あるいはサプライヤーが攻撃されていない場合、それはおそらくサプライチェーン攻撃ではない。”
明示的に、要件を満たしていない例として以下のようなものを挙げています。
- name-squattingやbrand-hijackingのパッケージがパブリックリポジトリにアップロードされたが、それは既存のパッケージやソフトウェアリポジトリを侵害していないからである。
- 既知の攻撃に使用されていない脆弱性や意図しないエラーが発見されたが、これはサプライヤーや顧客を対象としていないため。
- 一般に公開されているソフトウェアの脆弱性により、顧客データの流出が発生したが、このケースではサプライヤーは侵害されておらず（攻撃の対象はフランスのITプロバイダー）、脆弱性は意図的なものでもなく、この攻撃のために特別に作られたものでもない。
ソフトウェアサプライチェーンを守る
ソフトウェアサプライチェーンへの攻撃は、企業の攻撃対象を広げています。現在では、サードパーティ（ソフトウェア、ハードウェア、サービスなどを含む）が、企業に影響を与える攻撃者のゲートウェイとならないようにする必要があります。従来のセキュリティと同様に、すべてを保護することは不可能です。特に、新しい種類のソフトウェアサプライチェーン攻撃が継続的に発見されています。
可能な限り保護されるために、各レイヤーのどこに注力すべきかを説明しましょう。
ソフトウェア開発のインプット
複数のプロバイダからソフトウェア成果物、ハードウェア、およびサービスを受け取る消費者として、プロバイダーが高レベルのセキュリティを適用していることを確認してください。
ソフトウェアのサプライチェーンは非常に重要になってきており、2021年5月には米国大統領が国家のサイバーセキュリティを向上させることを目的とした大統領令を発令しました。この命令を受けて、NISTは「Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028」というガイドを作成し、ソフトウェアのベンダーや開発者による検証の最低基準を推奨しています。
100%のセキュリティを実現・保証することは不可能ですので、プロバイダーに影響を与えるリスクやインシデントにも注意を払い、万が一、侵害されたコンポーネントが検出または報告された場合には、迅速に是正措置を取れるようにしておいてください。
あなたの会社におけるソフトウェア開発
コードや開発プロセスに関しては、「大統領令（EO）14028に基づくソフトウェアのベンダーまたは開発者による検証（テスト）のための推奨最小基準」に、ソフトウェア開発ライフサイクルにおける最低限の安全要件として、以下の一連の技術が記載されています。どれも見逃さないようにしましょう。
- 脅威モデルを適用して、重要なテスト対象や見落とされる可能性のあるテスト対象を特定する
- 自動テスト
- コードスキャナーを用いたコードベースの（静的）分析と、ハードコードされたシークレットを確認する
- ブラックボックステスト、ファジーテスト、ウェブアプリスキャナなどを用いた動的解析
- 同梱のソフトウェア（サードパーティの依存関係）にも同様のチェックを適用する
- 重要なバグを早急に修正する
同じソフトウェア検証の原則をInfrastructure as Codeのデプロイメントと管理にも適用する必要があり、セキュリティをシフトレフトさせましょう。SysdigがApolicyを買収したのは、IACのセキュリティに独自かつ高度に差別化して対応することで、お客様のKSPM（Kubernetes Security Posture Management）やCSPM（Cloud Security Posture Management）のユースケースを改善するためでした。
しかし、セキュリティはすべての開発段階と会社全体の文化や慣習に浸透していなければなりません。コードと開発プロセスを保護するだけでは明らかに不十分であることは、複数の組織の調査やガイドで概説されています。
- Cybersecurity and Infrastructure Security Agencyの「Defending Against Software Supply Chain Attacks」では、ソフトウェアサプライチェーンライフサイクルには6つの段階があり、「ソフトウェアは悪意のある、または不注意による脆弱性の導入のリスクがある」と考えています。
- Design
- Development and production
- Distribution
- Acquisition and deployment
- Maintenance
- Disposal
- Cloud Native Computing Foundation（CNCF）では、コミュニティが維持するドキュメント「Software Supply Chain Security Paper」を公開しています。この文書は、「サプライチェーンへの攻撃が成功した場合に、その可能性と全体的な影響を低減することができる一連の推奨事項、ツールのオプション、設計上の考慮事項」をコミュニティに提供することを目的としています。
- CNCF、Linux Foundation、VMware、Intel、Googleなどは、SLSA（Supply-chain Levels for Software Artifacts）にも取り組んでいます。これは、ソフトウェアを扱うすべての人が、ソフトウェアのセキュリティとサプライチェーンの整合性のレベルを向上させるためのセキュリティフレームワークおよび共通言語です。それぞれのレベルは、ソフトウェアが改ざんされておらず、そのソースを安全に追跡できるという、信頼性の度合いを高めるものです。
- コンテナやポッドに脆弱性や設定ミスがないかスキャンする。
- コンテナやポッドの実行時には、可能な限り低い権限で実行する。
- ネットワークを分離することで、漏洩した場合の被害を抑制する。
- ファイアウォールを使用して不要なネットワーク接続を制限し、暗号化を使用して機密性を保護する。
- 強力な認証と認可を使用して、ユーザーと管理者のアクセスを制限し、攻撃対象を制限する。
- 管理者が活動を監視し、悪意のある活動の可能性を警告できるよう、ログ監査を使用する。当社のブログ記事「”Chain “ging the Game – ランタイムがサプライチェーンをよりセキュアにする方法」では、ランタイムによる脅威の検知に関する優れた例を紹介しています。
- 定期的にKubernetesのすべての設定を確認し、脆弱性スキャンを使用して、リスクが適切に考慮され、セキュリティパッチが適用されていることを確認します。
あなたのソフトウェアは、他の企業やユーザーへのインプットです
自信を持って最適なプロバイダーを選ぶ際に適用するすべてのことは、他社やエンドユーザーのサプライヤーとして行動する際のあなたの会社にも適用されます。ソフトウェアサプライチェーンのライフサイクルの各ステップやプロセスに セキュリティを正しく実装したとしても、それを顕在化させ、納品された成果物に 具体的な対策を加える必要があります。
- ソフトウェアサプライチェーンに適用される、組織内の法規制遵守とセキュリティ認証の証拠を提示する。
- ソフトウェアの依存関係やサードパーティによる危険源を追跡する方法として、ソフトウェア部品表（SBOM）を追加する。
- 改ざんを防止し、成果物の出所を確認するために、デジタル署名を含める。
- 安全な流通経路、暗号化された通信、および信頼できるホスティングまたはストレージインフラを使用する。
まとめ
ソフトウェアサプライチェーンへの攻撃は、実は最近のことではありません。1984年にデニス・リッチーとともにチューリング賞を受賞したケン・トンプソンは、「コード」の提供者に対する信頼の重要性について、このようなスピーチをしています。彼は、トロイの木馬化したコンパイラーバイナリが、バックドア付きのUnixコマンド「login」の修正版を生成する様子を紹介しています。“あるプログラムにトロイの木馬が存在しないという記述をどこまで信用すべきか？おそらく、ソフトウェアを書いた人を信用することの方が重要だと思います。”
しかし、ソフトウェア、インフラ、依存関係がますます複雑化し、サプライチェーンを標的とした攻撃の増加率が高いことから、業界や組織はそのセキュリティにますます関心を寄せています。
この時点ですでに、ソフトウェアのサプライチェーンが、コードやライブラリからハードウェア部品まで、相互に接続された異質なピースからなる非常に複雑なネットワークであることにお気づきでしょう。そのため、一つ一つの部品やリンクのセキュリティを確保するためのアプローチは非常に異なっており、全体としてカバーすることはできません。しかし、サプライヤーであれ、コンシューマーであれ（あるいはその両方であれ）、プロセスの安全性を確保し、信頼できる検証済みのプロバイダーとの強力なコネクションを確立することに重点を置く必要があります。なぜなら、最善のセキュリティ対策を施し、自社のコードやインフラなどに全力を尽くしたとしても、自社では完全にコントロールできないサードパーティのコンポーネントに依存しているからです。そして、ソフトウェアサプライチェーンのセキュリティは、個々のリンクに依存しています。
Sysdig Secureは、お客様のソフトウェアサプライチェーンを構成するすべてのコンポーネントを保護することができます。わずか数分で設定が完了します。今すぐお試しください！