Google Cloudとコンテナの継続的なセキュリティ
本文の内容は、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社のDockerイメージに流出した認証情報により、攻撃者はbashスクリプトを変更することができました。このスクリプトが顧客にダウンロードされて実行された結果、顧客の認証情報が漏えいし、攻撃者が顧客のgitリポジトリにアクセスできるようになりました。
Monday.com、Hashicorp、Twilio、Confluentなどの複数の顧客が影響を受けました。
攻撃者はSolarwinds社のネットワークに侵入し、同社のビルドプロセスに悪意のあるソフトウェアを注入することに成功しました。このマルウェア（APT29、Nobeliumに関連）は、Orion（ネットワーク管理システム）の製品アップデートの一部としてバンドルされていました。ビルドプロセスの一環として、この成果物はデジタル署名された後、何百人もの顧客によってダウンロードされました。
このマルウェアが顧客のネットワークで実行されると、攻撃者は顧客の情報をスパイして盗み出しました。
この事件は、サプライチェーン攻撃がいかに下流に伝播し、複数の顧客に影響を与えるかを示すものでもあります。侵害されたOrionソフトウェアの一部として、Mimecast（クラウドサイバーセキュリティサービス企業）のメールサーバのTLS証明書の秘密鍵が流出しました。これにより、攻撃者はメールサーバに対して中間者攻撃を行い、顧客の電子メールにアクセスすることができました。
漏洩したソフトウェアは、潜在的に数千人の顧客のネットワーク内で数週間から数ヶ月間稼働していたため、Solarwinds社の攻撃の本当の影響を知ることはできないかもしれません。
Solarwindsの背後にいる攻撃者は、最近、サプライチェーンの異なる部分で同様の攻撃を再現しようとしています。たとえば、顧客に代わってクラウドサービスやその他のテクノロジーをカスタマイズ、デプロイ、管理するリセラーやその他のテクノロジーサービスプロバイダなどです。
Solarwinds社の攻撃とよく似ていますが、このケースでは、攻撃者はKaseyaシステムのゼロデイ脆弱性を利用しました。システムをコントロールすると、リモート管理・監視ツールであるVSAを使って、顧客のシステムでリモートコマンドを実行しました。
この攻撃では、正規のXcodeプロジェクト「TabBarInteraction」のトロイの木馬化したバージョンがパブリックリポジトリで公開されました。この偽バージョンのプロジェクトを使用する開発者は、プロジェクトのビルドごとに誤ってスクリプトを実行していました。このスクリプトは、C2（command and control）サーバへの接続を開きました。
他にも、悪意のあるコードを含んだXcodeのリパッケージ版が中国のファイルホスティングサービスにアップロードされた例があります。これらのミラーサイトから危険なバージョンをダウンロードした開発者は、修正されたオブジェクトファイルを手にすることになります。このオブジェクトファイルは、iOSアプリケーションを作成する際に、最終的な実行ファイルにリンクされます。少なくとも2つのよく知られたアプリケーションがAppleの公式AppStoreに到達し、Appleの認証とコードレビューを無事通過しました。
2021年10月22日、ごく一般的なNPMパッケージであるua-parser-jsの開発者は、一部の攻撃者がLinuxおよびWindows用のマルウェアを含むパッケージの危険なバージョンをアップロードし、データ（少なくともパスワードとブラウザからのCookie）を盗むことができることを発見しました。
この ua-parser-js ライブラリは、Facebook を含む多くのソフトウェアや企業のサプライチェーンの一部であり、何百万台ものコンピュータに搭載されているユーザー向けのアプリケーションの一部に使用されています。
ケンブリッジ大学の研究者たちは、Unicodeなどのテキストエンコーディング規格の微妙な違いを利用して、ソースコードを標的とした新しいサプライチェーン攻撃を発見したと主張しています。Unicodeの仕組みでは、コメントやコードの一部に特殊な文字を追加することで、コードの「論理的エンコーディング」を表示とは異なる順序で動作させることができます。これにより、人間には正しく見えるコードの中に悪意のあるコードを隠し、審査手続きを回避することが可能になります。
しかし、パニックに陥る前に、この問題はそれほど新しくて目に見えないものではないかもしれないこと、そしてコード提供者への信頼を確立し、適切なレビューを行うことで防ぐことができることをご理解ください。
最後に、この例はソフトウェアサプライチェーンの攻撃として知られているものではなく、サプライチェーンのすべてのリンクにおいてプロバイダを信頼することの重要性を示すものとして掲載しています。ハードウェアのサプライチェーンも標的になる可能性があります。米国政府は何年にもわたって、中国製ネットワーク機器のセキュリティ上の脅威について、世界中の人々や米国企業に警告を発してきました：
入手可能な機密情報および非機密情報に基づいて、HuaweiとZTEは外国国家の影響を受けていないとは言えず、したがって米国および当社のシステムに対するセキュリティ上の脅威となっています。
この警告は、情報が不足しており、セキュリティ上の懸念を満たすことができないことに基づいており、システムにバックドアが存在するという実際の証拠に基づいているわけではないようです。
ですから、本当の証拠は得られないかもしれませんが、信頼性の欠如は深刻で、Huaweiは2019年5月、米国で活動するあらゆる組織との取引を禁止されました。
ソフトウェアのサプライチェーンのどの段階をターゲットにした攻撃も、「サプライチェーン攻撃」のカテゴリーに入ることに誰もが同意しているわけではありません。欧州連合サイバーセキュリティ機関（ENISA）は、「Threat Landscape for Supply Chain Attacks」レポートの中で、「サプライチェーン攻撃を特徴づけ、その後の分析を構造化するための分類法を提案する」としています：
しかし、同じレポート上で彼らはこう付け加えています：
"顧客が攻撃されていない、あるいはサプライヤーが攻撃されていない場合、それはおそらくサプライチェーン攻撃ではない。"
明示的に、要件を満たしていない例として以下のようなものを挙げています。
このように、インシデントによっては、サプライチェーン攻撃に分類されるかどうかについて、世界的なコンセンサスが得られていないものもあります。
ソフトウェアサプライチェーンへの攻撃は、企業の攻撃対象を広げています。現在では、サードパーティ（ソフトウェア、ハードウェア、サービスなどを含む）が、企業に影響を与える攻撃者のゲートウェイとならないようにする必要があります。
従来のセキュリティと同様に、すべてを保護することは不可能です。特に、新しい種類のソフトウェアサプライチェーン攻撃が継続的に発見されています。
可能な限り保護されるために、各レイヤーのどこに注力すべきかを説明しましょう。
複数のプロバイダからソフトウェア成果物、ハードウェア、およびサービスを受け取る消費者として、プロバイダーが高レベルのセキュリティを適用していることを確認してください。
ソフトウェアのサプライチェーンは非常に重要になってきており、2021年5月には米国大統領が国家のサイバーセキュリティを向上させることを目的とした大統領令を発令しました。この命令を受けて、NISTは「Recommended Minimum Standards for Vendor or Developer Verification (Testing) of Software Under Executive Order (EO) 14028」というガイドを作成し、ソフトウェアのベンダーや開発者による検証の最低基準を推奨しています。
100%のセキュリティを実現・保証することは不可能ですので、プロバイダーに影響を与えるリスクやインシデントにも注意を払い、万が一、侵害されたコンポーネントが検出または報告された場合には、迅速に是正措置を取れるようにしておいてください。
コードや開発プロセスに関しては、「大統領令（EO）14028に基づくソフトウェアのベンダーまたは開発者による検証（テスト）のための推奨最小基準」に、ソフトウェア開発ライフサイクルにおける最低限の安全要件として、以下の一連の技術が記載されています。どれも見逃さないようにしましょう。
IaC（Infrastructure as Code）により、ソフトウェアのサプライチェーンにおける脅威は、ソフトウェアやアプリケーションだけでなく、基盤となるインフラも対象となる可能性があります。
同じソフトウェア検証の原則をInfrastructure as Codeのデプロイメントと管理にも適用する必要があり、セキュリティをシフトレフトさせましょう。SysdigがApolicyを買収したのは、IACのセキュリティに独自かつ高度に差別化して対応することで、お客様のKSPM（Kubernetes Security Posture Management）やCSPM（Cloud Security Posture Management）のユースケースを改善するためでした。
しかし、セキュリティはすべての開発段階と会社全体の文化や慣習に浸透していなければなりません。コードと開発プロセスを保護するだけでは明らかに不十分であることは、複数の組織の調査やガイドで概説されています。
最近では、Kubernetesやコンテナは非常に一般的になっており、NSA/CISAもKubernetes Hardening Guidanceを発表し、3つの危険源の1つとして「サプライチェーンリスク」を強調し、以下のようなハードニング対策や軽減策を提案しています。
自信を持って最適なプロバイダーを選ぶ際に適用するすべてのことは、他社やエンドユーザーのサプライヤーとして行動する際のあなたの会社にも適用されます。ソフトウェアサプライチェーンのライフサイクルの各ステップやプロセスに セキュリティを正しく実装したとしても、それを顕在化させ、納品された成果物に 具体的な対策を加える必要があります。
ソフトウェアサプライチェーンへの攻撃は、実は最近のことではありません。1984年にデニス・リッチーとともにチューリング賞を受賞したケン・トンプソンは、「コード」の提供者に対する信頼の重要性について、このようなスピーチをしています。彼は、トロイの木馬化したコンパイラーバイナリが、バックドア付きのUnixコマンド「login」の修正版を生成する様子を紹介しています。
"あるプログラムにトロイの木馬が存在しないという記述をどこまで信用すべきか？おそらく、ソフトウェアを書いた人を信用することの方が重要だと思います。"
しかし、ソフトウェア、インフラ、依存関係がますます複雑化し、サプライチェーンを標的とした攻撃の増加率が高いことから、業界や組織はそのセキュリティにますます関心を寄せています。
この時点ですでに、ソフトウェアのサプライチェーンが、コードやライブラリからハードウェア部品まで、相互に接続された異質なピースからなる非常に複雑なネットワークであることにお気づきでしょう。そのため、一つ一つの部品やリンクのセキュリティを確保するためのアプローチは非常に異なっており、全体としてカバーすることはできません。しかし、サプライヤーであれ、コンシューマーであれ（あるいはその両方であれ）、プロセスの安全性を確保し、信頼できる検証済みのプロバイダーとの強力なコネクションを確立することに重点を置く必要があります。なぜなら、最善のセキュリティ対策を施し、自社のコードやインフラなどに全力を尽くしたとしても、自社では完全にコントロールできないサードパーティのコンポーネントに依存しているからです。そして、ソフトウェアサプライチェーンのセキュリティは、個々のリンクに依存しています。
Sysdig Secureは、お客様のソフトウェアサプライチェーンを構成するすべてのコンポーネントを保護することができます。わずか数分で設定が完了します。今すぐお試しください！
