オープンソースのバグ大発生：脆弱性は実際に探している人のおかげで50%近く増加

セキュリティ企業WhiteSourceによると、オープンソースプロジェクトの脆弱性の数は2019年にほぼ50パーセント増加したが、これは探していないものは見つからないという意味で良いニュースと言える。

同社は毎年発行している脆弱性レポートの中で、脆弱性件数の増加はオープンソースセキュリティへの意識の高まりに起因するとしています。これは、近年のオープンソースコンポーネントの普及とコミュニティ全体の成長、そしてデータ漏洩に対するメディアの注目度の高さによるものです。

言い換えれば、バグは常に存在していたのですが、私たちがより注意を払うようになったため、より目立つようになったのです。

昨年報告されたオープンソースの脆弱性は 6,000 件を超え、4,000 件強から増加しました。

「完璧なコードなど存在せず、脆弱性が見つかる可能性は常に存在する」とホワイトソースのCEO兼共同創設者であるラミ・サス氏はThe Registerへの電子メールで述べた。

「オープンソースの脆弱性の問題は、オープンソースコミュニティのあらゆるものと同様に、一度何かが報告されるとすべての情報が公開され、初心者のハッカーでもその脆弱性とその悪用方法を学習し、多数のアプリケーションで実行できることです。」

良い面としては、これらの脆弱性の 85 パーセントは修正とともに公開されており、これは責任ある公開の良い兆候です。

しかし、脆弱性に対するコミュニティの認識は、効果的なコミュニケーションに繋がっていません。既知のオープンソースの脆弱性のうち、最終的に国家脆弱性データベース（NVD）に掲載されるのはわずか84%に過ぎず、掲載されるまでに多少の遅延が生じることも少なくありません。

WhiteSourceの統計によると、NVDの外で脆弱性が報告された場合、最終的にNVDで公開されるのはわずか29%です。つまり、脆弱性情報を見つけるのは容易ではなく、タイムリーに修正される欠陥も少なくなる可能性があるということです。

それでも、WhiteSource は、GitHub の Security Lab のようなコミュニティ重視の取り組みが、セキュリティ研究者、プロジェクト管理者、ソフトウェア ユーザーが問題を報告し、情報をより簡単に一元管理するのに役立っていると評価しています。

この調査では、プログラミング言語別のオープンソース プロジェクトの脆弱性の数と、それらの数が時間の経過とともにどのように変化したかについても調査しました。

WhiteSource によれば、C はコード行数で言えば最も人気のある言語であるため、脆弱性の割合が依然として最も高いものの、他の言語の人気が高まるにつれてその割合は低下傾向にあるという。

しかし、報告書では、「PHP の脆弱性の相対的な数は大幅に増加している一方で、人気が同様に増加している兆候は見られない」と指摘している。

一方、Pythonは人気が高いにもかかわらず、脆弱性の割合が低いという結果に至っています。「これは安全なコーディング慣行の結果であり、Pythonプロジェクトにおけるセキュリティ調査の怠慢ではないことを願う」と報告書は述べています。

2019 年に最も多く見られた共通脆弱性リスト (CWE) は次のとおりです。

プログラミング言語別に分析すると、C を除くすべての言語の上位 3 つは次のとおりです。

WhiteSourceは、これらの欠陥が言語間で共通している理由として、特定の問題を検出する自動スキャンツールの使用を挙げています。また、同社は、情報漏洩は言語間で共通する一般的な問題であるとも指摘しています。

「CWE-79（クロスサイトスクリプティング）は、多くの自動化ツールがあり、初心者のハッカーでも簡単に利用できるため、攻撃者にとって最も悪用しやすい脆弱性の1つです」とサス氏は述べ、CWEは特定の欠陥ではなくカテゴリを表していると指摘した。

オープンソースコミュニティにおける利用の急増に伴い、攻撃者はオープンソースの脆弱性を悪用する可能性に気づき始めています。CWE-79の脆弱性は、容易かつ容易なハッキングに最も利用される脆弱性です。この点を考慮すると、この大幅な増加は理にかなっています。

脆弱性報告数が増加するにつれ、開発チームは、深刻度の低いバグよりも重大なバグの修正を優先できるというメリットを得ています。しかし、共通脆弱性評価システム（CVSS）による脆弱性の深刻度評価方法の変更により、この作業はより複雑になっています。

CVSSv2 は 2007 年 6 月にデビューし、CVSSv3 は 2015 年 6 月に登場し、CVSSv3.1 は 2019 年 6 月に登場しました。それぞれ、重大度の高い脆弱性を構成するものの定義が若干異なります。

WhiteSource によると、最も大きな変化は v2 から v3 への移行で発生し、v2 での重大度 7.6 (10 点満点中) のバグが v3 では 9.8 のバグとして再定義されました。

WhiteSource は、バージョン 3.1 では、重大度の分布が正規分布ではなく、脆弱性の 17 パーセントが重大で、低と評価されたのはわずか 2 パーセントであると主張しています。

つまり、評価されたバグの半分以上が重大または高重大度であるため、ほぼすべてをすぐに修正する必要があるときに優先順位を付けるのが難しいことになります。

「報告される脆弱性の数が増えるにつれて、それらの脆弱性を修正する緊急性も高まります」とサス氏は述べた。「しかし、開発チームはそのペースに追いつくのに苦労しています。」®