この内容は、FOSSA社のブログ記事を元に日本語に翻訳・再構成した内容となっております。
はじめに
オープンソースソフトウェアは現代のアプリケーションのいたるところで使われており、平均的なコードベースの90%以上をOSSが占めているとも言われています。OSSを扱ったことのある人なら、OSSの使用を規定するライセンスの多くを知っていると思います。MITライセンスやApache License 2.0といった寛容なライセンスや、GPLv2やGPLv3のようなコピーレフトライセンスまで、さまざまなライセンスがあります。
しかし時折、変わった条項のライセンスが適用されたOSSプロジェクトに出くわすこともあります。GitHubで約15,000個のスターを獲得しているDaprは、依存関係の1つであるGolangのモンキーパッチプログラム「bouk/monkey」に関する問題が発生した際に、この状況に陥りました。
Daprおよび、そのほかのbouk/monkeyに依存している何百ものプロジェクトにとっての問題は、bouk/monkeyのライセンスに書かれている以下の内容でした。
I do not give anyone permissions to use this tool for any purpose. Don't use it.
I’m not interested in changing this license. Please don’t ask.
私は誰に対しても、いかなる目的であれ、このツールを使用する許可を与えていません。使わないでください。
私はこのライセンスを変更することに興味はありません。聞かないでください。
つまり、bouk/monkeyのライセンスは、配布されるアプリケーションでの使用を禁止しているだけでなく、内部での使用も禁止しています。そのため理論的には、まだ何らかの目的でbouk/monkeyを使用している企業は、著作権侵害の責任を負うことになります。
あらゆる使用を禁止するライセンスが適用されているGitHubプロジェクトはあまり見たことがないため、この状況は非常に珍しいものですが、組織が依存関係の最新かつ正確なリストを持っていない場合にどのようなことが起こりうるかということを思い出させてくれます。
bouk/monkeyの概要
bouk/monkeyは2015年に公開されたGolang用のモンキーパッチプログラムです。ほかのモンキーパッチプログラムと同様に、実行時に実行ファイルの書き換えを行います。一方で、ほかのモンキーパッチプログラムとは異なり、bouk/monkeyは使用されることを意図していませんでした。
esoteric.codesというウェブサイトの最近のインタビューで、bouk/monkeyの作者であるBouke van der Bijl氏は以下のように説明しています。
"I never intended to use it or for it to be used,I only created it to see how people would react and for my own enjoyment.
And it has certainly been a great success in that regard.
It is almost a piece of modern art in that way - the project is completely irrelevant at this point,only the reaction to it is what matters."
「使うつもりも、使われるつもりもなく、ただ人の反応を見るために、そして自分の楽しみのために作ったのです。
そして、その点では確かに大成功を収めています。
これは現代アートのようなもので、この点でプロジェクトはまったく関係なく、それに対する反応だけが重要なのです。」
このような機能上の問題やライセンス条件にもかかわらず（作者であるvan der Bijl氏がリポジトリをアーカイブしたことは言うまでもありませんが）、多くのプロジェクトがbouk/monkeyに依存しています。この記事を書いている時点では、AWS-LabsやBaiduなどに属するプロジェクトを含む474のプロジェクトの依存関係に存在しています。
依存関係の把握とライセンスコンプライアンス
大規模な組織がホストするOSSプロジェクトを含め、何百ものプロジェクトがbouk/monkeyに依存しているという事実は、かなり驚くべきことのように思えます。しかし、現代のソフトウェア開発においては、理想的ではないにしても、このような見落としは理解できるものです。
結局のところ、平均的なアプリケーションには何十もの異なるオープンソースコンポーネントとライセンスが含まれています。実際、GitHubの最近のレポートによると、分析したプロジェクトの依存関係は平均して700近くになっています。
そして、適切なポリシーとツールがなければ、依存関係や関連するライセンスについて、正確かつ最新のリスト維持することは非常に困難になります。これにより、以下のようなさまざまな問題が発生します。
- OSSプロジェクトの著作権者が、ライセンス条件に従わずにコードを使用している企業に対して訴訟を起こす可能性がある
- OSSユーザーが特定のコピーレフトライセンスを使用した場合、コードベースの一部をOSS化することを余儀なくされる可能性がある
- 開発チームは、特定のライセンスが適用されているコンポーネントを交換しなければならず、余分な作業やリリースの遅れが生じる可能性がある
bouk/monkeyの場合、それに依存するプロジェクトはライセンスに準拠していませんが、作者であり著作権者であるvan der Bijl氏は現在、違反者に対して行動を起こしている様子はありません。しかし前述のようにそれは必ずしもそうであるとは限りません。
また、前述のesoteric.codesの記事でvan der Bijl氏が述べているように、bouk/monkeyに依存しているプロジェクトの多くがこれをテストのためだけに使用していることにも注意が必要です。配布するアプリケーションのための効果的なライセンスコンプライアンスポリシーとツールを持っている組織であっても、内部ツールの一部として使用しているがために、bouk/monkeyを見逃している可能性があります。この点については、後ほど詳しく説明します。
依存関係の把握と脆弱性管理
組織が依存関係を把握していない場合に発生する問題は、ライセンスコンプライアンス違反だけではありません。セキュリティ上の重大な問題も発生する可能性があります。
最近のGitHubの調査によると、GitHubのプラットフォーム上にあるプロジェクトの59%が今後1年間にセキュリティ警告を受けると予想されています。また、最近の別のレポートによると、プロジェクトの大部分は少なくとも4年間更新されていないOSSの依存関係を含んでいます。これは、OSSのユーザーが新しいセキュリティパッチを定期的に適用していない、あるいはバージョン管理のベストプラクティスにしたがっていない可能性が高く、問題が発生する可能性が高くなります。
複数のOSSプロジェクトに影響を与える共通の脆弱性としては、FOSSAの2020年の分析で最も多く発見されたCWE-79（クロスサイトスクリプティング）が挙げられます。なおCWE-20が僅差で2位となっています。
依存関係の識別に関するベストプラクティス
最近のアプリケーションには膨大な量のOSSが使用されているため、手動プロセスやレガシーツールを使って依存関係、ライセンス、潜在的なセキュリティ脆弱性を追跡すると、誤検知のようなコストのかかる問題が発生する可能性があります。ソフトウェア構成分析（SCA）ツールを導入すると、依存関係の特定、ライセンスの遵守、脆弱性の管理が自動化されます。スタッフの作業時間が大幅に短縮され、ライセンスコンプライアンスとセキュリティのリスクが軽減されます。
また一般的なルールとしてSDLC（ソフトウェア開発ライフサイクル）のできるだけ早い段階でセキュリティテストやコンプライアンステストを実施することが有効です。これによって開発チームが問題のあるコンポーネントの交換にリソースを割かなければならない可能性を減らすことができます。
SCAの最も一般的な使用例は、配布されるアプリケーションの一部となるコードをスキャンすることですが、bouk/monkeyの事件はすべての依存関係の正確なインベントリを維持することの価値を示しています（たとえそれが内部使用のみのプログラムであってもです）。内部ツールのコードを分析することが配布されるアプリケーションの分析よりも優先されるべきではありませんが、リスクを回避する企業は、内部ツールであってもOSSコンポーネントを含むすべてのソフトウェアにSCAを使用することを検討すべきです。
