SBOMの利用 (Pro)
DefectDojo Proは、ソフトウェアライブラリを依存関係ロケーションとしてモデル化します。依存関係は、Package URL (pURL) によって識別されるロケーションのサブタイプであり、org.apache.logging.log4j:log4j-core@2.17.0、pypi/django@5.0.2、npm/react@18.2.0 などの単一のライブラリまたはパッケージを表すことを意図しています。
依存関係は、検出事項にのみ紐付いていた従来のコンポーネントモデルに代わるものです。ロケーションでは、ライブラリは脆弱性の有無にかかわらず独立して存在できます。SBOMをアセットにアップロードしておけば、スキャンが取り込まれるたびに検出事項が参照する依存関係へ自動的に紐付きます。
依存関係が保持する情報
すべての依存関係はpURLによって一意に識別され、検索・フィルタリング可能な原子的なフィールドに分解されます。
| フィールド | 意味 | 例 |
|---|---|---|
purl_type | ライブラリのエコシステム | npm、pypi、maven、cargo、nuget、gem |
namespace | ベンダーまたは組織 | org.apache.logging |
name | ライブラリ名 | log4j-core |
version | 特定のバージョン | 2.17.0 |
qualifiers (オプション) | 実装の詳細 | arch=amd64 |
subpath (オプション) | アーカイブまたはモノレポ内のパス | src/lib/foo |
artifact_hashes (オプション) | フィンガープリント | SHA256サム |
license_expression (オプション) | SPDXライセンス表現 | Apache-2.0、MIT |
file_path (オプション) | プロジェクト内でライブラリが見つかった場所 | package-lock.json |
この原子的な分解こそが、pURLベースの検索を有用にしています。「django 名前空間にある、バージョン4.x系のすべての pypi パッケージ」といった問い合わせに対し、DefectDojoは自由記述の文字列を解析することなく回答できます。
Owned-ByとUsed-By
依存関係がアセットに関連付けられると、Asset Referenceは、そのライブラリがアセットにどのように属しているかを示す任意の**relationship(関係)**を持ちます。
owned_by— 「このライブラリはこのアセットが所有している」。アセットが公開・保守しているファーストパーティライブラリに使用します。used_by— 「このライブラリはこのアセットによって使用されている」。アセットが利用するサードパーティの依存関係に使用します。
同じライブラリが、あるアセットには owned_by、他の複数のアセットには used_by として関連付けられることがあります。これはまさに、脆弱性のトリアージ中に「自分のチームが公開しているパッケージを消費しているのは誰か」という問いに答えるために必要な関係性です。
SBOMのアップロード
依存関係を一括で取り込むには、製品に対してSBOMファイルをアップロードします。エンドポイントは次のとおりです。
POST /api/v2/sbom-import/| フィールド | 説明 |
|---|---|
product | 対象となる製品(アセット)のID |
file | SBOMファイル |
scan_type | SBOMの形式(サポートされる形式は以下を参照) |
replace (オプション) | true の場合、既存の検出事項の参照に裏付けられていない古い製品の関連付けが削除されます。デフォルト: false(累積) |
インポーターはファイルを解析して Dependency レコードを抽出し、既存のロケーションと重複排除を行い(必要に応じて新規作成し)、各依存関係を製品にリンクするAsset Referenceを作成します。Pro UIでも同じアップロードフローが提供されています。製品のロケーションタブにあるSBOMをアップロードアクションを参照してください。
サポートされる形式
MVPには、主要な2つのSBOM形式に対応するパーサーが同梱されています。
- CycloneDX — JSONおよびXML
- SPDX — JSON(v2およびv3)、XML、tag-value
SWID Tag形式にはまだ対応していません。
ReplaceとAppend
デフォルトでは、繰り返しのアップロードは追加方式です。アセットにすでに存在する依存関係はそのまま保持され、新しいものが追加され、何も削除されません。これは、SBOMを段階的に更新していく一般的なワークフローに合致します。
不要なものを削除するには replace=true を設定します。replaceモードが有効な場合、インポートが成功した後、新しいSBOMに存在せずかつ現在アクティブな検出事項から参照されていない製品の関連付けをインポーターが削除します。アクティブな検出事項に紐付く参照は、replaceモードでも保持されるため、新しいSBOMでパッケージが省略されたからといって脆弱性のコンテキストが失われることはありません。
ライブラリを参照する検出事項
パーサーがライブラリに紐付いた脆弱性を取り込む場合、たとえばSCAツールが log4j-core@2.14.1 に対して CVE-2021-44228 を報告する場合、インポーターは次の処理を行います。
- pURLで既存の依存関係ロケーションを検索するか、新規に作成します。
- 検出事項を依存関係にリンクする
LocationFindingReferenceを、ステータスアクティブで作成します。 - 依存関係が親製品にまだ表示されていない場合、そこにも表示されるよう
LocationProductReferenceを作成します。
検出事項とSBOMのアップロードは、同じ依存関係オブジェクトを基盤として共有しているため、SBOMのアップロードより前に取り込まれた検出事項も、SBOMビューに遡って表示されます。逆の場合も同様です。
REST API
| タスク | エンドポイント |
|---|---|
| SBOMをアップロード | POST /api/v2/sbom-import/ |
| 依存関係を一覧表示 | GET /api/v2/dependencies/ |
| 依存関係を手動で作成 | POST /api/v2/dependencies/ |
| 依存関係ロケーションを一覧表示 | GET /api/v2/location/?location_type=dependency |
| 依存関係を検出事項にリンク | POST /api/v2/location_findings/ |
依存関係を製品にリンク(owned_by / used_by を使用) | POST /api/v2/location_products/ |
/api/v2/dependencies/ のフィルタには、pURLの構成フィールド、タグ、そして name、version、アクティブな検出事項数による並べ替えが含まれます。
Pro UIでの表示
ロケーションが有効になると、ナビゲーションに以下が表示されます。
- ロケーション / 依存関係 — インスタンス全体のすべての依存関係のグローバル一覧。pURLによるフィルタが可能です。
- 製品/アセットのロケーション — URLと依存関係の両方を表示するアセット単位のビュー。依存関係タブにSBOMをアップロードアクションが表示されます。
- 新しい依存関係 — pURLの構成要素を手動で入力して単一のライブラリを作成するフォームです。
- 検出事項の詳細 — ライブラリに関係する検出事項は、URLロケーションと並んで依存関係ロケーションを表示するため、「このCVEはアセット6とアセット9の
log4j-core@2.14.1に影響している」といった情報を1か所で確認できます。
MVPに含まれないもの
- SWID Tag SBOM形式 — 解析されません。CycloneDXまたはSPDXが必要です。
- ライセンスリスクのスコアリング — SBOMに
license_expressionフィールドが含まれている場合はそれが取り込まれますが、DefectDojoはまだライセンスの非互換性について検出事項にフラグを立てません。ライセンスベースのレポート機能は、ロケーションMVPの後続としてロードマップに含まれています。 - コンテナイメージおよびクラウドリソースのロケーション — 将来のロケーションサブタイプです。現時点では、コンテナイメージ内で見つかったライブラリは依存関係として記録されますが、コンテナイメージ自体はまだファーストクラスのロケーションではありません。