OpenSSLの脆弱性から学ぶ パート2：サプライチェーンの脆弱性を発見し、修正する
2023年4月26日
0 分で読めますこのサプライチェーンシリーズでは、OpenSSLから得られた教訓と、サプライチェーンのセキュリティ強化にあたって考慮すべき点を取り上げます。本シリーズではOpenSSLと関連ライブラリに焦点を当てますが、あらゆる領域の脆弱性についても考察します。最初の記事では、脆弱なライブラリをどこで探せばよいかについて知っておくべきことをすべて紹介しました。今回はパート2として、サプライチェーンの脆弱性を発見し、さらに重要なこととして修正する方法について解説します。
サプライチェーンの脆弱性を発見する方法
問題のあるライブラリやパッケージを探す方法は、調査対象によって異なります。ホストやVMでは、コンテナやコードとは異なる仕組みを使います。今回はソフトウェア、つまりコンテナとコードに焦点を当てます。
エコシステム全体を一元的に把握できれば、「どこが影響を受けているのか」という問いに答えやすくなります。この一元的なビューによって、アプリケーションポートフォリオ全体を可視化できます。すべてのアプリケーションと、それらを構成するコード、デプロイ先のコンテナ、そしてすべてのオープンソース依存関係を含める必要があります。この「一元的なビュー」には、各ソフトウェアコンポーネントのソフトウェア部品表（SBOM）が保存され、実行中または保管中のアプリケーションとコンテナすべてのインデックスとして機能します。
ソースコードとオープンソースライブラリ
一元的なビューは便利ですが、よく言われるように、後からなら何とでも言えます。インベントリを作成する前に（あるいは、インベントリを一元化できると知る前に）OpenSSLの発表があった可能性も十分あります。まだ一元化できていない場合に考慮すべき点と、調査すべき場所を見ていきましょう。現代のアプリケーションはオープンソースのコンポーネントやライブラリを活用しており、アプリケーションのコードの80%以上が、直接管理できないものかもしれません。そのため、これらのライブラリやパッケージがどこで使われているかを特定することが、問題の大きな部分を占めます。
カスタムアプリケーションやプロジェクトにインポートされているライブラリを見つけるのは、物理ホストを調べるよりも複雑です。プロジェクトのルートディレクトリ以下にあるrequirements.txtのすべてを対象に「openssl」を総当たりで検索する方法もありますが、あまり見つからないでしょう。すべてのプロジェクトのソースコードが1台のホストに集約されている可能性は低いだけでなく、アプリケーションがOpenSSLに依存している場合、先ほど触れた推移的依存関係を通じて依存していることも十分に（おそらくは高い確率で）あり得ます。
理想的には、各アプリケーションのソフトウェア部品表（SBOM）があれば、リスクをすぐに特定できます。しかし、まだ広く普及しているとは言えません。アプリケーションのSBOMを生成できるツールはいくつかあります。たとえばSnykは、APIとCLIコマンドsnyk sbomを提供しており、SPDX形式またはCycloneDX形式のソフトウェア部品表を生成できます。ただし、ソースコードリポジトリを1つずつ手動で確認するのは現実的ではありません。ローカルマシン上のソースコードをスキャンするのではなく、リポジトリにあるソースコードをスキャンできるソリューションが数多くあります。たとえばSnykでは、アカウントを連携して追加するリポジトリを選択するだけで、監視対象のリポジトリを登録できます。
この方法でリポジトリを連携すると、定期的にスキャンできます。これにより、プロジェクトの依存関係に潜んでいた新たに発見された脆弱性（たとえば、昨日までは知られていなかったOpenSSLの脆弱性）だけでなく、開発者が追加した脆弱性も見つけやすくなります。
コンテナイメージ
コンテナイメージもソフトウェアサプライチェーンの一部です。ワークロードを動かすだけでなく、コードやその依存関係以外のものもまとめて含んでいます。構成、パッケージ、脆弱性についてコンテナイメージをスキャンするツールは複数あります。たとえばSnyk Containerは、有料プランと無料プラン、IDEとのインテグレーション、コマンドラインインターフェイスを提供し、CI/CDパイプラインでの自動化にも対応しています。また、Syft、Grype、trivy、非公式の「docker index」ツールなど、脆弱性をチェックできるオープンソースプロジェクトもあります。docker-indexツールは、コマンドラインからCVEを見つけるために使用できます。現時点ではツール自体に署名はありませんが、コンテナ内で実行できます（何ともメタな話です）。以下は公開イメージapache/tika:2.6.0.1の例です。この記事の執筆時点でも、脆弱なバージョンのOpenSSLが残っています。読みやすさのために引数を展開していますが、-itと省略してもかまいません。
docker-indexコマンドはOpenSSLの脆弱性3602と3768を特定しますが、それ以外は検出しません。
多くのコンテナおよびオープンソースコンポーネントスキャナーは脆弱性の一覧を表示し、一部のツールは「修正済み」バージョンも示します。たとえばTrivyの出力では、docker-indexが検出できない多数の脆弱性が特定されています（以下はその一部です）。
新たに見つかった重大度HIGHのOpenSSL脆弱性2件と、その概要、「修正済み」バージョンは特定できましたが、コンテナのセキュリティ強化にはあまり役立ちません。
最初の記事でのオープンソースに関する説明と同様、コンテナイメージを1つか2つスキャンすることはできても、一般的な開発ワークフローで何百、何千ものコンテナイメージをスキャンするのは現実的ではありません。
推移的依存関係やオープンソースの場合と同様に、Ubuntuやtikaそのもののイメージを実行しているのではなく、それらをベースにしたイメージを使っている可能性が高いでしょう。その場合、元のイメージに含まれる脆弱性を引き継ぐだけでなく、ユーザー指示によって追加された脆弱性も引き継ぐため、調査はさらに複雑になります。
影響を受けている場所を把握する
ここまで見てきたように、コンテナイメージやオープンソース依存関係の脆弱なライブラリを見つけるのに役立つツールはいくつもあります。ローカルの開発環境でその都度分析するツールは、開発者が少ないプロジェクトなら使えるかもしれませんが、チームの規模やプロジェクト数が増えるにつれて扱いにくくなります。一方、アプリケーションポートフォリオの信頼できる情報源であるソースコードリポジトリやコンテナイメージレジストリと連携するツールなら、インベントリを追跡し、潜在的な影響について最新情報を得られます。たとえば、注目度の高い別の脆弱性で絞り込むと、Snyk ReportingではLog4Shellの影響を受けるプロジェクトを一元的に確認できます。総当たりの方法を使った場合でも、一元化された整理済みのビューを使った場合でも、少なくとも「どこが影響を受けているのか」という問いには答えられます。
単に発生箇所を「見つける」だけではない
ソフトウェアサプライチェーンのコードの80%以上が外部ソースに由来する可能性があると分かりました。しかし、上司が尋ねることの一部は、発生箇所を見つけるだけでは答えられません。脆弱性がある場所と修正が必要な項目の一覧が分かっても、質問の後半である「どうやって修正するのか」に答える必要があります。OSやアプリケーションの場合、「修正」とは通常、ベンダーのパッチやアップデートを待って適用することを意味します。
オープンソースライブラリやコンテナの脆弱性についても、プロジェクトメンテナーからのアップデートを待つことになるでしょう。ただし、追加の手順が必要です。メンテナー自身も、上流の別の担当者からの修正を待っている可能性があります。一般的なLinuxディストリビューションの長期サポート（LTS）版、Ubuntu 22.04を例に考えてみましょう。OpenSSLの脆弱性が公表されたとき、Ubuntu 22.04には脆弱なバージョンの1つであるOpenSSL 3.0.2（具体的には3.0.2-0ubuntu1.6）が含まれていました。Ubuntuの場合、3.0.7に移行するのではなく、3.0.2に脆弱性の修正を含むパッチを適用しました。しかし、それだけではありません。ライブラリにパッチを適用した後、Ubuntu 22.04自体のアップデートをリリースし、更新済みのコンテナイメージをビルドする必要がありました。
Ubuntuイメージを直接利用している場合（たとえばDockerfileがFROM ubuntu:22.04で始まる場合）、影響を受けるイメージの公開後に自分のイメージを再ビルドすれば、修正を取り込めます（どんな小さな変更でも検証する必要があるため、イメージをテストすることをおすすめします）。一方、新しいJammy Jellyfishをベースにしたイメージに依存する下流の利用者であれば、修正が反映されたイメージが更新されるまで、あと数回のリリースを待つ必要があるかもしれません。
前のセクションで紹介したオープンソースのコンテナスキャンツールとは異なり、Snyk Containerはイメージの依存関係ツリーをたどり、より適切なベースイメージを見つけてより安全なイメージをビルドできるよう支援します。SnykはDocker Hub上の人気のある公式イメージについて、バージョンのインデックスを管理し、定期的に更新しています。そのため、ローリングタグを使用するイメージ（マイナーバージョンを上げずに同じタグのまま更新されるイメージ）が古くなっているかどうかを特定できます。この例では、Snyk Containerが、スキャン対象のイメージのビルド後にubuntu:22.04が更新されたことを検出し、変更を取り込むために再ビルドが必要であると示しています。
Snyk Containerは、公式Dockerイメージを使っている場合も、独自のカスタムベースイメージを指定している場合も、より適切なイメージの候補を提示できます。複数の脆弱性を一度にすばやく修正できるよう、ワンクリックでプルリクエストを作成する機能も備えています。
Snykを使えば、オープンソース依存関係の脆弱性も簡単に修正できます。以下のように、脆弱なライブラリの詳細と修正済みバージョンの情報に加えて、
Snykは「Fix PR」を通じて脆弱性を修正するツールも提供しており、ワンクリックで複数の脆弱性に対処できます。
1件ずつ修正する方法では規模に対応できない場合、「どうやって修正するのか」という問いへの答えはシンプルです。「Snykで修正します」。
Snykで次のサプライチェーンの脆弱性に備える
OpenSSLの脆弱性の深刻度が引き下げられた機会を活用して、脆弱性対応のプロセスをテストしましょう。次の脆弱性にどう対応するか、関係者、影響の評価方法、調査すべきインベントリ、社内（該当する場合は社外）への調査結果と影響の伝達方法などをまとめたプレイブックやチェックリストを作成してください。何より重要なのは、プレイブックの場所を全員が把握していることです。次の重大な脆弱性が発生する前に、ソースコードやコンテナのインベントリを追跡するツールを導入し、次の脆弱性に備えましょう。
Snyk ContainerとSnyk Open Sourceを活用してソフトウェアサプライチェーンを保護すれば、コンテナやオープンソースプロジェクトを継続的に監視できます。脆弱なコンテナイメージやオープンソースパッケージの該当箇所を慌てて探すのではなく、脆弱性が公表される前に、自分たちが影響を受けるかどうかを把握できます。Slackで「送信」ボタンを押し、上司にメッセージを送るときも、必要な答えが分かっているという安心感を得られます。
ソフトウェアサプライチェーンセキュリティツールについて、またSnykがソフトウェアサプライチェーンのセキュリティ強化をどのように支援できるかについて詳しくご覧ください。今すぐ無料で利用を開始できます。
CTFを始めよう
オンデマンドのバーチャル入門ワークショップで、CTFチャレンジの解き方を学びましょう。