OpenSSLの脆弱性から学ぶ パート1：次の重大な脆弱性に備えるサプライチェーン

季節外れの暖かさとなった10月の火曜日、まだ朝早い時間。今日最初のコーヒーや紅茶を楽しみながらメールを確認していると、OpenSSLから重大な脆弱性を修正するリリースが間もなく公開されるという知らせを目にし、思わず飲み物を吹き出しそうになります。すぐにHeartbleedの記憶がよみがえります。急いで上司へのSlackメッセージを書き始めますが、「送信」をクリックする直前に、上司から必ず聞かれることに気づきます。影響を受ける箇所はどこで、どう修正するのか？

OpenSSLプロジェクトチームは、この脆弱性についておよそ1週間前に慌ただしい予告を出しました。そして、バージョン3.0.7で修正された内容をようやく公開した際、深刻度を「高」に引き下げ、新たに2件の脆弱性を公表しました。しかし、これが次のHeartbleedだったらどうでしょう？備えはできていますか？影響を受けているか、受けているならどこなのか、どうすれば把握できるでしょうか？どこを調べればよいのでしょう？広く使われているライブラリに新たな重大な脆弱性が見つかるかどうかではなく、いつ見つかるかが問題なのです。

この2回シリーズでは、ソフトウェアサプライチェーン内で脆弱性のある箇所を見つける際に考慮すべき点をいくつかご紹介します。OpenSSLと関連ライブラリを中心に取り上げますが、さまざまな脆弱性についても考えていきます。まずは、脆弱なライブラリをどこで探せばよいかを確認し、検索に役立つヒントやテクニックをご紹介します。

サプライチェーン内の脆弱なライブラリを探す場所

新たに公表された2件のOpenSSL CVE（CVE-2022-3602とCVE-2022-3786）は、どちらもOpenSSLのバージョン3.0.0から3.0.6に影響するバッファオーバーフローの問題です。幸い、実環境でより広く使われている1.x系のバージョンは影響を受けませんでした。「よかった。OpenSSL v3がインストールされているホストをすべて調べればいいんだ」と思うかもしれません。これは正しい一歩ですが、ほかにも考慮すべきことがあり、脆弱なバージョンが潜んでいる場所や形態はほかにもたくさんあります。

ホスト、VM、コンテナイメージ

ワークロードの実行に使うリソースは、一般にサプライチェーンの一部とは見なされませんが、見落とさないようにしましょう。影響を受けるバージョンのOpenSSLがないか、サーバー、デスクトップ、ノートパソコン、ワークステーションなどの物理ホストを確認するだけでなく、仮想ホストも考慮する必要があります。自社のハイパーバイザー上で稼働する仮想マシン（VM）だけでなく、AWS、GCP、Azureなどのクラウドプロバイダー上のコンピューティングインスタンスも対象です。EC2、GCEなど、どのような名称のクラウドインスタンスも、悪用される可能性があります。適切なクラウドおよびネットワーク設定により、これらのインスタンスへのアクセスを制限できますが、検索可能なインベントリを維持するのが最善です。ホストにエンドポイント保護をインストールするか、AWS Inspectorのようなネイティブのクラウドツールを使えば、AWS環境全体でEC2を含むAWSワークロードを検出できます。この記事では、ソフトウェア面に焦点を当てます。

物理ホストや仮想ホストに加えて、調査対象となった組織の90%以上は、スキャンがやや難しい動的かつ一時的なコンテナ化ワークロードやサーバーレスワークロードも実行しています。こうしたワークロードは短期間で終了することがあるため一時的であり、スケジュールやイベントをきっかけに起動することがあるため動的です。そのため、実行中のコンテナだけでなく、インベントリにあるコンテナイメージも確認する必要があります。イメージは数百から数千に及ぶこともあります。

コンテナイメージは通常、Docker Hub、Quay、JFrog Artifactoryなどのコンテナレジストリや、クラウドベンダーが提供するイメージリポジトリに保存されています。また、イメージはワークロードとしてデプロイされたり、ほかのイメージの基盤、つまりベースイメージとして使われたりします。脆弱性は依存関係を通じて波及することがよくあります。コンテナイメージ内に脆弱なパッケージが見つかった場合、そのイメージから`FROM`して作られた派生イメージも影響を受けている可能性があり、その可能性は非常に高いといえます。

ここまでで、「ホスト」（物理、仮想、一時的）の観点からOpenSSLを探す場所がわかったはずです。これらの場所では、パッケージマネージャー（たとえば`brew (or yum, or apt) install openssl`）を使って、あるいはダウンロードしたパッケージを手動でインストールして、OpenSSLを導入している可能性があります。しかし、脆弱なパッケージがシステムに入り込む経路はほかにもあります。

ソースコードと依存関係

たとえば、ほかのホストとのSSH接続のために、ホストに特定バージョンのOpenSSLをインストールしているかもしれません。こうした最上位のインストールが脆弱かどうかにかかわらず、利用しているソフトウェアや、開発してデプロイするソフトウェアによって、さらに追加のインスタンスがインストールされることがあります。コードがOpenSSLライブラリに直接依存していると、こうしたインスタンスがサプライチェーンに入り込みます。たとえば、アプリケーションの依存関係として、`requirements.txt`、`pom.xml`、`Gemfile`などにOpenSSLライブラリを指定している場合です。また、依存関係が何層も深くても、アプリケーションの依存関係ツリーに含まれる何かがOpenSSLを必要としている場合もあります。たとえば、アプリが補助ライブラリを利用し、そのライブラリが暗号ライブラリに依存している、といった依存が連鎖した結果、依存関係ツリーをたどると、途中のライブラリは3行の`Gemfile`に見当たらないにもかかわらず、「qux」というライブラリがOpenSSL 3.05を取り込んでいることがわかる場合があります。アプリケーションの依存関係ツリーにOpenSSLライブラリが含まれていれば、アプリケーションのソフトウェア部品表（SBOM）にもOpenSSLライブラリが含まれます。

パッケージマネージャーを介さず、アプリケーション開発者がOpenSSLライブラリをアプリケーションに直接コピーして同梱する場合もあります。この場合、外部ライブラリが存在することに依存せず、ビルドプロセス中にライブラリがアプリケーションに埋め込まれます。

Snykで次のサプライチェーン脆弱性に備える

Snyk ContainerとSnyk Open Sourceを活用してソフトウェアサプライチェーンを保護すれば、コンテナやオープンソースプロジェクトを先回りして監視できます。脆弱なコンテナイメージやオープンソースパッケージを急いで探し回るのではなく、脆弱性が公開される前に影響の有無を把握できます。Slackで上司にメッセージを送るため「飛行機」アイコンをクリックする際にも、答えを把握しているという安心感を得られます。

まだSnykアカウントをお持ちでなければ、今すぐ無料で作成して、検索にかかる時間と手間を節約しましょう。来週は、サプライチェーンの脆弱性を見つけて修正する方法について、引き続きご紹介します。