0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

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

Last updated at Posted at 2024-11-03

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

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

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

Dependency-Trackを起動させてみた系の記事は既にあるし、公式ドキュメントにも書いてあるので、そちらをご覧ください。
Dependency-Track公式ドキュメント
SBOMツール紹介 ~ Dependency-Track編 ~

Dependency-Trackの脆弱性検知性能

使用するデータベース

Dependency-Trackでは、様々な脆弱性DBを参照することができます。無償で使用できるDBを以下に示します。

表から、そして実際に動かすとわかる通り、言語パッケージはGHSAs、OS distroパッケージはNVDのデータベースに依存していることがわかります。また、NVDのデータベースだとCPEを使ったマッチングを利用するため、検知ミスが発生する場合があります。そこを補うために、Sonatypeから出ているOSS INDEX、Googleから出ているOSVというDBで検知性能を向上させることができます。1

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

パターン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ベースでのトリアージが設定できるので、そちらで頑張るしかないです。

パターン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
Untitled (1).png

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

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

まとめ

今のところ、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などを利用した、検知中のトリアージ
  1. ちなみに、OSVはrpmパッケージに関する脆弱性情報が非対応なため、OSS INDEXで補っているのだと思います。まあ、Googleはrpmは使ってないですから、優先度が低いのだと思います。

  2. 当たり前かもしれませんが、基本的に、SBOM生成と脆弱性検知は提供しているベンダーを統一した方がよいです。詳細は省きますが、Trivy、SyftがSBOMを生成する際に、独自のフィールドを作成し、脆弱性検知にそのフィールドを使っているからです。つまり、SBOM生成をSyft、脆弱性検知をTrivyで行った場合、確実に検知漏れが起きます。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?