LiveRampがSnykを活用してLog4Shellを修正した方法

Javaで構築されたWebアプリやエンタープライズソフトウェアを使用する企業と同様に、サンフランシスコを拠点とするLiveRampも、広く使われているオープンソースのロギングライブラリLog4jに存在するLog4Shellのゼロデイ脆弱性に感染していないか懸念していました。

2021年12月中旬にLog4Shellが発生したとき、顧客データを統合して企業独自のマーケティングプラットフォームに取り込むデータコネクティビティ企業のLiveRampは、SnykとのPOC（概念実証）トライアルを終えたばかりで、Snyk Open SourceとSnyk Containerの導入を始めたところでした。

LiveRampがSnykを導入した主な目的は、自動脆弱性スキャンによってCI/CDパイプラインを保護することでした。LiveRampの開発チームとセキュリティチームは、Snykが重大なゼロデイ脆弱性を検出し、修正を支援するとは予想していませんでした。

「これにSnykを使うべきだろうか、と自問しました」と、LiveRampのスタッフDevOpsエンジニア、John Jelinek氏は説明します。「GoogleもLog4Shellのようなエクスプロイトをスキャンする独自のツールを公開していましたが、私たちはSnykとのインテグレーションを進めていました。このツールはまさにこうした状況を想定して設計されているため、Log4jライブラリの存在箇所を特定するのにSnykを使うことにしました。」

SnykでLog4jの存在箇所を特定

Snykを使ってLog4jのスキャンを始めたとき、Jelinek氏とチームは、スキャンが必要なリポジトリの数や、それぞれのリポジトリの所有者を把握できていませんでした。利用中のGitHubリポジトリは1,600件ありました。Jelinek氏はSnyk APIのインポートツールを使ってGitHubリポジトリを絞り込み、Log4Shellの影響を受けやすく、Snykにインポートしてスキャンする必要のあるJavaプロジェクトを400件特定しました。2時間以内に、すべてのJavaプロジェクトをSnykにインポートできました。

Jelinek氏は社内にLog4Shell対策チームを立ち上げ、LiveRampのJavaプロジェクト内にあるLog4jの存在を検知したSnykのレポートを集め始めました。その後、レポートをセキュリティチームに渡し、影響を受けるすべてのLog4jについて脆弱性の修正に取り組みました。

Jelinek氏とチームは、400件のJavaプロジェクトのうち23%にLog4Shellの脆弱性が含まれており、修正が必要であることを突き止めました。

コンテナ内のLog4jをスキャン

次のステップでは、Snykを使ってLiveRampのGCR内のコンテナをスキャンし、Log4jを検出しました。各コンテナには500～2,000件のプロジェクトが含まれ、Javaバイナリや複数のバージョンが存在していたため、これは手間のかかる作業でした。「Log4jが含まれるコンテナイメージの数は、実際よりも多く見えていました」とJelinek氏は話します。「その多くは、すでに私たちのエコシステムで使われていないため、アーカイブする必要がありました。」

この作業には多大な労力がかかりましたが、どのコンテナを優先すべきか、どれを削除またはアーカイブすべきかをLiveRampが把握するうえで役立ちました。

Log4Shellの修正対応

LiveRampは修正の優先順位を決めました。顧客に公開される対外向けアプリケーションを最初に修正し、次に従業員が利用する社内専用のアプリケーションに対応しました。

Snykを活用し、LiveRampは年末までに外部向けアプリケーションと内部アプリケーションのすべてからLog4Shellを修正できました（Log4Shellが公表されたのは12月10日です）。「顧客向けアプリの修正には1週間かかりました」とJelinek氏は話します。「社内アプリは、おそらく2週間ほどでした。Log4jの脆弱なすべてのバージョン（2.17まで）の修正には、1月末までかかりました。」

次の脆弱性に備えて得た教訓

SnykでLog4Shellをスキャンして修正した経験から、LiveRampにはソフトウェア部品表（SBOM）が必要だとわかりました。Jelinek氏によると、Log4Shellが発生した際の課題の1つは、各マイクロサービスがどのライブラリや依存関係を使用しているかを把握することでした。LiveRampのURL、マイクロサービス、リポジトリのつながりを可視化できていなかったため、インフラ内のどこにLog4jライブラリが存在し、どのサービスが脆弱なのかを特定するのが困難でした。

「Log4Shellの脆弱性を受けて、ソフトウェアの全体像を把握することが課題になりました」とJelinek氏は話します。「現在も、その把握を進める取り組みを続けています。」LiveRampがLog4Shellの課題を乗り越えた今も、Snykは同社のオープンソース依存関係やコンテナのセキュリティ態勢をより可視化できるよう支援しています。