Dependency Trackの導入と連携

Backstage のプラグインで拡張性を理解したうえで、本ドキュメントでは OWASP Dependency-Track を導入し、Backstage 上でコンポーネントごとの SBOM（部品表） と脆弱性状況を可視化するまでを解説します。これにより、カタログ上の各サービスから「このサービスは今どんな脆弱性を抱えているか」を一目で把握できるようになります。

---

1. Dependency-Trackとは

OWASP Dependency-Track は、SBOM を中心に据えた継続的な SCA（Software Composition Analysis：ソフトウェア構成分析） プラットフォームです。

• アプリが利用する オープンソース依存関係を棚卸しし、既知の脆弱性（CVE）・ライセンス・古さを継続的に追跡する。
• スキャン時点ではなく SBOM を取り込んで保持するため、後から公表された脆弱性も既存コンポーネントに遡ってマッチングできる。
• 脆弱性情報は NVD・GitHub Advisories・OSV・Sonatype OSS Index などのデータソースと同期する。

SBOM（CycloneDX）との関係

Dependency-Track は CycloneDX 形式の SBOM を入力とします。SBOM は「ソフトウェアの部品表」であり、依存ライブラリとそのバージョン・ハッシュ・ライセンスを列挙したものです。

関連ドキュメント

SBOM と脆弱性診断の基礎はSBOMと脆弱性診断を、より広い文脈はDevSecOpsと静的セキュリティスキャンを参照してください。

---

2. Dependency-Trackの構築

Dependency-Track は API Server と Frontend（SPA） の 2 コンポーネントで構成されます。Frontend は API Server を呼び出すだけのため、API Server が中核です。

デプロイ方法

最小構成は Docker Compose で起動できます。

# docker-compose.yml（抜粋・概念図）
services:
  dtrack-apiserver:
    image: dependencytrack/apiserver
    volumes:
      - dtrack-data:/data        # 永続化（H2 既定だが本番は外部 DB 推奨）
    ports:
      - "8081:8080"
  dtrack-frontend:
    image: dependencytrack/frontend
    environment:
      - API_BASE_URL=http://localhost:8081
    ports:
      - "8080:8080"
volumes:
  dtrack-data:

項目	推奨
本番デプロイ	Kubernetes（公式 Helm チャート）または マネージドコンテナ
データベース	PostgreSQL（H2 は評価用途のみ）
メモリ	API Server に 最低 4GB 程度を割り当てる（脆弱性 DB のミラーリングが重い）

初期設定と API キーの発行

1. Frontend にアクセスし、初期管理者（admin）でログイン後にパスワードを変更する。
2. 脆弱性データソース（NVD・OSV・GitHub Advisories）の同期を有効化する。
3. Administration → Access Management → Teams で CI 用のチームを作り、API キーを発行する。
4. そのチームに BOM_UPLOAD / VIEW_PORTFOLIO など必要な権限のみを付与する（最小権限）。

API キーは Secret として扱う

発行した API キーは CI/CD の シークレットストア（GitHub Actions Secrets 等）に保存し、リポジトリやログに残さないこと。

---

3. SBOMの取り込み

CycloneDX SBOM の生成

言語ごとに CycloneDX 公式ツールが用意されています。

言語 / エコシステム	生成ツール
.NET	dotnet CycloneDX（CycloneDX .NET tool）
Node.js	@cyclonedx/cyclonedx-npm
Java	cyclonedx-maven-plugin / cyclonedx-gradle-plugin
Python	cyclonedx-py
汎用（コンテナ等）	syft（複数エコシステムを横断検出）

BOM アップロード API

生成した SBOM は BOM Upload API に PUT します。autoCreate=true を付けると、初回でも対象プロジェクトを自動作成します。

curl -X POST "https://dtrack.example.com/api/v1/bom" \
  -H "X-Api-Key: $DTRACK_API_KEY" \
  -F "autoCreate=true" \
  -F "projectName=payment-api" \
  -F "projectVersion=1.4.0" \
  -F "[email protected]"

CI/CD パイプラインからの自動アップロード

SBOM 生成とアップロードはビルドの標準ステップに組み込みます。

プロジェクト命名とバージョン

projectName はカタログの Component 名と揃えると連携が容易になります。projectVersion にはリリースバージョンやコミット SHA を入れ、どのビルドの SBOM かを追跡できるようにします。

---

4. Backstageとの連携

@backstage-community/plugin-dependencytrack（コミュニティプラグイン）を使うと、エンティティページに脆弱性サマリを表示できます。

導入の流れ

1. プラグインの導入 — フロントエンドにカードを追加し、Component の Overview などに配置する。

2. プロキシ設定 — app-config.yaml の proxy で Dependency-Track API への経路と API キーを設定する。これによりブラウザに API キーを露出させない。

   proxy:
     endpoints:
       '/dependencytrack/api':
         target: 'https://dtrack.example.com/api'
         headers:
           X-Api-Key: ${DTRACK_API_KEY}

3. catalog-info.yaml のアノテーション設定 — Component と Dependency-Track のプロジェクトを紐付ける。

   metadata:
     annotations:
       dependencytrack.io/project-id: '<UUID>'
       # または name/version による指定（プラグインの対応に依存）

4. エンティティページでの脆弱性表示 — 重大度別の件数やポリシー違反がカードに表示される。

認証情報はプロキシで集約

API キーはブラウザではなく Backstage バックエンドのプロキシで付与します。アノテーションには UUID やプロジェクト名のみを置き、秘密情報を catalog-info.yaml に書かないでください。

---

5. 運用フロー

蓄積された脆弱性は、放置せず継続的に評価・トリアージします。

ステップ	内容
評価・トリアージ	各脆弱性を Exploitable / In Triage / False Positive / Not Affected などに分類する
ポリシー	バージョン・ライセンス・重大度に対するポリシー条件を定義し、違反を検出する
通知	ポリシー違反や新規脆弱性を Slack / Webhook / メールで通知する
誤検知の抑制	影響しないと判断した脆弱性は VEX（Vulnerability Exploitability eXchange） で Not Affected を記録し、再表示を抑制する

VEX とは

VEX は「その脆弱性が実際に影響するか」を機械可読に表明する仕組みです。同じ依存があっても呼び出し経路が無ければ影響しない、といった判断を残し、ノイズを継続的に減らせます。

---

6. CI/CDゲート

Dependency-Track はパイプラインから ポリシー評価結果を問い合わせ、しきい値超過でビルドを失敗させる「ゲート」を構築できます。

• アップロード後、API でプロジェクトのポリシー違反・重大度別件数を取得する。
• 例: 「Critical が 1 件でもあれば失敗」「新規の High はマージをブロック」。
• 公式の CI 連携（dependency-track/gh-upload-sbom-action 等）を使うと、アップロードと結果判定をまとめて行える。

関連ドキュメント

パイプラインでのセキュリティゲートの考え方はDevSecOpsと静的セキュリティスキャンも参照してください。

---

ベストプラクティス

• SBOM 生成をビルドの標準ステップにする — 手動アップロードに依存せず、全ビルドで自動的に最新の SBOM を取り込む。Software Templates で初期構成に組み込むと徹底しやすい。
• コンポーネント命名規則を統一する — projectName をカタログの Component 名と揃え、Backstage との紐付けと重複登録の回避を両立する。
• 重大度に応じたトリアージ SLA を設定する — 「Critical は N 日以内」のように対応期限を定め、ポリシーと通知で運用する。
• VEX で誤検知を継続的に抑制する — ノイズを放置すると形骸化する。Not Affected の判断を記録し続ける。
• アンチパターンを避ける — 手動アップロード依存、放置された脆弱性、ゲートを設けず可視化だけで終わる運用。

---

参考リンク

• OWASP Dependency-Track
• Dependency-Track Documentation
• CycloneDX
• Backstage Community Plugins
• CISA: Vulnerability Exploitability eXchange (VEX)