OSS脆弱性管理サービス

右のグラフのとおり、NVDで公表された脆弱性（CVE）の件数は、年々増加傾向で推移し、サイバーセキュリティーの脅威・リスクが年々増大しています。
脆弱性を悪用したサイバーセキュリティーの脅威・リスクに対しては、ベンダー製品は、脆弱性が発見された際にベンダーサポートを受けることで解決します。しかし、OSSに脆弱性が発見された際は、OSSの利用者自身が日々、OSSの脆弱性情報の収集から対処までの管理を行う必要があります。
OSS無しでは語れなくなってきている現在において、日々のOSSの脆弱性情報の収集から対処までの管理を怠ると、その影響は、賠償責任、製品・サービスの長期間の利用停止、ブランドイメージや企業の社会的な信頼性の失墜など、復旧・回復にかかる費用は状況にもよりますが億円規模になる可能性もあり、はかり知れません。

脆弱性管理とは、利用しているソフトウェアを一覧やSBOMなどで可視化し、そのソフトウェアの脆弱性を日々監視・認識し、遅滞なく修正などの対応し、その状況までを管理することです。
脆弱性管理の日々の作業には、まず、米国のNISTが管理するNVDサイト、日本のJPCERT/CCとIPAが共同で運営しているJVNサイトなどに掲載される脆弱性（CVE）情報を確認し、発見した脆弱性がどのようなものかを正確に把握することから始まります。
次に、発見した脆弱性情報が該当するバージョンおよび機能かをコミュニティーサイトなども調査し、最終的に、利用しているソフトウェアに影響する脆弱性か、該当するかしないかの判断を行っていきます。ここまでを利用しているソフトウェアについて毎日作業します。
その後は、回避・修正情報の収集、脆弱性対応（回避・修正）によって影響を受ける機能の範囲の調査・特定、回避・修正の優先順位・時期の検討、対応の判断を遅滞なく実施することとなります。なお、今後はさらに、法令に従い通知する作業が加わることになります。

このように、脆弱性情報監視・収集、脆弱性情報調査、内容精査、該非判定は、利用しているOSSについて毎日作業しなければなりません。それ相当の工数を要することとなるでしょう。
また、この作業には、脆弱性の専門的な知識が必要で簡単な作業ではありません。

例えば、まず脆弱性情報監視・収集の作業です。
たぶん、ブラウザーで検索する場合、ほとんどが右の図の米国のNISTが管理するNVDサイトで提供されている検索機能を用いて利用しているOSSについてCVEが公表されていないかを毎日確認するでしょう。
この検索1つをとっても、ただ、OSS名が分かっているので、CVE全文に含むOSS名をキーワードとし、その日に公表されたCVEだけに絞り込むために日付での絞込みを組合わせて検索しても、ベンダー、バージョンが異なるCVEまでもが検索結果に表示され、その中から該当するベンダー、バージョンの情報を1つ1つ確認し探さなくてはなりません。この作業を利用しているOSSについて繰り返し行わなければなりません。
仮に、利用しているOSSのCPE（製品を識別するための共通のプラットフォーム名の一覧）が分かっていたとして、CPEと日付で検索すれば、該当するベンダー、OSS、バージョンのCVEを絞り込むことができますが、利用している様々なOSSについて繰り返し行わなければならず、それ相当の工数を要することになります。ただし、この段階でバージョンを絞り込んだ判断を下すのは避け、そのCVEをOSSコミュニティーで調査し、内容精査・該非判定の作業で最終的にそのCVEが本当に影響するかを判断した方が良いでしょう。この脆弱性情報監視・収集の作業をツールを導入して効率的に行うこともできますが、監視・収集の作業だけ効率的にしても以降に記載する作業はツールを導入しても実施しなければならず、かつ、ツールを導入することでそのツールの運用スキルと工数が別途必要となります。そのため、ツール導入にあたっては、脆弱性管理における全体作業を鑑みた費用対効果をお客様が判断する必要があります。

次に脆弱性情報調査の作業です。
この作業では発見したCVEが、どういう攻撃の手口か、どういう影響をおよぼすのか、その他にどういう情報源があるのかの調査・確認を行います。これには、それ相当の脆弱性の専門的な知識が必要です。
まずは、[Description] から、そのOSSの脆弱性の概要を理解します。米国のサイトなので、当然、英語力も必要です。
次に、[Severity] から、CVSSによる深刻度と、CVSSによる攻撃元区分、攻撃条件の複雑さなどから攻撃される影響・可能性を確認します。ここでも、CVSSという脆弱性の標準化された評価基準の専門的な知識が必要となります。
なお、[Description]、[Severity] とともに [Weakness Enumeration] の内容も確認しなければいけません。ここでも、CWEという脆弱性タイプの専門的な知識が必要となります。
最後に、 [References to Advisories, Solutions, and Tools] から、次の内容精査・該非判定の作業につながる、その他にどういう情報源があるのかを確認します。 その情報源がどういう属性かも ”Resource" から確認します。
やはり、この脆弱性情報調査の作業についても、発見したCVEに対してだけとなりますが、これまでの通り、いくつかの作業には、それ相当の工数を要することになります。

最後に内容精査・該非判定の作業ですが、ここでは [References to Advisories, Solutions, and Tools] をもとにした調査や独自にそのOSSコミュニティーの情報ポータルサイトや開発リポジトリーサイトの調査を行い、最終的にそのCVEが本当に利用しているOSSに影響があるかを判定していきます。
いくとおりもの様々な作業で、ここでは書き表せない作業となりますが、いつの段階からの機能、攻撃の手口、攻撃の影響について裏付けを行う作業で、そのCVEが本当に利用しているOSSについて影響があるのかふるいにかけていき、最終的な判断を伴う重要な作業であり、それ相当の専門的な知識と工数が必要となります。

ここまでのとおり、このような作業を積み重ね、製品毎に検出した個々の脆弱性の対応状況を纏めて管理する必要があり、多大な工数が毎日必要となると同時に、脆弱性の専門的な知識を持った専任のエンジニアを充てる必要があることがお分かりになったかと思います。