こんにちは、MaineK00nです。普段はオープンソースの脆弱性スキャナ「Vuls」のメイン開発者として、機能開発やコミュニティ活動に携わっています。この記事では、OSS開発者自身の視点からCSS2025の模様をレポートします。
昨年に引き続き、今年もコンピュータセキュリティシンポジウム(CSS)に参加してきました。
CSSは、情報セキュリティに関する国内最大級のシンポジウムであり、産学官から多くの研究者や技術者が集まり、最新の研究成果や技術動向について議論する場です。
我々フューチャーは、オープンソースの脆弱性スキャナ「Vuls」と、そのクラウド版であるSaaS「FutureVuls」を開発しています。今回は、主にOSS Vuls開発チームとしての研究成果を発表する立場で参加しました。
今年はスポンサーとして協賛し、ブース出展も行いました。さらに、併設のOSSセキュリティ技術ワークショップでは、Vulsチームから研究発表1件とパネルディスカッションへの登壇も行い、非常に内容の濃いイベントとなりました。
本記事では、当日の現地の熱気や議論の様子をレポートします。
TL;DR
- CSS2025にて、Vulsチームが取り組む「脆弱性情報の統合管理と再現性向上」に関する研究発表を行いました。
- パネルディスカッションでは、欧州CRA法への対応を軸に、SBOMの標準化、EOLソフトウェアのリスク、脆弱性報告の自動化など、製造業が直面するリアルな課題が議論されました。
- FutureVulsの独自調査から見えた「EOL済みOSSの利用実態」など、現場のインサイトを共有しました。
研究発表「広範な脆弱性情報の統合管理と履歴追跡」
研究発表では、Vulsで脆弱性検知を提供する中で感じていた2つの課題について、OSS Vulsチームの取り組みについて発表しました。
課題1：広範な脆弱性情報の統合管理
1つ目の課題は、広範な脆弱性情報をどのように取り扱いやすく管理・提供するかです。
この課題に対して、我々は広範な脆弱性情報の差異を吸収する統合フォーマットを提案しました。以前であれば、ベンダごとに提供されるOVALやCSAF/CSAF VEX、OSVなどのフォーマットを読む必要がありました。標準化されているフォーマットなのであれば、読み方は一通り理解すれば十分なようにも思えますが、ベンダごとに微妙に表現方法が異なります。また、一つのベンダから複数のフォーマットで脆弱性情報が提供されることもあり、それぞれのフォーマットが得意・不得意な表現は何か？を理解する必要もありました。
よって、各種フォーマットを統合することで、Vulsで使う脆弱性情報を扱いやすくすることができました。Red HatのデータソースをOVALからCSAF VEXへ変更したときに、OVALとCSAF VEXで比較する必要がありましたが、一旦統合フォーマットで比較することができ、非常に効果的でした。また、脆弱性情報DBを作るデータを統合フォーマットにすることで、以前ブログ投稿した自前のデータをvuls.dbに追加可能になるといった副産物もありました。
3. 自前で持っているデータソースをvuls.dbに追加したい - あなただけのvuls.dbを作ろう！
課題2：脆弱性検知の再現性向上
2つ目の課題は、脆弱性検知の再現性を向上させることです。
Vulsを運用しているユーザから、誤検知しているのではないか？といった報告を頂いたとき、そのユーザが検知した当時の環境が再現できず、それが脆弱性情報の間違いなのか、Vulsのバグなのか、それともユーザの勘違いなのかを説明することに非常に苦労していました。
そこで我々は、Vulsで使う脆弱性情報DBを定期的に作成して、提供することにしました。以前のVulsで使っていた脆弱性情報DBは、ユーザ自身が脆弱性情報DBを更新する必要があり、さらに一次データソースから直接、脆弱性情報DBを作成するため、ユーザが作った脆弱性情報DBを、報告時点では完全に再現できませんでした。この問題に対して、GitとGitHub Container Registryを組み合わせて、脆弱性情報DBと脆弱性情報DBを作るためのデータ（一次データソースに限りなく近いデータ、統合フォーマットで記述されたデータ）を履歴管理することで、再現性を向上させました。
今回、脆弱性情報DBだけでなく、脆弱性情報DBを作るためのデータまで管理することで、脆弱性情報DBを作り直すことや、脆弱性情報DBの変化について、一次データソースの変化を根拠に説明できるようになりました。
これらをまとめて、定期的にデータの取得・変換を行い、脆弱性情報DBを作成、そして，各所で履歴付きで保存を行い、データを提供する基盤をデータハーベストとして提案しました。
今後の課題として、脆弱性情報DBのサイズを最適化や差分の論理的な説明能力の向上、データハーベスト基盤の安定を行っていきたいと思います。
論文や発表スライド、デモ資料は以下のリポジトリにあります。
https://github.com/vulsio/css2025-vuls2
パネルディスカッション「欧州サイバーレジリエンス法(CRA)で必要となる技術要素」
公式プログラムにもあるように、以下のテーマでパネルディスカッションが行われました。
パネルディスカッション：欧州サイバーレジリエンス法(CRA)で必要となる技術要素
概要：CRA対応を行う際に各企業やセキュリティベンダーが考えなくてはならない要素「OSSサプライチェーン」「Actively Exploited」「SBOM」についてのパネルディスカッションを行います。
登壇者のご紹介
登壇者は以下の通りです。
- モデレータ
- 須崎 有康氏（情報セキュリティ大学院大学）
- パネリスト
- 高橋 明彦氏（富士通株式会社）
- 余保 束氏 (ルネサスエレクトロニクス株式会社)
- 小保田 規生氏 (ソニーグループ株式会社)
- 神戸 康多 (フューチャー株式会社)
- 金井 遵氏 (株式会社 東芝)
- 面 和毅氏 (サイオステクノロジー株式会社)
CRA（欧州サイバーレジリエンス法）とは？
OSSセキュリティ技術ワークショップのパネルディスカッションでは、欧州サイバーレジリエンス法(CRA)で必要となる技術要素について議論しました。CRAとは、EU市場で販売されるデジタル製品にセキュリティ対策を義務付ける法律です。
議論の中心となったのは、ソフトウェアの構成要素を一覧化する「SBOM（Software Bill of Materials）」や、サポートが終了した「EOL（End-of-Life）ソフトウェア」への対応、そして「サプライチェーンセキュリティ」といった、まさに現代のソフトウェア開発者が直面する課題です。
議論のテーマ
主に以下の様なテーマで議論が交わされました。
OSSスチュワードの役割
- OSSスチュワードの役割: CRA対応において、OSSスチュワードはどのような役割を果たすべきか
- OSSスチュワードとは、組織内で利用するOSSの選定やコンプライアンス、セキュリティを管理する役割を指します。CRAではサポート期間中の脆弱性対応が義務化されるため、最初のOSS選定が非常に重要になります。安易に選んでしまうと、将来的に多大なメンテナンスコストが発生しかねません。
- パネルでは、OSS選定の際にOpenSSF Scorecardのような指標を活用することが有効であると紹介されました。一方で、Scorecardのスコアが高いからといって絶対安全というわけではなく、各チェック項目が何を意味するのかを理解して使う必要があるといった、ツールの特性や注意点についても言及されました。
- さらに、コミュニティの活発さや、企業による支援の有無、メンテナンス体制など、長期間サポートされそうなOSSを見極めるための実践的なコツについても議論が交わされました。
EOLソフトウェアへの対応
-
EOLソフトウェアへの対応: EOL(End of Life)を迎えたソフトウェアを使い続けるリスクと、その対策
- CRAでは脆弱性対応が義務付けられますが、これは実質的に、製品に組み込まれたEOL済みのOSSに発見された脆弱性も製造者が対応しなくてはならないことを意味します。パネルでは、この「OSSのEOLリスク」が現在の議論で見過ごされがちであるという問題提起がなされました。
- この点について、Vuls/FutureVuls開発チームの神戸より、FutureVulsで得られた情報を分析した独自調査の結果を共有しました。企業のシステムで実際に利用されているOSSのうち、無視できない数のコンポーネントが既にEOLを迎えているという実態が明らかになった点を共有しました。この事実を基に、パネリストからは「どうやってサポートの切れたコンポーネントの脆弱性に対応し続ければよいのか」といった、製造業者の直面する苦悩や課題が赤裸々に語られました。
- 議論の中では、こうした課題への根本的な対策として、OSS開発者コミュニティを企業がより積極的に支援していくべきではないか、といった提案もなされました。
脆弱性報告への対応と報告期限の遵守
- 脆弱性報告への対応と報告期限の遵守: 「積極的に悪用されている脆弱性」が報告された際の、迅速な対応方法と24/72時間報告の課題
- 「積極的に悪用されている脆弱性」を迅速に特定するための脅威インテリジェンスとして、CISA KEVやVulnCheck KEVなどが紹介されました。それぞれの情報の信頼性や掲載速度といった特徴を理解し、さらにベンダーのアドバイザリなど他の情報ソースと組み合わせて総合的に判断する必要性が議論されました。
- また、CRAが定める24時間や72時間といった厳しい報告期限を遵守するためには、組織内での迅速な連携が不可欠です。現場の開発チームとセキュリティ部門が密に協力する体制の重要性や、トリアージや影響範囲の特定を高速化するための「自動化」が鍵となる点などが強調されました。
高精度なSBOMの作成
- 高精度なSBOMの作成: SBOMの精度をいかにして高め、CRAの要求を満たすか
- CRAではSBOMの提出が求められていますが、具体的なフォーマットが明記されていないため、製造業の現場では「どのようなSBOMを、どの程度の粒度で作成すればよいのか」という混乱が生じている、という生々しい課題が語られました。
- 現在、有償・無償を問わず様々なツールでSBOMを生成できますが、同じ規格（SPDXやCycloneDX）でもツールによって解釈の差から「方言」が生まれてしまい、互換性に問題が出ることが指摘されました。特に、多くの企業が数珠つなぎになっているサプライチェーンにおいて、各社が異なるツールで生成したSBOMをどうやって統合・管理していくのか、その難しさが議論の中心となりました。解決策の一つとして、業界やサプライチェーン単位でフォーマットを標準化していく動きも紹介されました。
- また、SBOMに「推移的依存関係（直接の依存関係だけでなく、その依存先がさらに依存しているコンポーネント）」を含めるべきかという論点も、まだ揺れていることが紹介されました。CRA施行までに要件が変更され、すべての推移的依存関係の記載が必須となる可能性も示唆されました。この点について、弊社の神戸からは「推移的依存関係がなければ脆弱性管理は不十分」であると指摘。Log4Shellの際に影響範囲の特定が困難を極めた事例を挙げ、推移的依存関係を含めたSBOM管理がなければ、CRA施行後も同様の混乱が再発しかねない、という警鐘を鳴らしました。
展示ブース
今回のCSS2025では、協賛企業としてブース出展も行いました。
学会という場に合わせ、単なる製品紹介は一切せず（笑）、我々が取り組んでいる研究内容をポスターセッション形式で展示し、ご来場いただいた皆様に説明・デモを実施しました。
ブースでは、多くの方々と脆弱性管理の課題について直接お話しすることができ、大変有意義な時間となりました。
関連ブログ記事
今回の発表内容に関連するトピックについては、以下の記事でも詳しく解説しています。ぜひ合わせてご覧ください。
- CRA/SBOM関連
- 脆弱性管理/SSVC関連
- Vuls/vuls.db関連
- サプライチェーンセキュリティ
おわりに
今回のCSS2025では、研究発表とパネルディスカッションを通じて、脆弱性管理の奥深さと、コミュニティとの連携の重要性を改めて実感しました。特にパネルディスカッションでは、CRAという大きな規制の波に対して、現場のエンジニアがどのような課題に直面し、どう立ち向かおうとしているのか、生の声を聞くことができ、非常に刺激的な時間でした。
我々フューチャーは、OSS Vulsと商用版であるFutureVulsの両輪で脆弱性管理の世界をより良くしていきたいと考えています。今回得られた知見や課題感を持ち帰り、Vulsの機能開発に活かすことでOSSコミュニティへ貢献すると共に、FutureVulsを通じてエンタープライズのお客様が抱える課題解決にも繋げていきます。
来年のCSSでも、さらに進化した研究成果を報告できるよう、チーム一同精進してまいります。