ソフトウェアサプライチェーンのセキュリティ：実績あるフレームワークと戦術で脅威に先手を打つ

主なソフトウェアサプライチェーン攻撃とその原因

ソフトウェアツールが攻撃ベクトルになると、その被害は1社にとどまらず、そのツールに依存しているすべての企業に波及します。そこで、業界でよく知られている主なソフトウェアサプライチェーン攻撃とその原因、そしてこれらの重大インシデントが今も取り上げられる理由について見てみましょう。

1. SolarWinds事件：エンタープライズセキュリティに警鐘をもたらす

2020年にSolarWinds社のOrionソフトウェアが侵害された事件は、これまでで最も壊滅的な影響をもたらしたサプライチェーン攻撃の1つです。

ハッカーによって悪質なコード(後にSunburstと命名)が挿入されたOrionのアップデートが、米国の連邦政府機関や、Microsoft社を含む大手テクノロジー企業など、18,000ほどの組織に配信されました。このソフトウェアは管理者レベルのアクセス権を有していたため、攻撃者は発見されるまでの数カ月間、高度なセキュリティが施されたネットワーク内を気づかれることなく移動していました。

短期的な問題と長期的な影響

• 大規模なスパイ活動：この侵害により、攻撃者は米国財務省や国土安全保障省などの政府機関から機密データを盗み出すことができました。
• 世界的な影響：この攻撃では、米国の組織だけでなく、世界中の民間企業や政府機関も標的となり、セキュリティ侵害が連鎖的に発生しました。
• 信頼の失墜：サードパーティツールが攻撃手段になり得ることが明らかになり、これまで組織から信頼されていたエンタープライズソフトウェアでも、安全性に疑問が持たれるようになりました。

2. Log4Shell事件：小さなライブラリが極めて大きな影響を及ぼす

2021年後半、Javaのエコシステム全体で使用されているログツールのApache Log4jに、リモートコード実行(RCE)の欠陥が見つかりました。

攻撃者は、Log4Shellと名付けられたこの脆弱性を利用して、ログインや認証なしにサーバーをリモートで制御しました。

問題の広がり

• 世界的なパニック：Log4jは膨大な数のアプリケーションやシステムに組み込まれていたため、システムにパッチを適用しようとしても、多くの場合、問題がある箇所を特定することすら困難でした。
• リスクへの曝露の長期化：リスクが明らかになってから数カ月が経っても、パッチが適用されず脆弱なまま放置されているシステムが存在したため、組織はランサムウェア攻撃やデータ漏えいのリスクにさらされ続けました。
• サプライチェーンへの影響：この攻撃は、広く使用されているオープンソースライブラリに存在するたった1つの脆弱性が、中小企業から重要インフラに至るまで、エコシステム全体を危険にさらす可能性があることを知らしめました。

3. Codecov事件：CI/CDがバックドアとして利用される

2021年、Codecov社のCI/CDツールが侵害されました。その原因は、Dockerイメージの作成時に使用される資格情報へのアクセスを攻撃者に許したことでした。

これにより、攻撃者は開発者がパイプラインで使用していたBashアップローダースクリプトの改ざんに成功しました。これらのスクリプトはシークレットとトークンへのアクセス権を有していたため、攻撃者は何百もの環境から資格情報を盗み出すことができました。

さらに悪いことに、この侵害は3カ月もの間検出されませんでした。その間、攻撃者は警戒されることなく、多くの内部システムにひそかに侵入することができました。

影響と問題

• 資格情報の大規模な窃盗：何百もの組織が、APIキー、トークン、プライベートリポジトリなどの機密情報を知らないうちに盗まれました。
• 侵害の未検出：この侵害は3カ月もの間気づかれなかったため、内部システムに侵入してデータを盗み出すのに十分な時間を攻撃者に与えることになりました。
• 開発ツールに対する信頼の失墜：このインシデントによって、サードパーティのCI/CDツールに依存することのリスクが浮き彫りになり、開発パイプラインのセキュリティに対する監視の目が厳しくなりました。

脅威の発生源は？

ソフトウェアサプライチェーンに対する脅威は、その発生源によって大きく2つのカテゴリーに分類されます。

外部脅威

外部脅威は組織の外部で発生し、多くの場合、サードパーティのコンポーネント、パブリックインフラ、または保護されていない通信を標的とします。具体例としては以下のものがあります。

• 開発時に使用されるサードパーティライブラリに含まれた悪質なコード。
• 暗号化されずに転送されているアップデートやパッケージの傍受。
• コンテナやレジストリなど外部に公開されているコンポーネントの脆弱性。

内部脅威

内部脅威は、従業員のミス、アカウントの侵害、開発パイプラインのセキュリティ対策の不備など、組織の内部で発生します。

• ビルドパイプラインまたはデプロイパイプラインで使用される開発者の資格情報の漏えいまたは不正使用
• 本番環境に残されたパッチ未適用の古いコンポーネント
• 不適切に公開されているAPIや設定ミスがあるAPIによる不正アクセスやデータ漏えい

ただし、これらの脅威により無作為に攻撃されるわけではなく、ソフトウェアライフサイクルの特定のコンポーネントが標的となる傾向があります。詳しく説明しましょう。

• ソースコードの脅威：悪質なコミット、侵害されたバージョン管理システム(VCS)、サードパーティから提供された脆弱なコードなどを利用して、コードベースの完全性を標的にします。
• ビルド環境の脅威：CI/CDパイプラインを悪用して、元のソースコードを変更せずに悪質なアーティファクトを挿入します。
• 依存関係に関連した脅威：直接的または間接的な依存関係を介して脆弱性を挿入します。多くの場合、放棄または偽装されたパッケージが利用されます。
• デプロイとランタイムの脅威：設定ミス、漏えいした資格情報、古いソフトウェアなどを利用して、ライブ環境を標的にします。

安全なソフトウェアサプライチェーンを構築する方法

ソフトウェアサプライチェーンの保護は、ツールを1つインストールすれば済むというものではありません。開発ライフサイクルにおける実際のリスクを特定し、最も重要な部分に防御層を構築することが重要です。では、このアプローチについて見てみましょう。

ソースコードの保護

以下の方法で、コードベースの管理を強化できます。

• 署名付きコミットを使用する。
• ブランチ保護ルールを適用する。
• コードレビューを必須にする。

また、メインブランチへの直接プッシュを禁止したり、Gitアカウントで2要素認証を必須にしたりするといった基本的な対策も大いに役立ちます。慎重に行わないと、1つのブランチに設定ミスがあるだけで、そこが攻撃対象領域になる可能性があります。

使用するすべての依存関係のスキャンと追跡

深く考えずに何十ものオープンソースパッケージを使用していないでしょうか。直接的または間接的な依存関係を構築する前に、依存関係が自動でスキャンされるようにしてください。次に、ビルドプロセスの一環としてソフトウェア部品表(SBOM)を作成し、アプリに含まれるコンポーネントとその入手場所をいつでも確認できるようにしましょう。

これだけでも、Log4Shellのような脆弱性が新たに見つかって数日間混乱状態に陥るリスクを回避できます。これは「起こるかどうか」ではなく「いつ起こるか」の問題です。

設定管理ツールの強化

Ansible、Puppet、Chefなどのツールはインフラのデプロイ方法を制御するものであるため、悪用すればマルウェアを容易に拡散させることも可能です。このリスクを軽減するには、以下のように、プレイブックを重要なコードとして扱います。

• バージョン管理を適用する。
• シークレットへのアクセスを制限する。
• 不正な変更を監視する。

CI/CDパイプラインの厳重な保護

CI/CDパイプラインで、過剰な権限が付与されていたり、分離が適切に行われていなかったりすると、大きなリスクがもたらされます。

可能な対策としては、実行環境を分離する、資格情報を自動でローテーションする、署名付きビルドジョブを使用するといった方法があります。また、ビルドプロセス中にアテステーション(構成証明)のメタデータを生成し、ビルドの内容、ビルドに使われたシステム、ビルドの実行者を証明できるようにしましょう。

アテステーションによるビルド内容の証明

ビルドをリリースするたびに、署名付きのアテステーションを添付できます。SigstoreやCosignなどのツールは、この作業を自動化するのに役立ちます。アテステーションはアーティファクトが改ざんされていないことを証明するもので、使用された環境やツールに関する詳細情報も含めることができます。

セキュリティフレームワークへの準拠(初めての場合はSSDFを推奨)

NISTのセキュアソフトウェア開発フレームワーク(SSDF)のようなプラットフォームには、ロードマップが用意されています。まず、開発者のトレーニング、早期のコードスキャン、そしてインシデントが発生する前に脆弱性に対処するプロセスの設定から始めましょう。

SLSAレベルによるサプライチェーンのセキュリティ測定

「サルサ」と呼ばれるSLSAは、Supply-chain Levels for Software Artifactsの略で、ソフトウェアサプライチェーンの完全性を保護するために設計されたセキュリティフレームワークです。Googleによって開発されたこのフレームワークは、組織が構築、使用、配布するソフトウェアの保護に役立つベストプラクティスとコンプライアンスレベルのセットを提供します。サプライチェーンのセキュリティを段階的に強化するためのロードマップとして利用してください。

SLSAの目的は、ソースコード、ビルドスクリプト、コンテナイメージなどのソフトウェアアーティファクトが安全かつ検証可能な方法で作成され、管理されるようにすることです。特に、不正な変更の防止、トレーサビリティの確保、改ざんリスクの軽減に重点が置かれています。

SLSAは、環境の成熟度を示すモデルと考えることができ、セキュリティの成熟度がレベル1～4の4段階で定義されています。

1. SLSAレベル1：ソース管理やビルド自動化など、基本的なセキュリティ要件を満たしている。
2. SLSAレベル2：改ざん耐性のあるビルドと、認証済みの来歴(ソフトウェアがどのように構築されたのかを示す証拠)が存在する。
3. SLSAレベル3：分離された信頼性の高いビルド環境を使用するなど、さらに厳格な制御が行われている。
4. SLSAレベル4：完全性がエンドツーエンドで保証され、厳格なアクセス制御メカニズムが存在する(これが最高レベル)。

ソフトウェアサプライチェーンの保護に関するよくある質問

サプライチェーンのリスクを管理するにはどうすればよいですか？

ソフトウェアサプライチェーンのリスク管理に必要なのは、攻撃者よりも先に脆弱性を特定すること、そしてリスクの監視、評価、対応のためのシステムを導入することです。

そこで役立つのが、サプライチェーンリスク管理(SCRM)です。

SCRMの本質は、サプライチェーンに含まれるすべての要素(ベンダー、ツール、サードパーティライブラリ、クラウドプラットフォーム、さらには顧客まで)を把握し、各要素がセキュリティ態勢に与える影響を評価することにあります。

直接取引しているサプライヤーだけでなく、サプライヤーが使用しているツールやプラットフォーム、サプライヤーの環境のセキュリティ管理レベルも、全体的なリスクに影響します。SCRMを導入すれば、以下のことが可能になります。

• サプライチェーン全体のリスクを評価、分析する。
• 異常や不審な挙動を監視する。
• セキュリティ基準や規制への準拠を維持する。
• サプライチェーンのセキュリティインシデントへの準備と対応を行う。

SCRMの実践に役立つ脅威インテリジェンス、ベンダー評価、継続的監視などの機能を備えたプラットフォームが多数存在します。しかし、まずは戦略を策定することが必要です。

なぜ手動プロセスはもはや信頼できないのですか？

脆弱性の追跡、パッチの適用、コードの完全性の検証を人間の手で行っていては、現代の開発ペースに追いつけなくなり、ミスが多発することになります。手作業だけで、自動化に匹敵するスピード、規模、安全性を維持することはできません。自動化が必須となっている理由はここにあります。

脆弱性スキャン、アクセス制御、パッチ管理などのセキュリティタスクを自動化することで、問題を検出して修正し、脅威を未然に防ぐことができます。また、動きの速いCI/CDパイプラインで問題を見落とすリスクも軽減されます。

重要なイノベーションの1つは、アテステーションの自動化です。アテステーションでは、ビルドプロセスの一環として、ソフトウェアアーティファクトと、その作成者、作成時期、作成場所、作成方法に関するメタデータが生成されます。これにより、ソフトウェアが悪意を持って改ざんされていないこと、およびセキュリティ基準に準拠していることが証明されます。SigstoreやCosignなどのツールを利用することで、アーティファクトの構築時に自動で署名を付加して検証し、ソフトウェアのライフサイクル全体で信頼性の高い監査証跡を作成できます。

規制に伴う圧力や信頼性に関する厳しい要件がある業界にとって、アテステーションの自動化は便利なだけでなく、不可欠なものとなりつつあります。

SCAとSASTはソフトウェアサプライチェーンのセキュリティをどのように強化するのですか？

ソフトウェアサプライチェーンの保護に関して、よく取り上げられる主な手法が2つあります。それがSCAとSASTです。

• ソフトウェアコンポジション解析(SCA)は、オープンソースパッケージがコードベースに含まれているかどうかをチェックします。これにより、何が使用されているか、既知の脆弱性が存在するか、古いものや危険なものが含まれているかどうかがわかります。
• 静的アプリケーションセキュリティテスト(SAST)は、自分自身やチームが作成した自社コードをスキャンし、安全でないロジック、入力検証の問題、攻撃者が悪用しやすいその他のバグなどの問題を調べます。

SCAとSASTを組み合わせれば万全です。SCAは借用したコードに存在するリスクに対する防御策に、SASTはビルドしたコードのミスに対する防御策になります。サプライチェーンのセキュリティについて真剣に取り組みたいのであれば、この両方が必要です。

脅威モデリングとは？脅威モデリングがサプライチェーンのセキュリティにとって重要な理由とは？

多くの組織にとって、ソフトウェアサプライチェーンの保護は優先事項ですが、最大の課題はどこから始めればよいのか判断することにあります。ソースコード、ビルドツール、CI/CD、依存関係など、非常に多くの階層があるため、途方に暮れてしまうことが少なくありません。

ここで実践的な第一歩となるのが脅威モデリングです。脅威モデリングは、ソフトウェアシステム全体を可視化し、以下のような重要な質問を投げかけます。

• 価値のある資産は何か。
• 脆弱な部分はどこか。
• 現時点で最も重要な脅威はどれか。

すべてのコンポーネントに同じようにリスクがあるわけではありません。また、すべての脅威が単なる仮説というわけでもありません。依存関係の汚染やビルドスクリプトの改ざんのように、実際に確認されている攻撃手法もあります。脅威モデリングによって、実際のリスクに時間を割けるようになります。

OpenSSF End Users Working Groupなどの組織は、オープンソースソフトウェアの利用者向けに脅威モデルのサンプルを開発しています。このモデルは、よくあるリスクを検出し、SLSAやSSDFなどのフレームワークと関連付け、開発ライフサイクル全体でセキュリティ上の課題を特定するのに役立ちます。

基礎的なセキュリティ：ソフトウェアサプライチェーンの保護

ソフトウェアサプライチェーンの保護は、今や不可欠な要件となっています。ソフトウェアの相互接続が進んでいる今、あらゆるライブラリ、スクリプト、ツール、CI/CDジョブが攻撃ベクトルに変わる危険性を秘めています。

脅威が進化し、規制が強化される中で、ゼロトラストCI/CDやリアルタイム異常検出などが新たな標準となりつつあるのです。

まずは小さい規模で、リポジトリの保護、ビルドの隔離、あらゆる要素の検証に取り組みましょう。結局のところ、ソフトウェアの信頼性はその構築方法の信頼性から始まり、その信頼性を段階的に高めていかなければならないからです。

このブログはこちらの英語ブログの翻訳、藤盛 秀憲によるレビューです。