ソフトウェアサプライチェーンセキュリティを「品質」で読み解く：ソフトウェアサプライチェーンの守り方（3）（3/4 ページ）

米国と欧州を中心に法整備が進みつつある「ソフトウェアサプライチェーン」のセキュリティについて解説する本連載。最終回となる第3回は、SBOMの流通によってどんな「良いこと」と「悪いこと」が起こるかを整理しつつ、品質保証の枠組みへの取り込みについても考察する。

[松岡 正人，MONOist]

ソフトウェアサプライチェーンリスク管理が導入されたら何が起こるのか

　ということで、ソフトウェアサプライチェーンリスク管理が導入されたらどういったことが行われるのか、第1回記事で少し触れた「Log4j」を例に、SBOMを用いたリスク管理はどのように行われるのかについて考えてみよう。

　最初に、少しだけLog4jについて振り返ってみる。「Apache Log4j」は「アパッチ ログフォージェイ」と読み、オープンソースのJavaプログラム用のロギングユーティリティーとして2001年1月8日にバージョン1.0がリリースされている。その元となるコードは1995年9月〜1998年8月にかけてEUで実施された「SEMPER」プロジェクトにおけるEコマースの汎用アーキテクチャ開発の中でJavaベースのツールキットが開発される過程で誕生し、Apacheライセンスによって配布されるオープンソースプロジェクトによるJavaアプリケーション用の標準的なロギングユーティリティーとして長く利用されている。

　システムの性能に影響が少なく、設定ファイルを構成することによってデバッグ情報、エラー情報などをJavaプログラム内からコンソール、ファイル、その他ログサーバなどに出力することができる。プログラムを書いたことがある方なら、こういった機能がどれだけ便利かよくお分かりと思うが、このユーティリティーは痒いところに手が届く便利で使いやすいものであるが故に多くのシステムに利用されており、実はICS（産業制御システム）製品やネットワーク機器などにも使用されていたのである（関連資料）。

　発見されたリモートコード実行の脆弱性は「CVE-2021-44228」として採番され、2021年12月10日に公開されたが、対象のバージョンは2.0 beta9〜2.15.0で、これらのバージョンではJava Naming and Directory Interface（JNDI）という機能が、攻撃者の制御下にあるLDAPやJNDIのエンドポイントに対して保護されないため、JNDIのメッセージ置換の機能が有効な場合、攻撃者は制御下のLDAPサーバからコードを送信することで任意のコードを遠隔実行できるというものである。この脆弱性を解消するためにバージョン2.16.0（Java 8環境向け）と2.12.2（Java 7環境向け）がそれぞれリリースされたが、対策が不完全だったため、新たにサービス拒否の脆弱性としてCVE-2021-45046が採番されたというのがLog4j問題の概要である。

　さて、上述の通り、Log4jで発見されたCVE-2021-44228は「リモートコード実行」の脆弱性であるため、悪用のリスクが高いと考えるのが妥当だろう。では、みなさんの運用しているソフトウェアにこの脆弱性が含まれている場合どう対処するだろうか？

　シノプシスのブログ記事では、基本的な対処とその手順について、以下に挙げる6つの項目で説明しているが（図5）、開発と運用の両面での対処についての記述となっているのは、サプライチェーン全体での対処を前提で書かれているからであり、これは、ソフトウェアサプライチェーンセキュリティの基本的な考え方だと思ってよい。みなさんの組織や企業が、開発されたソフトウェアの利用者だとしたら、以下のうちどの部分をどの組織が担当するのか（させるのか）と置き換えて考えてみていただきたい。

図5　6つの項目でまとめた「Log4j」の脆弱性への対処法［クリックでWebサイトへ移動］

1. Log4jコンポーネントの脆弱性の告知と緩和
   SBOMによってコンポーネントの情報を運用側が得ているため、運用しているソフトウェアにLog4jコンポーネントが含まれることが分かっており、パッチを入手することが可能に（適用と動作検証のための環境を用意する必要がある）
2. 悪用に対する感受性：入力と出力の検証
   この脆弱性は「JNDIのメッセージ置換の機能が有効な場合、攻撃者は制御下のLDAPサーバからコードを送信することで任意のコードを遠隔実行できる」というものであることから、そもそも「不正なJNDIの入力」に対して脆弱であるかどうか、また攻撃を成功させるための条件である「LDAPサーバが制御されているかどうか」「JNDIのメッセージ置換機能が有効かどうか」の検証や確認が可能に
3. ネットワークアーキテクチャとネットワークレベルのアクセス制御
   「ネットワークアーキテクチャ」と「アクセス制御ポリシー」から、そもそも攻撃が可能な条件がどのネットワーク上の端末やシステムで成立するのか検討する。また、どのような攻撃（ランサムウェアやマイニング、監視ツールなどを送り込む）の可能性があるかについての検討が可能に
4. アプリケーションのアーキテクチャ上のリスク
   Log4jコンポーネントで悪意あるリモートコード実行、影響を受ける他の端末やアプリケーションなどについての検討が可能に
5. ログを取り、監視し、異常を検知する
   上記1.〜4.までの対処を行い、実際に想定される攻撃を受けているかを監視、確認することが可能に
6. ソフトウェアコンポーネントの透明性、ベンダー管理、成熟したOSSの利用
   脆弱性対策の一環として、SBOMで共有されたコンポーネントの一覧から、それらに関連する脆弱性や、開発停止などによる影響の速やかな検討が可能に