ぶるーたるごぶりん

UI, UX, セキュリティとか😘

Google の OSV と CPE の課題解決について

OSV と CPE

炭治郎です。コロナ2日目です。

自分は知らなかったのですが、 Google が2021年2月に OSV (Open Source Vulnerabilities) と言う脆弱性DBを公開していました。

https://opensource.googleblog.com/2021/02/launching-osv-better-vulnerability.html

この OSV に触れた国内記事はそれほど多くなく、 記事の内容自体も OSS-Fuzz について触れているケースが多そうでした。

ただ、自分的にはその点よりも以下の CPE の課題を解決してくれる点というのが非常に良さそうだと思いました。

This comes from the fact that versioning schemes in existing vulnerability standards (such as Common Platform Enumeration (CPE)) do not map well with the actual open source versioning schemes, which are typically versions/tags and commit hashes.

意訳すると、 CPE などが package manager 上の package 名などと対応していない問題があり、 それを OSV によって解決するという感じです。

この点について、既存のCPEを元にしたパッケージの特定の限界と、 OSV が良さそうという話をしてみようと思います。

CPE ってなに?

IPA が詳細な記事を出されているので読んでください

https://www.ipa.go.jp/security/vuln/CPE.html

超短く雑に書くと、以下のようなフォーマットです。

  1. 次のようなフォーマットで cpe:/o:redhat:enterprise_linux:4:update4
  2. どこの ベンダー, モジュール(ライブラリや製品), バージョン (など)が影響するのを表すフォーマット

CPE を元にした脆弱性の特定と落とし穴

1つ例を出します。

あなたは自社のセキュリティ管理を行うセキュリティエンジニアです。 あなたは「NVD の CVE 情報を監視し、自社に影響があるかどうかを調べる」というタスクを行なっています。

さて、今日は新たに自社に影響するかもしれない Spring Framework脆弱性が発表されました。

https://nvd.nist.gov/vuln/detail/cve-2022-22965

CPE を見ると以下が影響するそうです。

cpe:2.3:a:vmware:spring_framework:3.0.0:-:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.0:milestone1:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.0:milestone2:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.0:milestone3:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.0:milestone4:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.0:rc1:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.0:rc2:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.0:rc3:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.1:*:*:*:*:*:*:*
cpe:2.3:a:vmware:spring_framework:3.0.2:*:*:*:*:*:*:*

これを元に、実際にマニフェストファイル (pom.xml, package.json, requrements.txt などの構成ファイル)で、 利用しているかを調べてみます。(今回は Gradle を例とします)

調べてみると、(実際は使っているのに)Spring は見つかりませんでした。


これがCPE を使った調査の落とし穴です。

原因は簡単で、CPE の表記は、 package manager 上での名前を表しておらず、 しばしば表記揺れが発生するためです。

Gradle (Java) のパッケージ表記は以下のように表記されていました。 (適当なSpring Module を引っ張ってきているため適切な例ではないですが、そこは多めにみてください)

implementation 'org.springframework:spring-beans:5.2.19.RELEASE'

一方で、CPE の場合は次のような表記です。

cpe:2.3:a:vmware:spring_framework:3.0.2:*:*:*:*:*:*:*

このように CPE と PackageManager 上で springframework の表記揺れが発生しています。

PackageManager側: springframework
CPE: spring_framework

このような表記揺れ問題もあり、CPEを用いた機械的なチェックには限界があると認識しています。

これらの課題があり、(私は未読ですが)以下のような論文が出されているようです。 https://ipsj.ixsq.nii.ac.jp/ej/index.php?active_action=repository_view_main_item_detail&page_id=13&block_id=8&item_id=214466&item_no=1

OSV で脆弱性のパッケージ名を見てみる。

ということで、ようやく冒頭に紹介した OSV を見てみます。

先ほどの CVE がどのように表示されるか見てみます。
https://osv.dev/list?ecosystem=&q=cve-2022-22965

みてみるとわかりますが、 package manager 上での表現に寄せられたフォーマットによって、 影響するモジュールの特定ができています。

これによって、先ほどの課題は解消しました。素晴らしい。

終わりに

いかがだったでしょうか? 面白いと思った方は、高評価、それとチャンネル登録もよろしくお願いします。