高速化する脆弱性対応にどう向き合うか？ OWASP Dependency-Track活用術【セキュア開発技術Blog】

Securityチーム オーナーの松田です。

近年、オープンソースソフトウェア（OSS）の脆弱性公表や修正のスピードが上がっています。FIRSTが2026年6月15日に公表した脆弱性予測アップデートでも、2026年のCVE件数は当初予測を大きく上回るペースで推移しており、その背景の一つとしてAI支援による脆弱性発見の拡大が指摘されています。

AIとの厳密な因果関係が完全に立証されたわけではないものの、Webアプリケーション開発・運用の現場では、最近、サードパーティ製ソフトウェアの脆弱性対応の頻度が激増しており、これまで以上に重要になっていると実感しています。

本記事では、そうした状況に向き合うための手段として、OWASPが開発するDependency-Trackを紹介します。Dependency-Trackは、SBOMを取り込むことで、利用中コンポーネントの脆弱性を継続的に把握できるツールです。

サードパーティ製ソフトウェアの脆弱性とは

多くのWebアプリケーション開発では、Laravel、React、Djangoなどのフレームワークやライブラリを利用します。これらは、自分たちで作ったものではなく、外部の組織やコミュニティが開発・公開しているソフトウェアです。

サードパーティ製ソフトウェアの脆弱性とは、こうした外部ソフトウェアに発見される脆弱性のことです。

特徴的なのは、これらの脆弱性がリリース後の運用フェーズで新たに見つかることが珍しくない点です。つまり、リリース時点で問題がなくても、後から利用中のライブラリに脆弱性が公表されることがあります。そのため、運用中も継続的に利用コンポーネントを把握し、脆弱性情報を追い続ける必要があります。

定期的に脆弱性をチェックするには

脆弱性を継続的に確認するには、まず自分たちのアプリケーションに何のソフトウェアが、どのバージョンで含まれているのかを把握する必要があります。その助けになるのがSBOMです。

SBOMには、利用しているソフトウェアやそのバージョンなどの情報が含まれます。Dependency-Trackは、この情報を取り込んで、脆弱性データソースと照合し、影響のある脆弱性を継続的に確認できます。

Dependency-Trackを使ってみる

今回はローカル環境でDependency-Trackを動かして試してみます。2026年7月時点では、公式サイトでDocker Composeを使った起動方法が案内されています。

curl -LO https://dependencytrack.org/docker-compose.yml
docker compose up -d

起動後、http://localhost:8081にアクセスします。初回ログイン時のデフォルト認証情報はadmin / adminです。ログイン後、パスワード変更が求められます。

なお、初回起動時には脆弱性データソースの初期同期も走ります。公式ドキュメントでは、この初期ミラーリングに10分から30分以上かかる場合があるとされています。同期完了前は、SBOMを取り込んでも十分に脆弱性が表示されないことがあります。

また、画面右上のメニューから表示言語を変更でき、日本語表示も利用できます。

脆弱性情報を取り込む

Dependency-Trackは複数の脆弱性データソースを利用できます。代表的なものとして、NVD、GitHub Advisories、OSV、OSS Indexなどがあります。

管理メニューの脆弱性情報源から各データソースの設定状況を確認できます。必要に応じてMirror Nowを実行すると、手動で同期を開始できます。

今回は例としてOSVを有効にして試します。ただし、OSV連携は公式ドキュメント上でpreview featureとされているため、本番運用ではNVDやGitHub Advisoriesなども含めて、自組織に合ったデータソース構成を検討するとよいでしょう。

以下の記事が参考になります。
https://dependencytrack.github.io/docs/next/concepts/about-vulnerability-data-sources

プロジェクトを作成してSBOMをインポートする

次に、SBOMを取り込むためのプロジェクトを作成します。

Dependency-Trackにおけるプロジェクトは、アプリケーション、サービス、環境、製品バージョンなど、管理したい単位に応じて設計できます。親子関係を持たせることもできるため、アプリケーション全体を親にして、個別コンポーネントやバージョンを子として管理する構成も可能です。

プロジェクトについては、以下の記事が参考になります。
https://dependencytrack.github.io/docs/next/concepts/projects

まず、プロジェクト -> プロジェクトを作成をクリックします。

最低限、プロジェクト名を入力すれば作成できます。今回は以下のようにします。

• プロジェクト名: demo-project
• バージョン: 1.0.0
• 分類器: アプリケーション

その後、作成したプロジェクトを開き、コンポーネントタブからBOMをアップロードを選択します。

サンプルとして、以下のCycloneDX BOMをアップロードしてみます。

{
  "$schema": "http://cyclonedx.org/schema/bom-1.4.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:7f2c6b2d-2fb8-4b48-a57c-ec98ed0fa241",
  "version": 1,
  "components": [
    {
      "type": "library",
      "group": "org.apache.logging.log4j",
      "name": "log4j-core",
      "version": "2.14.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1",
      "bom-ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.14.1"
    }
  ]
}

脆弱性を見る

上記のBOMをアップロードすると、log4j-core 2.14.1に対して既知の脆弱性が検知されるはずです。たとえば、Log4Shell関連の脆弱性などが該当します。

ただし、表示結果は取り込んでいる脆弱性データソースや、その時点で同期済みの内容によって変わります。そのため、検知件数や表示される脆弱性は実施タイミングによって変動します。

脆弱性詳細の説明は英語のまま表示される場合がありますが、影響を受けるコンポーネントやバージョン、CVE、深刻度などを確認できます。

また、脆弱性の詳細画面から、同じ脆弱性が他のプロジェクトにも影響しているかを横断的に確認できます。組織全体でDependency-Trackを利用している場合は、ある脆弱性がどのアプリケーション群に波及しているかを把握しやすくなります。

修正して差分を確認する

次に、脆弱性対応としてバージョンアップしたケースを試します。

先ほどのプロジェクトに新しいバージョン1.0.1を追加し、そちらを最新バージョンとして登録します。

次に、log4j-coreを2.14.1から2.17.1に更新した想定で、以下のBOMを1.0.1にアップロードします。

{
  "$schema": "http://cyclonedx.org/schema/bom-1.4.schema.json",
  "bomFormat": "CycloneDX",
  "specVersion": "1.4",
  "serialNumber": "urn:uuid:7f2c6b2d-2fb8-4b48-a57c-ec98ed0fa241",
  "version": 1,
  "components": [
    {
      "type": "library",
      "group": "org.apache.logging.log4j",
      "name": "log4j-core",
      "version": "2.17.1",
      "purl": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1",
      "bom-ref": "pkg:maven/org.apache.logging.log4j/log4j-core@2.17.1"
    }
  ]
}

すると、2.14.1のときに比べて、主要な既知脆弱性が減っていることを確認できます。

このように、Dependency-Trackではバージョンごとに状態を分けて持てるため、修正前後の差分や、過去バージョンに残っているリスクも追跡できます。

脆弱性を継続的にトラッキングできる

Dependency-Trackの大きな利点は、SBOMを基点に、利用中コンポーネントの脆弱性を継続的に追跡できることです。

特に、以下のような用途と相性が良いと感じます。

• OSS利用状況を可視化したい
• 脆弱性管理をまず始めたい
• アプリケーションやバージョン単位で影響を把握したい
• CI/CDと連携してSBOM取り込みを自動化したい

手動でSBOMをアップロードし続ける運用は長続きしにくいため、実運用ではCI/CDパイプラインでSBOMを生成し、API経由でDependency-Trackに登録する構成が現実的です。そうすることで、ビルドやリリースのたびに最新状態を反映できます。

Dependency-Trackは「サードパーティ製コンポーネントの脆弱性を継続的に追跡する基盤」として使うのが適しています。

最後に

リリース前の脆弱性診断は引き続き重要です。一方で、運用開始後に新たに公表されるサードパーティ製ソフトウェアの脆弱性へ対応する重要性も、ますます高まっています。

有償ツールを含めて選択肢はいろいろありますが、まずはSBOMを活用した継続的な脆弱性把握を始める、という意味でDependency-Trackは有力な選択肢です。特に、SBOMをすでに生成できる環境であれば、比較的導入しやすいはずです。