ソフトウェア工学研究の日々

ソフトウェア工学の学術研究を紹介しています。ソフトウェア開発に関する調査と実験が大好きです。

開発者は使用するライブラリを更新しない

ソフトウェア開発では、画像の読み書きやネットワーク接続など、基本的な処理を提供するライブラリを土台にして、開発したいソフトウェアに固有の機能を作っていきます。

ほとんどの人は、開発を始めるとき、あるいはライブラリを必要とするような機能を実装するときに、ライブラリの名前やバージョンを調べて、その時点での最新版を開発に使います。それで何の問題なさそうにも思えますが、ライブラリの中にはセキュリティ問題などの深刻なバグが発見されることもあり、そういう場合には新しいバージョンに素早く移行することが求められます。ただ、セキュリティに関心のある一部の人々を除くと、ライブラリに新しいバージョンが出たといっても、大して気に留められることもありません。

そんな実態を、少しまじめに調べたのがこの論文です。

arxiv.orgいくつかのセキュリティ問題の報告に対して、横軸に時間、ライブラリの利用者数 (Library Usage, LU) を縦軸に取ったグラフを取ってプロットしてみました。以下は Apache Commons-beanUtils のセキュリティ問題発生時のものです(論文内 Fig.9 を引用)。

f:id:ishiotakashi:20190202221200p:plain

セキュリティ問題の報告に伴うライブラリ利用者数の変化

セキュリティ問題が2014年4月に報告され(図中の黒い縦の破線)、新しいバージョンがリリースされた後も、一定数のユーザが残っていることが分かります。利用者数のカウントは、リポジトリで更新作業をしていることを条件にしているので、「古いバージョンのライブラリを採用したまま、プロジェクトの更新が終わっている」ようなプロジェクトの数は除外しています。

調査対象全体では、 81.5%という多数のプロジェクトが古いバージョンのまま他の作業をしていました。この原因の1つは、個々のライブラリのバージョン更新内容をまじめに追いかけるのは大変である、ということにあります。幸い、2018年になって、GitHub など複数のサービスがセキュリティ警告機能(セキュリティ問題のあるバージョンのライブラリ利用者にメール等で連絡する機能)を提供するようになり、状況はだいぶ改善されました。それでも、ライブラリはバージョンごとに完全に互換性があるわけではなく、新バージョンに更新しようとして失敗する事例があることも報告されています。プロジェクト全体の他の作業で忙しい開発者にとっては、ライブラリの更新を迅速に実行するのは難しいかもしれません。

ライブラリ開発者が互換性を保ってくれれば自動更新ができるのに、という期待もあるかもしれませんが、非互換性の導入にもエラー報告の詳細化や危険な機能の削除など、相応の理由があることが知られています。そのため、ソフトウェアを新しいバージョンのライブラリでテスト実行して安全に更新できそうなときだけ自動で通知する、といった手法も提案されています。 また、本当に今すぐ更新する必要があるのか、セキュリティ問題のあるコードを実際に呼び出しうるか・実行しているかを自動的に判定するソフトウェアというのも研究レベルでは出てきています。以下がそういうプロジェクトの1つです。

github.comこの記事を執筆した時点では、すぐに実用に供するというには難しい開発段階のようですが、いずれは、このようなツールでソフトウェアの状態をチェックし、セキュリティ問題の報告に素早く応答することがソフトウェア開発の標準となるかもしれません。