ということで、ソフトウェアサプライチェーンリスク管理が導入されたらどういったことが行われるのか、第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)、開発と運用の両面での対処についての記述となっているのは、サプライチェーン全体での対処を前提で書かれているからであり、これは、ソフトウェアサプライチェーンセキュリティの基本的な考え方だと思ってよい。みなさんの組織や企業が、開発されたソフトウェアの利用者だとしたら、以下のうちどの部分をどの組織が担当するのか(させるのか)と置き換えて考えてみていただきたい。
Copyright © ITmedia, Inc. All Rights Reserved.