アプリに含まれるライブラリが原因で“脆弱性あり”に判定される「偽陽性」問題

使われているようで実際には使われていないライブラリ

　米セキュリティ企業Contrast Securityは世の中で使われているアプリケーションが内部で使用しているオープンソースのライブラリについて調査した報告書「2021 State of Open-source Security Report」を公開しました。これはJavaや.NET、Nodeで書かれたアプリケーションを分析したもので、多くのアプリケーションが数多くのオープンソースのライブラリを含んでいる実態を示すとともに、そのようなライブラリに脆弱性が存在したり、「悪意のあるコード」が仕込まれたりした場合のリスク、すなわち「アプリケーションのサプライチェーンのリスク」を訴える内容となっています。その一方で、実際には機能として使われていないライブラリが多く、アプリケーションに対する簡易な脆弱性診断では「偽陽性」となるケースが少なくないことも示しています。

　まず、アプリケーションに含まれているライブラリ数をまとめたのが以下の図です。

図1

　調査対象全体で平均するとアプリケーションあたり118のライブラリを含んでいますが、ばらつきが大きく、25未満が37％と最も多い一方、100以上も合計するとほぼ同じ割合となっています。しかし、興味深いのは言語によってかなりの違いがある点です。ライブラリの数を言語ごとに分類したのが以下の図です。

図2

さらに細かく見たのが以下の図です。

図3

　.NETのアプリケーションでは含まれるライブラリが1つだけのものが43％を占め、アプリケーションあたりのライブラリ数の平均値がわずか6であるのに対し、Nodeでは8割以上が350以上のライブラリを含んでおり、1000以上のライブラリを含むものも2割あります。.NETのアプリケーションに含まれるライブラリの数が少ない理由についてレポートでは「.NET言語がMicrosoftという単一の企業によって高度に標準化され、かつ管理されているため」としています。なお、Javaについては.NETとNodeの中間で、アプリケーションあたりのライブラリ数の平均は125となっています。

　次にNodeのアプリケーションで使われることの多い上位25のライブラリを挙げたのが以下の図です。

図6

　注目すべきは、これらの25のライブラリがいずれも9割以上のアプリケーションで使われている点です。つまり、これらのライブラリの1つでも何らかの脆弱性が存在したり、悪意のある改ざんが行われたりした場合、その影響は極めて多くのNodeアプリケーションに及ぶ可能性があることを意味します。

　ところで、一般的には多くのライブラリに依存していれば、それだけ「サプライチェーンのリスク」も高まるのですが、ここで改めてライブラリの依存関係を考えてみましょう。

　AというアプリケーションがBというライブラリを使うとします。一方、ライブラリBは、その機能をフルに実現するために、Cという他のライブラリを使うとします。すると、アプリケーションAは必然的にライブラリCも含まざるを得なくなります。しかし、もしアプリケーションAがライブラリBの機能のうちライブラリCに依存する機能を使わなければ、アプリケーションとしてはライブラリCを含んでいても、実際にはライブラリCは使われない、このレポートでの表現を使って言い換えれば、ライブラリCは「アクティブではない」ということになります。この場合、ライブラリCにどのような深刻な脆弱性が存在していても、アプリケーションAは基本的に影響を受けることがありません。ところが、一般的な脆弱性管理または簡易な脆弱性検査においては、ライブラリCに脆弱性が存在すれば、そのライブラリを含むアプリケーションAも無条件で脆弱であると判定されてしまうのです。これは明らかに「偽陽性」です。

　そこで今回のレポートでは、含まれているライブラリが実際に使われている、つまり「アクティブである」かどうかについても調べた結果を紹介しています。言語ごとにまとめたのが以下の図です。

図7

　アプリケーション全体でアクティブなライブラリは38％、つまり62％のライブラリが実際には使われていないことが分かります。さらに言語ごとにアクティブなライブラリの数をまとめたのが以下の図です。

図8

　先ほどの図3と比較すると、Nodeのアプリケーションには多くのライブラリが含まれているものの、その大半がアクティブでないことが分かります。また、先ほどの図6で紹介したNodeのアプリケーションで使われることの多い上位25のライブラリについて、それを含んでいるアプリケーションの中で実際にアクティブな割合をまとめたのが以下の図です。

図11

　ライブラリとしてはいずれも9割以上のアプリケーションに含まれていましたが、そのうちアクティブな割合は2割から4割程度にとどまっています。

　このようにアプリケーションに含まれているライブラリの多くが実際には使われておらず、そのようなライブラリに脆弱性があっても実際にはアプリケーションに何の影響もないにもかかわらず、一般的な脆弱性管理ではアプリケーションに脆弱性があると判定されてしまう「偽陽性」のケースが少なくないのです。そこで、CVE番号が振られた脆弱性のうちアクティブでないライブラリなどに起因するものの割合を示したが以下の図です。

図25

　深刻度の高い脆弱性については、アプリケーション全体では18％が偽陽性ですが、Nodeのアプリケーションにおいては偽陽性が8割にも及んでいます。つまり、これだけの割合の脆弱性に対して、極端に言えば「無駄な脆弱性対応」をさせられていたわけです。

　このような脆弱性に関わるリスクのほかに、今回のレポートでは、どのようなライセンスのライブラリが使われているかを調査した結果とともに、オープンソースのライセンスに関わるリスクも紹介しています。まずオープンソースのライセンスを、使用に制約のない「permissive」なものと、GPL（General Public License）に代表される「copyleft」なものの2つに分け、「permissive」なライセンスとして、Apache、Javaおよび.NETライセンス、MIT、Nodeライセンスを挙げています。一方「copyleft」なライセンスのうち、GPLを高リスク、LGPL（Lesser GPL）、MPL（Mozilla Public License）、EPL（Eclipse Public License）などを中リスクと見なし、このような「copyleft」のライブラリを使用するにあたってはコードの取り扱いについて十分に注意する必要があると警告しています。

　今回の調査結果を踏まえてレポートのまとめには、アプリケーションの開発者に対して「継続的な可観測性の確立」が重要なポイントの1つとして提示されています。これはどのライブラリがアクティブか、また、それぞれのライブラリのライセンスがどのようなものかなどを完全に把握すべきというものです。

　アプリケーションの開発者はライブラリを使うにあたっては、そのライブラリのどの機能を使っているのか、また、その機能に他のライブラリを必要としているのかなどを把握しておいた方が良いのは確かです。少々理想主義的にも見えますし、そもそもContrast Securityとしては、それを実現できる自社の製品やサービスを宣伝する目的で今回のレポートを公開しているのは明白ですが、それでも可能ならばやるべきでしょう。とにかく、Contrast Securityの製品やサービスを使わないとしても、このような可観測性の確立を「手動」で行うのは現実的ではないので、そのためにどのような仕組みや仕掛けが必要かを検討するところからまずは始めてみてください。

　今回のレポートはあくまでJavaや.NET、Nodeで書かれたアプリケーションというかなり限定されたものを対象としており、世の中にある全てのアプリケーションの傾向を示すものではありません。しかし、どのような言語で書かれたアプリケーションであっても同様の問題やリスクは間違いなくあり、今回のレポートの内容には参考になるところが少なからずあるでしょう。うまく使ってください。