はじめに
Vuls は エージェントレス で動く OSS の脆弱性スキャナです。
複数 OS・ミドルウェアを横断してスキャンできますが、その裏側では
- NVD/OVAL/CVE List など 多種多様な脆弱性データベース
- それぞれフォーマットも更新タイミングも異なる
- 脆弱性DBのフェッチが面倒
という課題がありました。
そこで登場したのが vuls.db です。
従来のgo-cve-dictionary、goval-dictionary、gost などのDBを1つにまとめ、さらに VEX・CSAF など次世代フォーマット も取り込める “統合 DB” として進化しています。
vuls.dbは次のようにFetchとExtract、DBの3つの工程を経て、作成・配布されます。

このブログでは
- 自分専用の
vuls.dbを作る手順 - GitHub Actions で自動ビルドする方法
- 3 つのユースケース
を解説します。
💡 誰に向けた記事?
- オフィシャルで採用されていないデータソースを使いたい人
- オフィシャル vuls.db に含まれる不要データを省きたい人
- 社内/サードパーティ製の独自データソースを追加したい人
あなただけのvuls.dbの作り方
早速、vuls.dbを作ってみましょう!
今回は、RedHat VEXとCVEProject CVE List V5が入ったvuls.dbを作りたいと思います。
はじめに、vuls.dbを作成するために必要なツールをインストールします。
1 |
# require go 1.24 or higher |
続いて、vulsとvuls-data-updateを利用して、vuls.dbを作っていきます。
1 |
$ vuls db init --dbpath ./vuls.db |
では、作成したvuls.dbからCVEを検索してみましょう。
vuls db search data vulnerability --dbpath vuls.db CVE-2025-4091
1 |
$ vuls db search data vulnerability --dbpath vuls.db CVE-2025-4091 |
もちろん、vulsでの脆弱性検知に作成したvuls.dbを使うこともできます。
1 |
$ cat config.toml |
さて、ここでvulsio/vuls-db-templateを紹介しようと思います。
GitHub Actionsで定期的にvuls.dbを作成して、作成したvuls.dbを自身のPackagesに公開するまでを、このテンプレートリポジトリを利用することで簡単に行えます。
先程、手動で作ったvuls.dbも、vuls-db-templateを利用することによって、次のようにGNUMakefileを変更するだけで、GitHub Actionsがvuls.dbを作成してくれます。
1 |
:100644 100644 5eb2622 0000000 M GNUMakefile |
提供されているデータソースの確認方法は次のとおりです。
1 |
$ gh api --paginate /orgs/vulsio/packages/container/vuls-data-db/versions --jq '.[] | select(.metadata.container.tags[] | startswith("vuls-data-extracted-")) | .metadata.container.tags[]' |
もしくは、こちらから探すこともできます。
https://github.com/vulsio/vuls-data-db/pkgs/container/vuls-data-db/versions
ユースケース紹介
これまで、vulsやvuls-data-updateを使う方法、またはvuls-db-templateを利用する方法という2つのvuls.dbの作り方を紹介しました。
これから、あなただけのvuls.dbを作るべきユースケースを3つ紹介します。
1. オフィシャルで採用されていないデータソースを使いたい
次の記事によると、RedHatは、OVALに代わるフォーマットとしてCSAF、VEXを採用し、2024年末に廃止予定でした。
OVALは2024年末に廃止はされなかったものの、RHEL 10といった将来のメジャーリリース向けのデータは提供されないようです。
- https://www.redhat.com/en/blog/vulnerability-exploitability-exchange-vex-beta-files-now-available
- https://www.redhat.com/en/blog/red-hat-vex-files-cves-are-now-generally-available
よって、vulsはRedHatに対するデフォルトのデータソースをOVALからVEXに変更しました。
https://github.com/vulsio/vuls-data-db/commit/45b078f8888a81b82851d61285cf1663c68c1284
フォーマットの変更により、未修正の脆弱性に紐付くパッケージが、binary packageからsource packageに変更されています。
よって、スキャナが古い場合など、スキャン対象のsource packageが収集できていない場合、オフィシャルなvuls.dbでは、未修正な脆弱性を検知できなくなります。
そこで、OVALが入ったvuls.dbを作成・利用することで、この問題を一時的に回避できます。
2. オフィシャルなvuls.dbに必要のないデータソースがある
オフィシャルで配布するvuls.dbは、ユーザがどんな対象をスキャンするかわからないため、vulsでサポートする対象のデータソースをすべて追加する予定です。
goval-dictionaryやgostでは、必要な分だけDBに追加することができました。
もし、自分たちの環境に必要なデータソースだけを含むvuls.dbが必要であれば、紹介した方法でvuls.dbを作成してください。
3. 自前で持っているデータソースをvuls.dbに追加したい
vuls.dbでは、goval-dictionaryやgostなどと異なり、ユーザ自身が持っているデータソースを追加できるように考えています。
例えば、次のようにデータを用意します。
1 |
$ tree vuls-data-extracted-test/ |
そして、用意したデータをvuls.dbに追加して、TMP-2025-0001を検索してみます。
すると、検索結果に自分が用意したデータの内容が追加されていることがわかります。
1 |
$ vuls db add --dbpath vuls.db vuls-data-extracted-test |
もちろん、検知条件を設定しているため、vulsでの検知も可能です。
1 |
$ ./vuls0 report --refresh-cve 2025-05-01T12-55-56+0900 |
おわりに
今回、vuls.dbの作り方とユースケースについて紹介しました。
vuls.dbを使いこなして、脆弱性管理に活用していただければ幸いです。
issueやpull requestも歓迎しております!