オープンソースのパラドックス：リスク、公平性、受け入れについて

オープンソースは常に矛盾した性質を持っています。熱意のある開発者によって開発され、無料で提供されるソフトウェアでありながら、世界最大級の企業によって収益化され、資金が提供されているのです。かつては「社会悪」とみなされ、勝ち目のなかった存在でしたが、イノベーションとテクノロジーの進歩にとって私たちがこれまでに見た中で最大の原動力となっています。オープンソースの世界では常にパラドックスが存在しますが、それが最も顕著となるのは、セキュリティの脆弱性を理解するときです。

25 年前、ソフトウェアの欠陥の命名と追跡を標準化するために共通脆弱性識別子 (CVE) プログラムが策定されました。sendmail などの一般的なソフトウェアに複数の問題があり、特定の脆弱性の識別があいまいなことがよくあった時代に CVE が登場し、明確さと体系化をもたらしました。初期には Security Focus や Bugtraq などの取り組みがありましたが、強く望まれていたグローバルシステムを提供したのが MITRE の CVE でした。最初の年である 1999 年には 894 件の脆弱性がカタログ化されました。これは比較的少量でしたが、一貫して早期に識別することの必要性を浮き彫りにしました。この歴史的背景は、CVE が現在直面している課題を理解する上で重要です。

この間に、ソフトウェアの脆弱性を取り巻く状況は劇的に変化しました。このプログラムの最初の 6 年間で、導入が広範に進んだことから、割り当てられた CVE の数は 450% 以上急増しました。この成長は爆発的に続き、2017 年までに CVE は約 15,000 件に達し、わずか 2 年で 125% 増加しました。2023 年には、さらに 50% 増加して 29,000 件以上に達しました。この爆発的な増加は、ソフトウェアの複雑化、ソフトウェアの可用性の向上、および CVE を採用するベンダーの増加を裏付けています。

脆弱性の状況は劇的に拡大し続けています。2024 年には、Linux Kernel が CVE 採番機関 (CNA) ステータスを得たこともあって、割り当てられた CVE は 39% 増加し、40,000 件を超えました。モバイルアプリケーションやゲーム開発など、他のソフトウェアセクターが CVE の正式な追跡を始めれば、この成長率は大幅に加速する可能性があります。その量が膨大であるために、脆弱性管理戦略の再評価が必須となっています。

「すべてにパッチを適用」は持続不可能

私たちが長年にわたって主張してきたことは、「すべてにパッチを適用」という長年の考え方は、物事が単純であった時代では管理可能であっても、現在の複雑な環境では持続不可能 であり、戦略的にも適切ではないということです。それは真のリスク評価を欠いた運用です。すべての脆弱性に対して、リソース負荷の高い即時の修正が必要なわけではありません。最も重要なのは、悪用の可能性や潜在的な影響といった要素です。特定された欠陥に対してすべて同じように対処することは、良性と悪性の両方の腫瘍に対して積極的に手術を推奨することに似ています。実際の脅威のレベルとその対処法自体に内在するリスクを無視することになります。

アクションの優先順位付けの重要な指標は、実際の悪用です。Cybersecurity and Infrastructure Security Agency (CISA) の Known Exploited Vulnerabilities (KEV) カタログなどのソースを活用したデータ分析では、悪用率は常に極めて低く、これまで毎年 0.5% 未満です。これは、およそ 200 件に 1 件の脆弱性が実際に攻撃されている計算になります。このことを理解した上で、より実用的でリスクベースのアプローチに焦点を当てる必要があります。

私たちは、悪用される可能性が最も高く、かつ大規模な損害を引き起こす可能性のある脆弱性をターゲットにすることへと重点を移さなければなりません。このような脆弱性は一般に、高レベルの特権への昇格により、認証されていない攻撃者がリモートアクセスを実行することが可能になります。これは「Critical (重大)」または「Important (重要)」として分類されるものです。修正作業を高リスクまたは高影響の脆弱性に集中させることで、利用可能なリソースでリスクを最大限に低減できます。これは必然的に、脆弱性によってもたらされるその他の低いリスクを戦略的に受け入れることを意味します。それらのリスクとは、ターゲットにされる可能性が低い、または悪用されても重大な影響がもたらされる可能性が低いものであり、優先順位が中程度または最も低いとされる問題です。 

効果的なリスク管理とは、すべての脆弱性を排除することではありません。発生する可能性の高い真の脅威をもたらすものを優先し、その他の管理できるリスクは意識的に受け入れることです。

オープンソースとの関係

パッチが適用されていない脆弱性に関する懸念は、オープンソースに集中しがちですが、その透明性が主な理由となっています。コードと CVE の両方を見ることができるのです。対照的に、プロプライエタリーのベンダーは、修正する価値がないと判断した低影響の不具合については公開しないことが多く、リスクの状況が不透明になります。オープンソースで CVE として公開されるような小さな欠陥については、プロプライエタリー・ソフトウェアでは報告されない、修正されない、またはサイレントでパッチが適用されることがあります。

この可視性の違いがダブルスタンダードを生み出します。「既知の脆弱性がない」ことを要求するポリシーについては、本質的にオープンソースの透明性を対象としたものであり、必ずしもオープンソースのリスクの高さを対象としたものではありません。実際のところ、組織は日常的に使用するプロプライエタリー・ソフトウェアにおける公開されていない小さな欠陥のリスクを暗黙的に受け入れています。真のリスク管理を行うには、このことを認識する必要があります。オープンソースに内在している可視性からもたらされる不利な状況を鵜吞みにするのではなく、悪用の可能性とすべてのソフトウェアへの影響に焦点を当てた、一貫性のある明示的なリスク評価を適用する必要があります。

脆弱性管理の分野で真の公平性を実現するには、オープンソースの異なる点を認識する必要があります。オープンソースは設計上はるかに透明性が高く (それは良いことです)、脆弱性がより多く存在するように見えます。オープンソースでは、プロプライエタリー・ソフトウェアで暗黙に受け入れているリスクを明示的に受け入れることが求められます。

これを裏付ける興味深いデータがあります。Red Hat と、有名な大手プロプライエタリー・ソフトウェアベンダーに対して Red Hat が実施した 2024 年のリスクレポートのデータを比較すると、前述の仮説を裏付ける非常に興味深い知見が得られます。プロプライエタリー・ベンダーが影響の極めて大きい (つまり、容易に悪用され得る) バグだけを作成しているのでない限り、「Critical (重大)」、「Important (重要)」、「Moderate (中程度)」、「Low (低度)」の問題の分布は同様になるはずです。つまり、それらのベンダーが引き起こすセキュリティバグが常に大きく、厄介で面倒なものでない限り、影響の少ないセキュリティバグが多く発生することになります。しかし、数値を見てみると、重大度の低い問題はごくわずかです。参考までに、このベンダーは Red Hat と同じ 4 段階の重大度評価スケールを使用しています。

しかしながら、脆弱性レポートのメトリクスは、現実を表しているとは限りません。オープンソース・プロジェクトから透過的に報告された重大度の低い CVE (2024 年における Red Hat の脆弱性の 92% が中程度および低度) は、このプロプライエタリー・ベンダー (2024 年に中程度および低度と評価されたのが 5.5%) よりも多いのですが、これは相対にリスクが高いことを示している訳ではなく、主に開示の考え方の違いが反映しています。

膨大な量や重大度の評価を追跡するよりも、重要な要素である実際の悪用に焦点を当てることをお勧めします。2024 年に、Red Hat ソフトウェアに影響を与えたオープンソースの脆弱性のうち、実際の状況でいずれかのプラットフォーム上で悪用されたことが判明したのはわずか 0.26% (4,200 件を超えるうちの 11 件) でした。数を優先すると、現実の脅威が最も小さい問題に多大なリソースを浪費されてしまうことになります。

プロプライエタリー・ベンダーもオープンソース・ベンダーも、基本的に最も重要な問題の修正を優先する傾向があります。主な違いは、多くの場合、パッチが適用されていない脆弱性や影響の低い脆弱性に関する透明性です。私たちはすでに、クローズドソース・ソフトウェアに生じるこれらのリスクを暗黙的に受け入れていることになるのですが、今こそ、実用的なリスクベースの評価を、オープンソースを含むすべてのソフトウェア全体に明示的に適用するときです。考え方としては、私たちは皆同じです。つまり、重要なことを修正し、重要でないものについては優先順位を低くします。

セキュリティリーダーとして、当社は脆弱性をただ数えるだけのやり方から脱却すべきだと考えています。悪用の可能性に関するインテリジェンスと潜在的なビジネスインパクトを中心とした戦略を推進しましょう。攻撃される可能性のある一部の脅威を厳密に優先するプロセスを実装し、管理可能なその他のリスクを理解し、意識的に受け入れる文化を育むことが重要です。組織を真に脅かす脅威の軽減にリソースを振り向けましょう。

このトピックをより深く掘り下げたい場合は、私が昨年、このトピックについて 2023 年のデータを使用して OpenSSF の SOSS/Fusion Conference で行った講演をご覧ください。今年は 2024 年のデータを反映して更新し、VulnCon 2025 で講演しました。