Dependency-Track by OWASP ソフトウェアコンポーネント管理システム

SBOMを生成し、分析する無償ツールは数多く存在していますが、生成したSBOMやそのデータを管理する仕組みを持つツールは少ないのが現状です。
生成したSBOMやソフトウェアコンポーネントを管理していくことはとても難しく、多くの課題があります。

Dependency-Trackは開発プロジェクトが利用するソフトウェアコンポーネント情報を保存し管理することを目的としたツールです。このツールはOWASPから提供されています。

Dependency-Trackはコンポーネント管理と脆弱性検知機能が一体となっています。そのため、Dependency-Track、一つでSBOM・コンポーネント管理を完結させたい場合は、十分な脆弱性検知性能を持っているか確かめる必要があります。
また、脆弱性検知性能が足りていない場合、他ツールと組み合わせる必要があるため、他ツールとの相性を調べる必要があります。
本記事では、まずDependency-Trackの脆弱性検知性能を紹介し、他のSBOMツール群との相性について議論します。

Dependency-Trackを起動させてみた系の記事は既にあるし、公式ドキュメントにも書いてあるので、そちらをご覧ください。
[Dependency\-Track公式ドキュメント](https://docs.dependencytrack.org/)
[SBOMツール紹介 ~ Dependency\-Track編 ~](https://tech-lab.sios.jp/archives/40539)


## Dependency-Trackの脆弱性検知性能
### 使用するデータベース
Dependency-Trackでは、様々な脆弱性DBを参照することができます。無償で使用できるDBを以下に示します。

表から、そして実際に動かすとわかる通り、言語パッケージはGHSAs、OS distroパッケージはNVDのデータベースに依存していることがわかります。また、NVDのデータベースだとCPEを使ったマッチングを利用するため、検知ミスが発生する場合があります。そこを補うために、Sonatypeから出ているOSS INDEX、Googleから出ているOSVというDBで検知性能を向上させることができます。[^1]
[^1]: ちなみに、OSVはrpmパッケージに関する脆弱性情報が非対応なため、OSS INDEXで補っているのだと思います。まあ、Googleはrpmは使ってないですから、優先度が低いのだと思います。

|pkgタイプ|使用する脆弱性ソース|マッチングアルゴリズム|
|:----|:----|:----|
|言語|GitHub Security Advisories (GHSAs)|言語とパッケージ名、影響のあるバージョンから脆弱性情報を取得する|
|OS distro,<br>言語|National Vulnerability Database (NVD)|NVDのCPEとのマッチング時、少し幅を持たせマッチングさせる <br>ここでいう幅を持たせるとは、cpeの一部分をワイルドカードに置き換えること|
|言語+rpm|OSS INDEX  (By Sonatype)|OSS INDEXに登録されているpurlとのマッチング 、ただしDBの正確性は不明 <br>rpmの情報を補うために採用されていると思われる|
|両方|OSV (Open Source Vulnerabilities), (By Google)|rpmは非対応|


今回は調べ切れていないのですが、Trivyを別のサーバーで動かしたり、VulnDBやSnykから出ている有償脆弱性DB、独自に作成した脆弱性DBを利用することが可能です。
https://docs.dependencytrack.org/datasources/snyk/
https://docs.dependencytrack.org/datasources/vulndb/

また、CPEのファジーマッチングの強さを変えることもできます。

### 脆弱性検知性能
使用している脆弱性DBを見ると、検知する範囲は広そうです。しかし、OSSで有名な脆弱性検知スキャナーTrivyやGrypeと比較するとDependency-Trackはいくつかの点において検知性能はまだ発展途上であると言えます。


#### 1. OS distroパッケージの検知性能が発展途上
TrivyやGrypeをはじめ、いくつかの脆弱性検知スキャナーがCPEによるマッチングを利用していません。ディストリビューションが提供する脆弱性DBを利用し、検知する傾向にあります。
Dependency-TrackはOS distroパッケージの検知をCPEに頼っているため、検知方法はあまり筋がいいとは言えません。dpkgやapkだとOSVで補強することができますが、**rpmについてはRedHatが出している脆弱性情報を参照せず、OSS INDEXに依存**しています。
#### 2. DBをミラーする必要がある
TrivyやGrypeは様々なDBをまとめた軽量の`.db`ファイルをベンダーが用意しています。これを脆弱性検知に利用できます。そのため、別の環境でdbファイルをダウンロードし、ネットワークから隔離されたエアギャップ環境でも脆弱性検知を行うことができます。  
一方で、Dependency-Trackは脆弱性DBをミラーリングしています。そのため、ネットワークに接続する必要があり、ネットワークから隔離された環境で脆弱性検知を行うことができません。
また、GHSAsを利用する場合は、GitHubのアクセストークンを用意し、GitHubへのアクセスが必要になります。もし、エンタープライズではないGitHubへのアクセスが禁止されている場合、GHSAsは利用できません。そのため、言語パッケージの検知性能はCPEマッチングに依存し、検知性能が大幅に低下してしまいます。

## 他ツールとの相性
Dependency-Trackはコンポーネント情報を管理し、解析するツールであることは公式ドキュメントを使えば十分理解できると思います。また、上で述べた通り、脆弱性検知性能がまだ発展途上なため、他の脆弱性検知ツールと組み合わせ利用する必要があります。
問題は別ツールでSBOMを生成し、Dependency-Trackで管理、別ツールで脆弱性検知、トリアージが実施するライフサイクルを実現できるのかということです。
ここでは、有名なOSSであるTrivy、Syft/Grypeを例に説明します。SBOM生成と脆弱性検知の両方をTrivy、SBOM生成Syft、脆弱性検知をGrypeという二つのパターンについて説明します。[^2]
[^2]: 当たり前かもしれませんが、基本的に、SBOM生成と脆弱性検知は提供しているベンダーを統一した方がよいです。詳細は省きますが、Trivy、SyftがSBOMを生成する際に、独自のフィールドを作成し、脆弱性検知にそのフィールドを使っているからです。つまり、SBOM生成をSyft、脆弱性検知をTrivyで行った場合、確実に検知漏れが起きます。

### パターン1. Dependency-Track + Trivy
Dependency-TrackとTrivyの相性はかなり良いです。というか、かなり優遇されています。まず、https://docs.dependencytrack.org/datasources/trivy/ にもありますが、すでにDependency-TrackにはTrivyと連携を行う機能が備わっています。つまり、以下の図に示すように、TrivyでSBOMを生成し、Dependency-Trackで管理、Trivyで脆弱性検知というサイクルを実行できます。
利用する上での課題が一つあります。それは、外部から脆弱性情報をインポートできないことです。Dependency-Trackは脆弱性情報をjson形式でエクスポートでき、例えば、SSVCなどを使ったトリアージに利用することができます。しかし、**トリアージ結果をDependency-Trackに戻せない**ため、Dependency-Trackの良さが消えてしまいます。
なので、トリアージとしてはSSVCなどは適用できませんが、Dependency-TrackではCVSSベースでのトリアージが設定できるので、そちらで頑張るしかないです。

```mermaid
sequenceDiagram
    actor User
    participant Trivy CLI
    participant Dependency-Track
    participant Trivy Server
    
    User->>+Trivy CLI:SBOM生成リクエスト
    Trivy CLI->>Trivy CLI:SBOM生成
    Trivy CLI-->>-User:SBOM 取得

    User->>Dependency-Track: SBOMをDPTへインポート 
    Dependency-Track->>+Trivy Server:脆弱性検知をリクエスト
    Trivy Server->>Trivy Server:脆弱性検知
    Trivy Server-->>-Dependency-Track:脆弱性検知結果反映
    User->>+Dependency-Track:結果閲覧をリクエスト
    Dependency-Track-->>-User:結果閲覧を結果の閲覧
    User->>+Dependency-Track: 脆弱性検知結果エクスポート <br>リクエスト
    Dependency-Track-->>-User:脆弱性検知結果jsonを取得
    User->>User:トリアージ
    rect rgb(200, 150, 255)
    note right of User: インポートができない！
    User->>Dependency-Track:脆弱性検知結果をインポート
    end

```

### パターン2. Dependency-Track + Syft/Grype
Dependency-TrackとSyft/Grypeとの相性は正直言うと、あまりよくありません。Dependency-Track以外で出力した脆弱性検知結果をDependency-Trackへインポートできないため、コンポーネント管理と脆弱性検知が完全に分離してしまいます。
では、分離させればいいのでは？と思う方もいるかもしれませんが、それならば、そもそもDependency-Trackいらなくないという結論になると自分は思っています。

次に、Dependency-TrackはSyftが生成するCPEをうまく参照できません。Syftは独自のフィールドで複数CPEを生成することで、CPEのファジーマッチングを実現しています。しかし、Dependency-Trackはcyclonedx標準のフィールド`cpe`というフィールドしか参照できません。

![Untitled.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781216/fe3f49d3-133b-b305-eaf5-12e24aa8d645.png)
![Untitled (1).png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/2781216/0522927f-900b-ea35-8227-a86adeb045a9.png)


どうしても、Dependency-Track + Syftを使いたい場合はおそらく、SBOM生成をSyftで行い、Dependency-Trackで管理、脆弱性検知を行う必要があります。トリアージについては、パターン1と同様です。

Syft/Grypeとの連携についても、Trivyのような仕組みがほしいですね。

```mermaid
sequenceDiagram
    actor User
    participant Syft
    participant Dependency-Track
    
    User->>+Syft:SBOM生成リクエスト
    Syft->>Syft:SBOM生成
    Syft-->>-User:SBOM 取得

    User->>Dependency-Track: SBOMをDPTへインポート 
    Dependency-Track->>Dependency-Track:脆弱性検知
    User->>+Dependency-Track:結果閲覧をリクエスト
    Dependency-Track-->>-User:結果閲覧を結果の閲覧
    User->>+Dependency-Track: 脆弱性検知結果エクスポート <br>リクエスト
    Dependency-Track-->>-User:脆弱性検知結果jsonを取得
    User->>User:トリアージ
    rect rgb(200, 150, 255)
    note right of User: インポートができない！
    User->>Dependency-Track:脆弱性検知結果をインポート
    end
```

## まとめ
今のところ、Dependency-Track + Trivyの組み合わせが良いと個人的には考えています。脆弱性検知については他ツールの方が優秀なので、そちらをうまく使えるようにできたらいいなと考えています。
Dependency-TrackはJavaで書かれているので、Javaを覚えて、コントリビュートするのも良いなと思っています。

ちなみに、DependencyTrackを使ったSBOM管理について、卒論があったので、ご興味あれば参照してください。
https://www.theseus.fi/bitstream/handle/10024/819967/Herman_Michael.pdf?sequence=2
以下のリポジトリで実装まで行っています：
https://github.com/mherman-fi/cool-projects/tree/main/sbom

### 課題
Dependency-Trackにはいくつかの課題があり整理すると以下のような感じです：
- OS distroパッケージの検知率の向上
    - rpmの脆弱性データベースの強化
    - CPEマッチング依存からの脱却
- トリアージ機能の充実
    - SSVCなど、様々なトリアージ機能の追加
    - 外部からの脆弱性検知結果のインポートがない
    - 脆弱性検知後のトリアージだけではなく、VEXなどを利用した、検知中のトリアージ