継続的アップデートツールVersionEyeがオープンソースに

VesionEyeは，自社の名前を冠した，プロジェクト依存関係の更新を支援する継続的インテグレーションツールをオープンソースとして公開した。“継続的アップデート”という造語が表すように，さまざまなソフトウェアライブラリを対象とした更新通知やライセンスチェック，セキュリティ上の脆弱性情報の提供などを行なうツールだ。VersionEyeを開発したRobert Reiz氏は，ソフトウェアをオープンソース化することで，プライベートなリポジトリにアクセスするコードベースの信頼性と透明性の向上を目指している。

同ツールはGitHubやBitbucket，Stashなどに統合されて，Java，Ruby，Node.JSなど，一般的なプログラミング言語で記述されたプロジェクトとパッケージマネージャを対象とした依存関係の更新検索を行なう。最新の追加は.NETのサポートだ。

VersionEyeを使用するユーザは，まず自身のアカウントでリポジトリにログインする。するとソフトウェアが全プロジェクトをスキャンして対象となる依存関係を検索し，旧版になったライブラリを定期的に通知してくれる。ライセンスのホワイトリストを使用すれば，自身のプロジェクトに適したライセンスタイプの定義や，セキュリティ脆弱性の警告を有効にすることも可能だ。

一般的なライブラリでは，定期的にバグや脆弱性のフィックスが行われることが多い。VesionEyeの創設者でCEOのRobert Reiz氏がソフトウェアの更新について調査した結果によると，毎年100万以上に及ぶ新バージョンが公開されている中で，その90%がAPIの変更を伴わないという意味でのマイナーチェンジないしパッチであるという。 しかし，そういった修正は，当然ながらそれを利用するアプリケーションに統合されて初めて意味を持つ。研究からは，旧版の依存関係を使用した場合，次のようなリスクがあるとしている。

• セキュリティ: 依存関係の対象がセキュリティ上の脆弱性を含むかも知れない。このような脆弱性がパッチ適用によって更新されなければ，そのシステムは危険にさらされる可能性がある。
• 柔軟性: 依存関係を最新に保つことで，変更への迅速な対応が可能になる。古いバージョンに比較して新しいバージョンは，アップデートが容易だからだ。新機能も常に利用可能になる。
• 安定性: アップデートにはバグフィックスが含まれる場合があるので，システム全体の安定性や正確性の向上に寄与する。
• 互換性: システム環境への外部的な変更によって，システム機能が停止する可能性がある。

同ツールとそのオープンソース化について，Robert Reiz氏から話を聞くことができた。

InfoQ: 依存関係更新の通知はユーザにとって，どのようなメリットがあるのでしょう？

VersionEyeは，さまざまなパッケージマネージャの100万におよぶソフトウェアライブラリを継続的に監視することで，ライブラリの現行バージョンが何かを理解しています。例えばGitHubのpackage.jsonファイルを監視して，古くなった依存関係を日々通知してくれます。Eメールの通知周期はプロジェクト毎に設定が可能で，毎日，毎週，毎月，あるいは無効を選択できます。VersionEyeはMavenやNPM，PIPなど12のパッケージマネージャをサポートし，それらのシンタックスを理解します。

InfoQ: ライブラリの中には，コピーレフトライセンスを使用しているために，企業での使用には馴染まないものもあります。これについてはどうでしょう？

VersionEyeのクローラはソフトウェアライセンスに関するメタ情報も収集しています。現時点で600万のソフトウェアアーティファクトに関するライセンス情報を保持していますが，その数はさらに増えています。VersionEyeのライセンスのタブには，すべてのプロジェクトの依存関係とそのライセンスが一覧表示されます。さらに，プロジェクトのさまざまなライセンスの分布を表示するチャートもあります。オプションとして，例えばMITやApacheなど，特定のライセンスのみを登録したホワイトリストを設定することもできます。プロジェクトにホワイトリストが設定されると，VersionEyeは依存関係で使用されているすべてのライセンスをそのホワイトリストに対してチェックした上で，違反するものがあれば通知を行います。VesionEye Marven Pluginではさらに，ライセンス違反があった場合に，CIサーバでのビルドをブレークすることも可能です。当社の企業ユーザの中には，これとまったく同じ方法で使用しているところもあります。

InfoQ: セキュリティ脆弱性のチェックはどのように動作するのでしょう？

Java，PHP，Ruby，Node.JS，Pythonの５つのセキュリティデータベースを集約して，セキュリティ脆弱性からパッケージマネージャの対応するアーティファクトへのマッチングを行います。VersionEye Maven Plugin，VersionEye Gradle Plugin，VersionEye SBT Pluginなどで適切な設定が行われていれば，プロジェクトにセキュリティ脆弱性の影響のある場合には，CIサーバでのビルドをブレークすることもできます。誰かが重要ではないという判断を下せば，プロジェクト単位でセキュリティ脆弱性をミュートすることももちろん可能です。

InfoQ: VersionEyeを効果的に運用するためには，開発プロセスの適用が必要なのでしょうか？

プロジェクトがGitHubかBitbucketにあるのならば，自分のGitHubないしBitbucketアカウントに無償でサインアップして，VesionEyeで監視したいプロジェクトファイルを選択するだけです。そうすれば自動的に，プロジェクトへのEメールを受け取るようになります。他に何かをする必要はありません。
さらに一歩進みたいのであれば，ビルドやテストのライフサイクルにVersionEyeを統合することも可能です。主要なビルドツールのほとんどに，VersionEyeの公開APIを使用したVersionEye用のネイティブプラグインが用意されています。これらのプラグインは，セキュリティとライセンス違反のチェックをビルド時に実行して，必要ならばビルドをブレークします。多くのソフトウェアプロジェクトや開発者に対してQAを用意しなくてはならない大企業にとって，これは理にかなった方法です。

InfoQ: VersionEyeをオープンソースにしたのはなぜですか？

オープンソースにしたのは，ソフトウェアをもっと幅広く提供して，オープンソースコミュニティからのコントリビューションを求めたかったからです。
当社はこれまで，VMWareのイメージとしてVersionEyeのエンタープライズバージョンを販売していましたが，イメージの安全に提供するためのプロセスに時間がかかる上，楽しいものではありませんでした。ソフトウェア販売の成果はありましたが，大変だったのです。しかも企業は，透明性やセキュリティを重視します。自分たちのインフラストラクチャ内で動作するブラックボックスが何をしているのか，正確に把握することができないからです。
今の私たちには，VMWareイメージのセキュリティを気にしたり，コードの機密性を守ったりする必要はありません。ユーザとしても，もうブラックボックスソフトウェアについて心配する必要はなくなりました。すべてがオープンソースになれば，ディストリビューションやメンテナンス全体がずっと簡単になりますし，大企業の望む透明性や信頼性も手に入るようになります。

InfoQ: ビジネスモデルはどのように変わりましたか？

昨年はソフトウェアを販売していましたが，現在はVesionEye APIやホストされたソフトウェアへのアクセスとサポートを販売しています。コードはGitHubから，DockerイメージはDocker Hubから，無償で取り出すことができます。ただし自分自身のVersionEyeをローカルで立ち上げた場合には，ローカルデータベースに何も入っていません。ローカルデータベースのアップデートはVersionEye APIの同期メカニズムを介して可能ですが，これは有償となっています。代わりに自分自身でJavaクローラを実行することも可能ですが，クローリングフレームワーク全体をメンテナンスしたいという人はいないでしょう。VersionEye APIからデータをフェッチした方が，ずっと簡単で安価です。