Amazon Inspector SBOM Generator で Java のネストされた依存関係を特定する方法

本ブログは 2024 年 2 月 12 日に公開された AWS Blog “Identify Java nested dependencies with Amazon Inspector SBOM Generator” を翻訳したものです。公開後のサービスアップデートを訳注として補足しています。

Amazon Inspector は自動化された脆弱性管理サービスであり、Amazon Web Services (AWS) のワークロードを継続的にスキャンして、ソフトウェアの脆弱性や意図しないネットワークの露出を検出します。Amazon Inspector は現在、Amazon Elastic Compute Cloud (Amazon EC2) インスタンス、Amazon Elastic Container Registry (Amazon ECR) に保存されたコンテナイメージ、および AWS Lambda に対する脆弱性レポートをサポートしています。

訳注: 2025 年 6 月の Code Security 機能の一般提供開始により、現在は GitHub および GitLab 上のソースコードリポジトリ (SAST / SCA / IaC スキャン) も対象となっています。

Java アーカイブファイル (JAR、WAR、EAR) は、Java アプリケーションやライブラリのパッケージングに広く使用されています。これらのファイルには、アプリケーションが正しく動作するために必要なさまざまな依存関係を含めることができます。場合によっては、JAR ファイルの構造の中に別の JAR ファイルが含まれ、ネストされた依存関係が生じることがあります。Java アプリケーションのセキュリティと安定性を維持するには、こうしたネストされた依存関係を特定し、管理することが不可欠です。

本記事では、ネストされた Java 依存関係を発見する際の課題への対処方法を紹介し、JAR ファイルを分析してこれらの依存関係を明らかにするプロセスを解説します。ここでは、Amazon Inspector SBOM Generator を使用して Amazon Inspector が特定する脆弱性に焦点を当てます。

ネストされた Java 依存関係を発見する際の課題

Java アプリケーションのネストされた依存関係には、古くなっているものや、共通脆弱性識別子 (CVE) に関連付けられた既知の脆弱性を含むものが存在することがあります。ここでお客様が直面する重要な問題は、分析やトリアージの際にネストされた依存関係が見落とされがちなことです。この見落としにより、脆弱性が誤検知と判断され、セキュリティリスクにつながる可能性があります。

この課題は、以下のような複数の要因から生じます。

脆弱性の量: 大量の脆弱性に直面すると、その数の多さに圧倒され、それぞれを徹底的に分析するための十分な時間とリソースを確保することが難しくなります
ツールの不足または不十分なツール: ネストされた依存関係を効果的に特定できるツール (mvn dependency:tree や OWASP Dependency-Check など) が十分に整備されていないことがよくあります。適切なツールがなければ、アプリケーションの深部に隠れた重要な依存関係を見逃す可能性があります
複雑さの理解: 複雑に絡み合ったネストされた依存関係を理解するには、特定のスキルセットと知識が必要です。こうしたスキルや知識が不足していると、効果的な分析とリスク緩和の妨げになる可能性があります

ネストされた依存関係の概要

ネストされた依存関係は、アプリケーションが必要とするライブラリやモジュールが、さらに別のライブラリやモジュールに依存している場合に発生します。これはモダンなソフトウェア開発では一般的なシナリオです。開発者は、既存のソリューションを土台にし、オープンソースコミュニティに蓄積された知見を活用するために、サードパーティライブラリを頻繁に使用するからです。

JAR ファイルの文脈では、JAR ファイルの構造の一部として別の JAR ファイルが含まれる場合に、ネストされた依存関係が生じることがあります。これらのネストされたファイルは独自の依存関係を持つことがあり、それがさらに別のライブラリに依存して、依存関係の連鎖を作り出します。ネストされた依存関係はコードのモジュール化と再利用を促進する一方で、適切に管理されないと複雑さが増し、セキュリティ上の脆弱性が生じる可能性が高まります。

JAR ファイルで使用されている依存関係を把握することが重要な理由

ネストされた依存関係がどのように構成されているかを示すために、Java アプリケーションの典型的なファイル構造を表す以下の例を見てみましょう。

例 1: Log4J の依存関係

MyWebApp/
|-- mywebapp-1.0-SNAPSHOT.jar
|   |-- spring-boot-3.0.2.jar
|   |   |-- spring-boot-autoconfigure-3.0.2.jar
|   |   |   |-- ...
|   |   |   |   |-- log4j-to-slf4j.jar

この構造には、以下のファイルと依存関係が含まれています。

mywebapp-1.0-SNAPSHOT.jar はメインのアプリケーション JAR ファイルです
mywebapp-1.0-SNAPSHOT.jar の中には、メインアプリケーションの依存関係である spring-boot-3.0.2.jar があります
spring-boot-3.0.2.jar の中には、推移的依存関係である spring-boot-autoconfigure-3.0.2.jar がネストされています
spring-boot-autoconfigure-3.0.2.jar の中には、ネストされた Log4J の依存関係である log4j-to-slf4j.jar があります

この構造は、Log4J が他のライブラリの中にネストされる形で、Java アプリケーションにネストされた依存関係が含まれる仕組みを示しています。実際のネストの深さや依存関係は、プロジェクトで使用する特定のライブラリとバージョンによって異なります。

例 2: Jackson の依存関係

MyFinanceApp/
|-- myfinanceapp-2.5.jar
|   |-- jackson-databind-2.9.10.jar
|   |   |-- jackson-core-2.9.10.jar
|   |   |   |-- ...
|   |   |-- jackson-annotations-2.9.10.jar
|   |   |   |-- ...

この構造には、以下のファイルと依存関係が含まれています。

myfinanceapp-2.5.jar はアプリケーションのプライマリ JAR ファイルです
myfinanceapp-2.5.jar の中には、メインアプリケーションが JSON 処理のために利用するライブラリである jackson-databind-2.9.10.jar があります
jackson-databind-2.9.10.jar の中には、jackson-core-2.9.10.jar や jackson-annotations-2.9.10.jar などの他の Jackson コンポーネントがネストされています。これらは jackson-databind 自体が動作するために必要な依存関係です

この構造は、JSON 操作に Jackson を使用する Java アプリケーションの例です。Jackson ライブラリは、パフォーマンスの最適化やセキュリティ修正など、さまざまな問題に対応するために頻繁に更新されるため、開発者はアプリケーションを最新かつ安全な状態に保つうえで、これらのネストされた依存関係を把握しておく必要があります。これらのコンポーネントがアプリケーション内のどこにネストされているかを詳しく把握していれば、保守やアップグレードが容易になります。

例 3: Hibernate の依存関係

MyERPSystem/
|-- myerpsystem-3.1.jar
|   |-- hibernate-core-5.4.18.Final.jar
|   |   |-- hibernate-validator-6.1.5.Final.jar
|   |   |   |-- ...
|   |   |-- hibernate-entitymanager-5.4.18.Final.jar
|   |   |   |-- ...

この構造には、以下のファイルと依存関係が含まれています。

myerpsystem-3.1.jar はアプリケーションのプライマリ JAR ファイルです
myerpsystem-3.1.jar の中では、hibernate-core-5.4.18.Final.jar がオブジェクトリレーショナルマッピング (ORM) 機能の依存関係として機能します
hibernate-validator-6.1.5.Final.jar や hibernate-entitymanager-5.4.18.Final.jar などのネストされた依存関係は、Hibernate が提供するバリデーションおよびエンティティ管理機能に不可欠です

MyERPSystem が Hibernate のバージョンと別のライブラリとの不一致 (例えば、新しいバージョンの Spring が異なるバージョンの Hibernate を想定している場合など) により運用上の問題に直面した場合、開発者は Amazon Inspector SBOM Generator が提供する詳細な情報を活用できます。このツールを使用すれば、Hibernate とそのネストされた依存関係の正確なバージョンを迅速に特定でき、互換性の問題をより早く解決できます。

JAR ファイル内で使用されている依存関係を理解することが重要な理由を、いくつか挙げます。

セキュリティ: ネストされた依存関係が古い、または既知のセキュリティ問題を抱えている場合、脆弱性をもたらす可能性があります。代表的な例は、2021 年後半に発見された Log4J の脆弱性 (CVE-2021-44228) です。Log4J は広く使用されているロギングフレームワークであり、脅威アクターがこの欠陥をリモートから悪用でき、深刻な結果を招く恐れがあったため、この脆弱性は重大なものとなりました。さらに問題を悪化させたのは、Log4J がさまざまな Java アプリケーションにネストされた依存関係として存在することが多く (例 1 を参照)、組織が Log4J を含む箇所をすべて洗い出してパッチを適用するのが困難だったことです
コンプライアンス: 多くの組織は、ライセンス、規制、またはセキュリティ上の理由から、サードパーティライブラリに関する厳格なポリシーを順守する必要があります。依存関係、特に Log4J のケースのようなネストされた依存関係を把握していないと、これらのポリシーに違反する可能性があります
保守性: 適切なタイミングで更新や置き換えを行うためには、プロジェクト内の依存関係を常に把握しておくことが不可欠です。Jackson ライブラリ (例 2) は、新機能の導入やセキュリティ脆弱性の修正のために頻繁に更新されます。特にライブラリがネストされた依存関係である場合、これらの更新の管理は複雑になる可能性があります
トラブルシューティング: 依存関係の特定は、運用上の問題を迅速に解決するうえで重要な役割を果たします。その一例が、バージョンの不一致に起因する、アプリケーション内の Hibernate と他の Java ライブラリやフレームワーク間の互換性問題への対処です (例 3)。このような問題は、予期しない例外やパフォーマンスの低下として現れることが多いため、関係するライブラリを正確に把握する必要があります

これらの例からわかるように、目の前の脅威から保護し、アプリケーションの長期的な健全性とコンプライアンスを確保するには、JAR ファイルの内容を詳細に把握できる状態にしておく必要があります。

既存ツールの限界

Java アプリケーションのネストされた依存関係を分析する際の主な課題の 1 つは、既存のツールではこれらの依存関係の正確な場所を効率的に絞り込めないことです。この問題は、mvn dependency:tree や OWASP Dependency-Check をはじめとする同様の依存関係分析ソリューションで特に顕著です。

Java アプリケーションのネストされた依存関係を分析するツールは存在するものの、いくつかの重要な領域で不十分なことがよくあります。以下に、これらのツールの一般的な限界を挙げます。

依存関係ツリーの深さの不足: 既存のツールはプロジェクトの依存関係を階層的に表示しますが、多くの場合、ネストされた依存関係、特に他の JAR ファイル内に埋め込まれているものを明らかにするほど深くは掘り下げられません。ネストされた依存関係はライブラリ内に再パッケージ化されており、標準の依存関係ツリーではすぐには見えません
具体的な場所情報の欠如: これらのツールは通常、JAR ファイル内のネストされた依存関係の正確な場所を特定するために必要な粒度の情報を提供しません。大規模で複雑な Java アプリケーションでは、特定の依存関係、特に深く埋め込まれているものを特定して対処するのが難しい場合があります
大規模プロジェクトにおける複雑さ: 依存関係が広範かつ複雑に絡み合ったプロジェクトでは、これらのツールは明確で実用的な洞察を提供するのに苦労することがあります。出力が複雑で扱いにくくなり、重要な依存関係を特定するための明確な道筋が得られないことがあります

Amazon Inspector SBOM Generator によるツールの限界への対処

Amazon Inspector SBOM Generator (Sbomgen) は、Java アプリケーションのネストされた依存関係の特定において大きな進歩をもたらします。依存関係の監視という概念自体はソフトウェア開発において十分確立されていますが、AWS はソフトウェア構成の複雑さに対する可視性を高めるためにこのツールを設計しました。コンテナイメージのソフトウェア部品表 (SBOM) を生成することで、Sbomgen は、従来のツールでは見落とされがちな隠れたネストされた依存関係を含む、システムにインストールされたソフトウェアの詳細なインベントリを提供します。この機能は既存のツールキットを補完し、アプリケーションの依存関係構造をより詳細かつ実用的に理解できるようにします。

Sbomgen は、インストールされたパッケージに関する情報を含むファイルをスキャンすることで動作します。該当するファイルが見つかると、パッケージ名、バージョン、その他のメタデータなどの重要なデータを抽出します。その後、このメタデータを CycloneDX SBOM に変換し、依存関係の構造化された詳細なビューを提供します。

Sbomgen のインストール方法については、Amazon Inspector ユーザーガイドの「Sbomgen のインストール」を参照してください。

訳注: 本記事公開時点の Amazon Inspector SBOM Generator は v1.0 系ですが、2026 年 8 月時点の最新は v1.13 系です。対応エコシステムは Go / Rust バイナリや Windows アプリケーションなどに大幅に拡大しているほか、v1.13 では Lua で独自のパッケージコレクタを追加できるプラグインシステムが導入されました。詳細は “Amazon Inspector SBOM Generator をプラグインで拡張” を参照してください。本記事のコマンドは翻訳時点の最新バージョン(v1.13 系)で動作することを確認していますが、最新の構文は Amazon Inspector SBOM Generator のドキュメントを参照してください。

Sbomgen の主要な機能の 1 つは、各依存関係への明示的なパスを提供できることです。

例えば、コンパイル済みの JAR アプリケーション MyWebApp-0.0.1-SNAPSHOT.jar がある場合、Sbomgen で以下の CLI コマンドを実行できます。

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

出力は以下のようになります。

{
  "bom-ref": "comp-11",
  "type": "library",
  "name": "org.apache.logging.log4j/log4j-to-slf4j",
  "version": "2.19.0",
  "hashes": [
    {
      "alg": "SHA-1",
      "content": "30f4812e43172ecca5041da2cb6b965cc4777c19"
    }
  ],
  "purl": "pkg:maven/org.apache.logging.log4j/log4j-to-slf4j@2.19.0",
  "properties": [
...
    {
      "name": "amazon:inspector:sbom_generator:source_path",
      "value": "/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/BOOT-INF/lib/logback-core-1.4.5.jar/BOOT-INF/lib/log4j-to-slf4j-2.19.0.jar/META-INF/maven/org.apache.logging.log4j/log4j-to-slf4j/pom.properties"
    }
  ]
}

この出力では、amazon:inspector:sbom_generator:source_path プロパティが特に重要です。このプロパティは、アプリケーションの構造内における特定の依存関係 (この場合は log4j-to-slf4j) の場所への明確で完全なパスを提供します。このレベルの詳細な情報は、以下のような理由から極めて重要です。

正確な場所の特定: 各依存関係の正確な場所を迅速かつ正確に特定できます。これは、通常は見つけにくいネストされた依存関係の場合に特に役立ちます
効果的なリスク管理: 依存関係の正確なパスがわかると、これらの依存関係に関連するセキュリティリスクをより効率的に評価し、対処できます
時間とリソースの効率化: 依存関係を手動で追跡・分析するために必要な時間とリソースを削減し、脆弱性管理プロセスを効率化します
可視性と透明性の向上: アプリケーションの依存関係構造をより明確に理解できるようになり、全体的な管理と保守の改善に貢献します
包括的なパッケージ情報: Sbomgen が提供する名前、バージョン、ハッシュ、パッケージ URL を含む詳細なパッケージ情報により、各依存関係の詳細を十分に理解でき、正確な脆弱性の追跡とソフトウェアの整合性検証に役立ちます

脆弱な依存関係への対処

Java JAR ファイル内のネストされた依存関係を特定したら、次はそれらの依存関係が古くなっていないか、脆弱性がないかを検証する必要があります。Amazon Inspector は以下を行うことで、この検証を支援します。

発見された依存関係を既知の脆弱性のデータベースと比較する
脆弱な可能性のある依存関係のリストを、関連する CVE の詳細情報とともに提供する
依存関係をより新しく安全なバージョンに更新するなど、リスクを緩和する方法についての推奨事項を提供する

Amazon Inspector をソフトウェア開発ライフサイクルに統合することで、Java アプリケーション内の脆弱なネストされた依存関係を継続的に監視し、アプリケーションの安全性とコンプライアンスの維持に必要な措置を講じることができます。

まとめ

Java アプリケーションの安全性を高めるには、ネストされた依存関係の管理が欠かせません。Amazon Inspector は、JAR ファイル内の脆弱な可能性のある依存関係を自動的かつ効率的に検出し、対処する方法を提供します。Amazon Inspector の機能を活用することで、Java アプリケーションのセキュリティポスチャを改善し、ベストプラクティスに準拠させることができます。

本記事に関するご質問がある場合は、AWS サポートにお問い合わせください。

Amazon Web Services ブログ

Amazon Inspector SBOM Generator で Java のネストされた依存関係を特定する方法

ネストされた Java 依存関係を発見する際の課題

ネストされた依存関係の概要

JAR ファイルで使用されている依存関係を把握することが重要な理由

例 1: Log4J の依存関係

例 2: Jackson の依存関係

例 3: Hibernate の依存関係

既存ツールの限界

Amazon Inspector SBOM Generator によるツールの限界への対処

脆弱な依存関係への対処

まとめ

お役立ちリンク

フォローお願いいたします

学ぶ

リソース

デベロッパー

ヘルプ