C/C++のライブラリ構成管理はなぜ難しいのか。同梱ライブラリのバージョンをソースから同定する

はじめに

脆弱性を継続的に管理するには、どのライブラリのどのバージョンを使用しているかを把握する「構成管理」が欠かせません。しかし、C/C++のプロジェクトでは、この構成管理が難しくなる場面が多くあります。ライブラリのソースコードをthird_party/zlibのようにプロジェクトへ直接取り込むと、ライブラリ名とバージョンを記録した台帳が作成されないためです。

本記事では、C/C++で構成管理が複雑になる背景を整理し、FutureVulsの「C/C++ライブラリ構成識別」機能で、直接取り込んだライブラリを脆弱性検知の対象に登録する手順を、実行例とあわせて紹介します。

C/C++のライブラリの取り込み方

多くの言語では、言語標準のパッケージマネージャーでライブラリを管理する方法が一般的です。パッケージマネージャーを使う環境であれば、インストール済みパッケージの一覧やロックファイル（使う部品とバージョンを記録したファイル）を、そのまま構成管理の台帳として使えます。

しかし、C/C++では他の言語に比べてパッケージマネージャーが広く普及していません。実際、C/C++のエコシステムを対象としたTangらの研究[1]によると、2022年3月時点のGitHub上にあるC/C++リポジトリ24,001件のうち、Conanやvcpkgなどのパッケージマネージャーを利用していたリポジトリは442件で、全体の1.8%にとどまりました。

パッケージマネージャーが普及していないため、実際のプロジェクトでは次の2つの方式を組み合わせてライブラリを取り込む構成が一般的です。

• OSパッケージを利用する方式：aptなどのOSのパッケージ管理機能でライブラリをシステム領域へインストールし、ビルド時にCMakeなどのビルドツールでそのライブラリを探してリンクします。
• ソースコードを直接取り込む方式：ライブラリのソースコードをプロジェクト内に配置し、自分たちのコードと一緒にビルドします。

OSパッケージを利用する方式であれば、OSのパッケージ管理機能からソフトウェアの一覧を取得できます。FutureVulsのローカルスキャンも、この一覧を読み取ってソフトウェアを登録します。

CPEを特定できない理由

一方、ソースコードを直接取り込む方式では、ソフトウェアの台帳を自動で作成できません。ディレクトリ名がthird_party/zlibであれば製品がzlibだと推測できますが、ディレクトリ名からバージョンは判断できません。

さらに、脆弱性情報と照合するには、製品名とバージョンからCPE（ソフトウェア製品を表す共通の名前）を特定する必要があります。ソースコードを直接配置しただけでは製品名とバージョンの記録が無いため、CPEを特定できず、そのライブラリに関する脆弱性情報も照合できません。その結果、取り込んだライブラリに脆弱性が公表されても、スキャンでは検知できません。

ハッシュ照合による同定

FutureVulsの「C/C++ライブラリ構成識別」機能では、利用者が自分の環境で専用コマンドfuturevuls-cpp-fingerprintを実行し、ライブラリの各ファイルからMD5ハッシュ値を生成します。FutureVulsへ送信する情報は、ディレクトリの末尾名とハッシュ値だけです。FutureVulsは、オープンソースの脆弱性情報サービスであるOSVへハッシュ値を問い合わせ、リポジトリとバージョンを同定します。

同定の対象は、zlib、libxml2、expatなどを含むGoogle OSS-Fuzzの管理対象プロジェクトのうち、C/C++のプロジェクトです。グループ設定でCPE自動割当を有効にしていれば、FutureVulsはスキャン時に、同定したライブラリへCPEを自動で割り当てます。ただし、割り当ての対象は、NVDなどが公式のCPEを採番しているライブラリに限られます。

構成管理を始める流れ

導入時は、ソースを直接取り込んでいるライブラリのディレクトリを一覧にまとめ、専用コマンドでfuturevuls-cpp-library.jsonを生成してFutureVulsへ送信してください。同定結果はコンソールまたはAPIで確認できます。

照合先のハッシュ値は、改行コードがLFのソースから作られています。そのため、WindowsのGitでcore.autocrlfを有効にして取得したソースのように、CRLFに変換されたファイルは一致しません。対応OS、対象ファイルの拡張子、CI/CDへの組み込みは、C/C++ライブラリ構成識別のhelpを参照してください。

実行例

third_party/配下に5つのディレクトリを置いたプロジェクトで、本機能を実行した例を紹介します。5つのディレクトリには、zlib 1.3.1、curl 8.5.0、libpng 1.6.37、PCRE2 10.39の公開ソースと、社内で書いたソースをそれぞれ置きました。社内のソースを置いたディレクトリはinhouseです。4つの公開ソースは、いずれもOSS-Fuzzの管理対象です。

構成識別データの生成

取得スクリプトを実行し、引数にライブラリのディレクトリを渡します。

$ curl -fsSL -o futurevuls-cpp-fingerprint.sh https://installer.vuls.biz/futurevuls-cpp-fingerprint.sh
$ bash futurevuls-cpp-fingerprint.sh third_party/*/
[2026/10/14 20:45:37] "SUCCESS": Check architecture. [arch: x86_64]
[2026/10/14 20:45:38] "SUCCESS": Download binary. [key: futurevuls-cpp-fingerprint_0.1.0_linux_amd64]
futurevuls-cpp-fingerprint: file "third_party/zlib/contrib/testzlib/testzlib.c" has CRLF line endings; it is hashed as stored and may not match the index
futurevuls-cpp-fingerprint: wrote futurevuls-cpp-library.json

コマンドは警告を1件出力しました。zlibに同梱されたテスト用ファイルがCRLFで保存されており、運用前に確認する項目で挙げた改行コードの条件に該当したためです。このファイルのハッシュ値は、照合先と一致しない可能性があります。zlibとして同定できるかどうかは、他のファイルの照合結果次第です。

生成したfuturevuls-cpp-library.jsonには、ディレクトリの末尾名（label）とファイルごとのハッシュ値（hashes）だけが入ります。先頭を抜粋すると次のとおりです。

{
  "version": "0.1.0",
  "components": [
    {
      "label": "curl",
      "hashes": [
        "PgwdHUmCkSuf6SEA1gi9DA==",
        "wS3nSo1oQG9MsBnHC0Hsbg==",
        ...

このファイルを、helpの手順どおりLockファイル追加API（POST /v1/lockfile）でサーバへ送信します。

同定結果の確認

サーバ詳細の「アプリケーション」タブでfuturevuls-cpp-library.jsonを開くと、同定結果を確認できます。

登録されたソフトウェアは3件でした。curl、zlib、PCRE2は、リポジトリとバージョンを同定できています。CRLFの警告が出たzlibについても、他のファイルのハッシュ値が照合先と一致したため同定できました。一方、OSS-Fuzzの管理対象であるlibpngは、候補のリポジトリが2つあり、1つに特定できなかったため登録されていません。社内で書いたinhouseには、一致するリポジトリがありませんでした。

続いて、CPE自動割当を有効にしたグループで手動スキャンを実行しました。3件ともCPEが割り当てられ、「ソフトウェア」タブにはソフトウェア種別vcs、脆弱性検知「検知可」と表示されました。

curlのソフトウェア詳細では、「CPE/PURL割当」タブにcpe:2.3:a:haxx:curl:8.5.0が自動で割り当てられています。「脆弱性×タスク」タブには、関連する脆弱性のタスクが54件表示されました。

同じ内容はAPIでも取得できます。

$ curl -fsS "https://rest.vuls.biz/v1/pkgCpes?filterServerID=${SERVER_ID}" \
    -H "Authorization: ${FVULS_TOKEN}" \
  | jq -c '.pkgCpes[] | {name, version, cpeURI, vulnDetectionStatus}'
{"name":"github.com/curl/curl","version":"8.5.0","cpeURI":"cpe:/a:haxx:curl:8.5.0","vulnDetectionStatus":"detecting"}
{"name":"github.com/madler/zlib","version":"1.3.1","cpeURI":"cpe:/a:zlib:zlib:1.3.1","vulnDetectionStatus":"detecting"}
{"name":"github.com/pcre2project/pcre2","version":"10.39","cpeURI":"cpe:/a:pcre:pcre2:10.39","vulnDetectionStatus":"detecting"}

まとめ

C/C++でソースを同梱したライブラリは台帳に記録されないため、スキャンで脆弱性を検知できません。FutureVulsのC/C++ライブラリ構成識別を使うと、ソースのハッシュ値からリポジトリとバージョンを同定し、脆弱性検知の対象に登録できます。実行例では、同定したcurl 8.5.0に54件の脆弱性タスクが登録されました。

対象は、OSS-Fuzzの管理対象で公式のCPEがあるライブラリです。グループ設定のCPE自動割当も有効にしてください。

運用で困っている点やご要望は、お問い合わせフォームからお寄せください。

参考文献

1. Wei Tang, Zhengzi Xu, Chengwei Liu, Jiahui Wu, Shouguo Yang, Yi Li, Ping Luo, Yang Liu. "Towards Understanding Third-party Library Dependency in C/C++ Ecosystem". Proceedings of the 37th IEEE/ACM International Conference on Automated Software Engineering (ASE 2022), pp. 1-12, ACM, 2022. https://doi.org/10.1145/3551349.3560432