オープンソースソフトウェアの脆弱性とライセンスを管理する5つのステップ

ステップ1：OSSが自社にどのように持ち込まれたかを把握する

　オープンソースが社内に持ち込まれる経路は多数あります。典型的な例では、開発者が特定のオープンソースコンポーネントを使用すると決め、そのソースコードをダウンロードし、製品にそのソースコードを組み込みます。

　これは今でもよくあるケースですが、オープンソースが組織内で使われるようになる経路は、ほかにも多数あります。現在では、開発者がリポジトリマネージャと呼ばれるツールを使用することがよくあります。これらのツールを使用すると、開発者は使用したいコンポーネントを指定することができます。

　そして、リポジトリマネージャでは、ソースコードやコンパイル済みのバイナリ、さらにはそのコンポーネントが依存するすべてのファイルをダウンロードできます。

　これらのリポジトリマネージャでは通常、ダウンロードしたオープンソースコンポーネントを、企業が使用している従来のソースコード管理システム外にある、別のリポジトリに保存します。Maven、Nuget、npmなどが、よく知られているリポジトリマネージャです。

　オープンソースが組織に持ち込まれるもう1つの経路は、商用コンポーネントまたは大規模なオープンソースコンポーネントのサブコンポーネントとしてです。単一のトップレベルコンポーネントが複数のオープンソースサブコンポーネントや依存関係を含んでいるのはよくあることです。これらのサブコンポーネントが開示または管理されていないことがよくあります。

　さらに、オープンソースはWebサーバー、オペレーティングシステム、データベースなどのランタイムインフラストラクチャの要素として使用されることがあります。

　これらのコンポーネントはすべて、開発者やグラフィックデザイナー、購買部門、プロフェッショナルサービス、IT管理者など、多くの人々によって持ち込まれる場合があります。これはもはや開発者が関与しないプロセスです。

ステップ2：OSSを探し始める

　オープンソースがどのように選択され、使用されるかを把握したら、どのようなコンポーネントの依存関係、およびコンポーネントの使用、配布方法の評価を開始できます。これは通常、自社の部品表（BOM）の作成、またはオープンソースの開示リストの作成として知られるプロセスです。

　このリストは義務を順守し、OSSポリシーを修正し、公開された脆弱性に対応するために使用されます。組織が順守できないライセンス義務のあるオープンソースパッケージが見つかることがあります。これはライセンスに関するコンプライアンスに違反していることになります。

　このような場合、そのオープンソースコンポーネントは削除する必要があり、その機能は別のOSSコンポーネントまたは同等の機能のコードを作成して置き換える必要があります。

　このプロセスでは、コードベースのレビューや話し合い、スキャンツールが役に立ちます。

ステップ3：自社の開発チームに質問する

　プロジェクトが大きく複雑になり分散されるにつれて、使用されている要素のすべてを検出することはますます困難になります。そのため当該プロジェクトの作成、開発、運営にかかわっている開発者やDevOps、IT部門の人員と定期的に話し合うことが重要になります。

　「どのデータベースを使用していますか？」または「どの暗号化ライブラリを使用していますか？」といった的を絞った質問をすると、当初は見過ごされていた可能性のある他のモジュールの検出に役立ちます。

　単に「どのオープンソースを使用していますか？」と尋ねても、完全なリストが得られることはほとんどありません。いくつか理由はありますが、1つには、どのOSSコンポーネントを選択したかということは、多くの場合、人の記憶や会社の記録に残っていないということが挙げられます。

　また、何をオープンソースと見なすかということに関して、多くの開発者の間で誤解や知識不足があります。

ステップ4：持ち込まれるOSSの管理方法を把握する

　外部コンポーネントの使用を管理するための、一貫した強制的なプロセスが設けられている必要があります。このプロセスにより、オープンソースのライセンス義務を適切に順守することができ、新たな脆弱性にも対処できます。

　複数のチームのそれぞれで、完全性やコンプライアンスのレベルに差があるのはよくあることです。現在のところ、開発者から「リクエストされた」場合にのみコンポーネントを記録している組織もあります。このような企業では、往々にしてオープンソースの中でも大きな要素のみを記録しているか、または開発者によってプロセス順守の程度に差があります。

　スキャン技術を使用してOSSを検出し、追跡している企業もあります。使用しているスキャンツールや行われている分析のレベルにより、検出範囲は異なります。実際のOSSコンポーネントではなく、ライセンステキストのみを検出するツールもあります。パッケージマネージャによって管理されているコンポーネントしか検出できないツールもあります。

　行われている分析のレベルと、検出すべき内容を理解しておくことが重要です。一般的には、より多くのコンポーネントが検出され管理されるようになるにつれて、コンプライアンスの程度が段階的に向上します。

ステップ5：OSSコンプライアンスの証拠を求める

　ポリシーを策定したらOSSを確認して管理し、OSSの義務順守を強制し始めます。この時、コンプライアンスを目に見える形式で確認できるようにしておくことが重要です。

　これらはすべて、効果的なオープンソース管理プロセスの目に見える形式での指標です。

＊＊＊＊＊

　上記の5つのステップに従って、企業内でOSSの適切な使用についての教育を行い、自社内におけるソフトウェアのエコシステムの他の人員にも同じことを実行するように促すことで、オープンソースを活用して最新の強力なアプリケーションを作成することができます。

　しかも同時に、それを実現するオープンソースのライセンスと義務を尊重することもできます。さらに自社製品がどのように構成されているか、それらを構成している外部から入手したソフトウェアコンポーネント、それらの脆弱性の現在の状態についてよく知れば知るほど、製品をより安全でサポート可能なものにすることができるのです。

著者：西浦 詳二

フレクセラ・ソフトウエア合同会社　シニア事業開発マネージャー
産業制御システムの設計、開発実務から、ソフトウェア産業、電気電子産業、および通信事業における事業・サービスの企画、導入に一貫して従事し、技術潮流や産業構造の変化をとらえた事業化の実績多数。
日本ヒューレット・パッカード、ボーダフォン（現ソフトバンク）、野村総合研究所等を経て2016年から現職。
工学修士（光物性工学）。