SCANOSS サポート担当の橋本です。
弊社では SCA ツールのナレッジベース製品である SCANOSS 製品を代理店として取り扱っています。
SCANOSS 製品の開発元である SCANOSS 社より、SCANOSS 社内の Dependency-Track 運用ノウハウドキュメントを提供いただきました。
Dependency-Track は SCANOSS 製品と統合することが可能な OSS であり、SBOM の管理運用を実施する上で有用なソフトウェアであるため、本ドキュメントを翻訳の上公開いたします。
Dependency-Track を検討している方のお役に立てればと思います。
注:Dependency-Track は OWASP が開発している OSS です。
SBOM 運用のデファクトスタンダード的な OSS ツールではありますが、SCANOSS 社とは直接的な関係はございません。
本ドキュメントはあくまで SCANOSS 社が考える Dependency-Track ベストプラクティスという点にご注意ください。
1. 概要 (Overview)
Dependency-Trackは、組織内の全プロジェクトにおけるコンポーネントの分析、監視、および制御を可能にする一元化されたダッシュボードを提供します。
CycloneDX 形式の SBOM および VEX(Vulnerability Exploitability Exchange) のインポート・分析を通じて、組織のポートフォリオ全体に含まれるすべてのアプリケーションのコンポーネント使用状況を追跡します。
2. SBOMアップロード後の脆弱性確認
プロジェクトのSBOMがアップロードあるいは更新されると、Dependency-Track は自動的に脆弱性分析を開始します。
監査の脆弱性 (Audit Vulnerabilities) タブへの移動
「監査の脆弱性」とは、各プロジェクトのコンポーネントに関する検出事項をトリアージするプロセスです。
特定のプロジェクト内で行われた監査の決定、コメント、および履歴は、そのプロジェクトの検出事項にのみ適用され、他のプロジェクトには影響しません。
- プロジェクト監査には VULNERABILITY_ANALYSIS 権限が必要です。
- 監査証跡の閲覧は VIEW_VULNERABILITY 権限を持つすべてのユーザーが可能です。
EPSS と重大度 (Severity) による優先順位付け
統合された EPSS (Exploit Prediction Scoring System : 脆弱性悪用予測スコア) を CVSS の深刻度と併用することで、どの検出事項から先に対処すべきかの優先順位を付けます。
「高い CVSS」+「高い EPSS」=即座に修正すべき項目、という判断基準になります。
脆弱性インテリジェンスソース
Dependency-Track は、以下の7つの主要なソースと統合されています。
- National Vulnerability Database (NVD)
- GitHub Advisories
- Sonatype OSS Index
- Snyk
- Trivy
- OSV
- VulnDB (Risk Based Security)
3. 監査判断の実施:分析ステート
各検出事項には分析ステートを割り当てます。
まず「設定されていません」の項目から着手し、調査中は 「トリアージ中」へ移行させ、最終的に調査結果に基づいたステートを決定します。

分析ステート一覧
日本語表記 | 英語表記 | 説明 |
設定されていません | Not Set | 分析がまだ開始されていない初期状態 |
悪用可能 | Exploitable | 脆弱性が悪用可能 (またはその可能性が高い) と判断された状態 |
トリアージ中 | In Triage | 検出内容の正確性や影響度を判断するための調査が進行中の状態 |
偽陽性 | Falese Positive | 誤ったロジックやデータ (コンポーネントの誤特定や脆弱性情報の誤りなど) による誤検知 |
影響を受けません | Not Affected | 脆弱性自体は存在する (真の陽性) が、当該プロジェクトの利用方法等により影響を受けない状態 |
ヒント: ステートの変更を含むすべての監査証跡には、ユーザー名とタイムスタンプが自動的に付記されます。
判断の根拠を後から検証できるよう、監査時には必ず具体的な理由をコメントとして記録してください。
4. ポリシー違反の確認
組織全体、または特定のプロジェクト単位でポリシーを設定し、ポリシー違反状況を継続的に測定できます。ポリシーの評価は、SBOM がアップロードされるたびに自動的に実行されます。
ポリシー違反には以下の 3 つの種類があります:
I :ライセンス違反
宣言されたライセンスが組織のコンプライアンス基準に適合しているか確認します。
ポリシー管理 > ライセンスグループ > ライセンスグループの作成より「許容ライセンス」や「禁止ライセンス」といったライセンスグループを作成し、それらに対して違反条件を設定します。
- 承認済みリスト以外のものを検知するには、「『ライセンスグループ』『ではない』『許容ライセンス』」という条件を使用します。
- 禁止されているライセンスを検知するには、「『ライセンスグループ』『は』『禁止ライセンス』」という条件を使用します。
- Copyleft などの一般的なライセンスグループは標準で用意されています。
※訳注『』内は設定値です。

II:セキュリティ違反
脆弱性の重大度を条件として指定できます。
検出事項の重大度がポリシー条件と一致した場合、違反としてトリガーされます。
抑制れた脆弱性は、ポリシー違反を引き起こしません。
III.運用違反
以下の条件に基づき、特定のコンポーネントに対する許可・禁止ルールを作成できます。
- 年 : バージョン公開日からの期間
- 座標 : group, name, version (GAV) による特定
- パッケージ URL (PURL)
- CPE
- SWID Tag ID
- ハッシュ値: MD5, SHA, SHA3, Blake2b, Blake3
- バージョン距離: 使用中のバージョンと最新バージョンの差
これにより、特定のコンポーネントの許可リストや拒否リストを作成することができます。

5.影響範囲分析と特定
新しいCVE (脆弱性) が公開された際、ポートフォリオ内の 「コンポーネント (Component)」または「脆弱性 (Vulnerability)」を活用することで、その影響を受けるライブラリを利用しているプロジェクトを検索可能です。
個別のプロジェクトを一つずつ確認する必要はなく、組織全体の影響範囲を迅速に評価できるため、影響範囲を即座に特定することができます。
活用シーン: ゼロデイ脆弱性への対応、監査、およびサプライチェーン・インシデントへの対応時。
6. 抑制
抑制機能は、検出事項をグローバル (ポートフォリオ全体) または特定のプロジェクト単位で非表示にするために使用します。
- 自環境のアーキテクチャ上、影響対象外であることが確認された脆弱性に対して使用します。
- 抑制された項目は、ダッシュボード上のポリシー違反カウントから除外されます。
- 抑制を行う前に、必ず監査コメントにその技術的・運用的理由を記録してください。
- 以前は適用外だった脆弱性も、デプロイメントやアーキテクチャの変更によって再度リスクとなる可能性があるため、定期的に抑制設定を再確認することが推奨されます。
https://docs.dependencytrack.org/triage/suppression/
7. 通知の自動化
ダッシュボードを手動で確認するのではなく、通知機能を活用してプッシュ型で情報の通知が可能です。
サポートされるチャネル
- Slack
- Microsoft Teams
- Mattermost
- Webhooks
- Webex
- Jira
推奨される通知トリガー
- 新規脆弱性の特定 (特に重大度が Critical または High のもの)
- ポリシー違反の発生
- プロジェクト SBOM の更新
CI/CD 統合
- Jenkins: OWASP Dependency-Track Plugin を使用します。ポリシー違反が発生した際にパイプラインを自動的に失敗させることも可能です。
- その他の CI システム: REST APIを使用して SBOM をアップロードし、プログラムを介して違反の有無を確認します。
8. ベストプラクティス (Best Practices)
SBOM の生成
- SBOM は手動で作成せず、CI プロセス内で自動生成してください。
- サプライヤーやベンダーに対しても、CycloneDX SBOM の提供を契約条件として要求してください。
- 商用ソフトウェアについても、可能な限り SBOM を入手または生成してください。
アナライザーとデータソース
- Internal Analyzer および OSS Index を有効化してください。
- NVD および GitHub Advisories のミラーリングを有効化し、常に最新の知見を利用できるようにしてください。
日常の衛生管理
- Dependency-Track 内のプロジェクトのバージョンを常に最新の状態に保ち、検出事項のスコープ (影響範囲) が正しく設定されるようにします。
- ステートを変更する際は、毎回必ず監査コメント欄を使用してください。判断に至った経緯は、チームメンバーや監査人にとって非常に重要な情報となります。
- 個々のプロジェクトだけでなく、ポートフォリオのダッシュボードを定期的に確認し、全体的なリスクの傾向を把握します。
- 「プロジェクト収集 (Collection Projects)」を活用して関連するプロジェクト (例:チームや製品ライン別など)をグループ化し、集約されたビューで確認できるようにします。
- 「トリアージ中」 の状態で長期間放置されている検出事項に対処するため、定期的なレビューのサイクル (例:週次でのトリアージセッションなど)をスケジュールします。
9. チュートリアルビデオ (Tutorial Videos)
タイトル とリンク | 説明 |
OWASP 財団による概念的概要 — ステークホルダー向け | |
インストール、ダッシュボード、API キー、プロジェクトの作成とインポートについて説明 | |
プロジェクト作成者による解説:ビジョンと設計思想 | |
UI のクイックデモ (簡単な実演) — 主要な画面説明 | |
OWASP Dependency-Track SBOM Analysis Up and Running in Minutes | ステップバイステップの設定手順、および SBOM 自動アップロードのための GitHub Actions 連携 |
Understanding Open Source Dependencies — Lightning Talk (Fran Hoey) | コミュニティ・カンファレンスでの講演:日々の利用に役立つ実用的な事例 |
Is Your Supply Chain Safe? Dependency-Track Tutorial for Devs | CycloneDX SBOM の生成とサプライチェーン・リスク評価を説明 |
10. 公式チャネルと主要ドキュメントリンク
YouTube の公式チャネルでは、メンテナによる新機能解説やコミュニティミーティングを含む約 30 本のビデオが公開されています。
継続的なアップデート情報を得るため、サブスクライブを推奨します。
🔗 https://www.youtube.com/c/OWASPDependencyTrack
主要ドキュメントリンク
監査の基本 | |
分析ステート | |
抑制 | |
ポリシーへの準拠 | |
影響分析 | |
CI/CD連携 | |
ベストプラクティス | |
REST API | |
通知 |

