JARの奥深くに埋もれたネストされた依存関係は、Log4Shellの教訓が示すとおり脆弱性の温床になりがちです。本記事ではAmazon Inspector SBOM Generatorを使い、Javaアプリのネストされた依存を明示的なパスまで特定し、脆弱性を検出して緩和し、CI/CDへ段階的に組み込むまでの実践的な流れを解説します。

Javaのネスト依存が招く脆弱性リスクとLog4Shellの教訓

ネストされた依存関係とは、アプリが直接指定したライブラリがさらに別のライブラリを必要とし、その依存がまた次の依存を呼ぶという連鎖を形成する構造を指します。推移的依存とも呼ばれ、宣言していないコードが実行時のクラスパスに取り込まれる点が特徴です。多くの従来ツールは直接依存の一覧は把握できても、JARの内部に畳み込まれたライブラリまでは追い切れず、脆弱性のエクスポージャが静かに増大していきます。

この危うさを世界規模で突きつけたのがLog4Shellでした。CVE-2021-44228として知られるこの欠陥は2021年後半に発見された広く使われるロギングフレームワークLog4Jの深刻な脆弱性で、AWSの解説によれば脅威アクターがリモートから欠陥を悪用でき、深刻な結果を招く恐れがあったと説明されています。具体的なスコアの断定は避けますが、影響範囲の広さと悪用のしやすさが大きな問題でした。

Log4Shellが長期にわたり深刻化した核心は、Log4Jが数え切れないほどのJavaアプリケーションにネストされた依存として存在していた点にあります。フレームワークが内部で抱えるライブラリの一部として埋め込まれ、各インスタンスの所在を特定してパッチを当てる作業が極めて困難でした。たとえばLog4Jに関連するモジュールが、実行可能JARの中のSpring Bootのライブラリ、さらにその自動構成モジュールという階層の内側にネストされていると、表面的な依存リストを眺めるだけでは存在にすら気づけません。階層の奥まで正確にたどれる仕組みが要ります。

Amazon Inspector SBOM Generatorとは何か

Amazon Inspector SBOM Generatorは、略してSbomgenと呼ばれるスタンドアロンのツールで、実行バイナリの名前はinspector-sbomgenです。生成するのはCycloneDX形式のソフトウェア部品表、いわゆるSBOMで、ドキュメントの例ではspecVersion 1.5として出力されます。対応する入力はアーカイブ、コンテナイメージ、ディレクトリ、ローカルシステム、コンパイル済みのGo/Rustバイナリで、検出できるパッケージタイプにはJavaを含む多数の言語が含まれます。

Sbomgenは、ECRやLambda、EC2のエージェントレススキャンといったAmazon Inspectorのマネージドスキャンを支える基盤技術でもあり、スタンドアロン版は同じ技術をローカルやパイプラインから直接呼び出せます。動作環境はLinuxのみで、推奨スペックは4コアCPUと8GBのメモリです。ローカルにキャッシュ済みのイメージを解析する場合はDockerが必要ですが、tar形式で書き出したイメージやリモートレジストリのイメージにはDockerを必要としません。入手先はAWSの公式配布で、amd64とarm64それぞれのzipがS3から提供されています。

インストールは配布物を展開して実行権限を付与し、バージョンを確認するだけです。

unzip inspector-sbomgen.zip
chmod +x inspector-sbomgen
./inspector-sbomgen --version

Javaの実行可能JARを対象にする場合、AWSのブログでは次のコマンドが例として示されています。以下はブログ掲載のとおりの引用であり、--scanners java-jarという指定はブログ記載の一例です。現行CLIの一般仕様として断定するものではなく、バージョンによって指定方法が異なる可能性がある点は念頭に置いてください。

./inspector-sbomgen localhost --path /path/to/MyWebApp-0.0.1-SNAPSHOT.jar --scanners java-jar

JAR内のネスト依存を解析し明示的なパスを特定する仕組み

SbomgenのJava依存関係スキャンはパッケージマネージャとしてMavenを前提とし、対応アーティファクトはコンパイル済みのJavaアプリすなわち.jar、.war、.earと、ビルド定義であるpom.xmlです。推移的依存の収集と再帰的なスキャンの双方に対応し、直接依存の背後に隠れた連鎖を掘り下げられます。解析ではまず含まれるすべての.jar、.war、.earにSHA-1ハッシュを生成し、完全性とトレーサビリティを担保します。続いて埋め込まれたpom.propertiesからversionやgroupId、artifactIdを収集し、さらにネストされたpom.xmlをパースします。パース対象はリポジトリ内のスタンドアロンなファイルとコンパイル済み.jar内部のファイルの両方です。

解析結果の各コンポーネントには、依存関係への完全なパスを示すsource_pathプロパティが付与されます。プロパティ名は次のとおりで、これが正体を突き止める要になります。

amazon:inspector:sbom_generator:source_path

Spring Bootの実行可能JARのようにライブラリを内包したJARでは、このパスはBOOT-INF/libを何段も経由する入れ子として表現されます。次の文字列で、どのライブラリがどこにネストされているかを追えます。

/tmp/MyWebApp-0.0.1-SNAPSHOT.jar/BOOT-INF/lib/spring-boot-3.0.2.jar/BOOT-INF/lib/spring-boot-autoconfigure-3.0.2.jar/BOOT-INF/lib/logback-classic-1.4.5.jar

具体例で見てみましょう。JSON処理でよく使われるJacksonは、直接依存としてjackson-databind-2.9.10.jarを宣言していても、その内側にjackson-core-2.9.10.jarやjackson-annotations-2.9.10.jarをネスト依存として抱えます。ORMのHibernateも同様で、直接依存のhibernate-core-5.4.18.Finalの背後にhibernate-validator-6.1.5.Finalやhibernate-entitymanager-5.4.18.Finalがネストされます。source_pathがあれば、奥まったコンポーネントの正体と位置を取り違えません。なお、脆弱性評価はMaven Centralリポジトリのみに対応し、JBoss Enterprise Maven Repositoryのようなサードパーティは対象外です。ネストされたpom.xmlの解析を外すには--skip-nested-pomxmlという引数も用意されています。uberやfat、shadedといった呼び名は一般的な説明の語にとどめ、AWSが特定のプラグイン対応を明言したとは扱いません。

検出からCVE提示と緩和までInspectorがつなぐ流れ

部品表が揃えば、次は脆弱性の照合です。Amazon Inspectorがつなぐ流れは大きく三段階で整理できます。第一に、発見された依存を既知脆弱性データベースと突き合わせます。第二に、脆弱と判定された依存の一覧と、それに紐づくCVEの詳細情報を提示します。第三に、より新しく安全なバージョンへの更新といった緩和策を推奨します。開発者は当てずっぽうではなく、根拠のある優先順位で対処できます。

Sbomgenで生成したSBOMは、Inspector Scan APIのScanSbom操作へ送ることで脆弱性検出にかけられます。サブコマンドに--scan-sbomを付ければ、生成とスキャンを単一のコマンドで実行でき、archive、binary、container、directory、localhostの各サブコマンドで利用できます。認証は--aws-profileや--aws-region、--aws-iam-role-arnといったフラグかAWS_*系の環境変数で行い、InspectorScan-ScanSbomへのread権限が必要です。出力は--scan-sbom-output-formatでcyclonedxかinspectorを選べます。

./inspector-sbomgen container --image alpine:latest \
                          --scan-sbom \
                          --aws-profile your_profile \
                          --aws-region your_region \
                          --scan-sbom-output-format cyclonedx \
                          --outfile /tmp/inspector_scan.json

運用上の重要な制約として、Inspector Scan APIは5,000パッケージを超えるSBOMを処理せず、超過した場合はHTTP 400を返します。多数のイメージをまとめて投げず、対象を適切な単位に分割してスキャンする設計が現実的です。

CI/CDパイプラインへ段階的に組み込む運用術

運用は一度に完成形を目指すより段階的に積み上げると定着します。まず最初の段階は可視化です。開発端末やビルド環境で対象のJARにlocalhostと--scanners java-jarを使い、ネスト依存とその明示的なパスを確認し、何がどこに埋まっているかをチームで共有します。次の段階は成果物化です。CIパイプラインでcontainerやarchive、directoryを実行し、CycloneDX形式のSBOMを成果物として保存すれば、リリースごとに部品表が残り、後から構成を振り返れます。

三つ目の段階はゲート化です。--scan-sbomでInspector Scan APIへ送ってCVEを検出し、あらかじめ決めたしきい値でパイプラインを通すか止めるかを判断します。四つ目は更新と再スキャンで、Inspectorの推奨に沿って該当依存を安全なバージョンへ引き上げ、もう一度スキャンして継続的にモニタリングします。この段階的な流れは、Log4Shellのときに難所だった所在特定とパッチ適用を日常業務に組み込む発想だと言えます。

CI環境での実務を助けるオプションもいくつかあります。進捗インジケータがログを乱すのを避けたいときは--disable-progress-barが使えます。スキャン対象は既定で200MB以下となり、--max-file-sizeで調整できます。不要なファイルを一括で外すにはcontainer向けの--skip-filesやvolume向けの--exclude-suffixが役立ちます。なお、GitHub ActionsやJenkinsといった具体的なパイプライン設定はブログ本文にあるわけではなく、あくまで考え方の一例です。実装ではAWSのCI/CD統合のドキュメントを一次根拠として確認し、公式手順であるかのように断定しない姿勢が安全です。速度や検出率といったベンチマーク数値や公式情報にない機能は示唆せず、まずは手元のJARひとつの可視化から第一歩を踏み出してみてください。