特別企画
オープンソースソフトウェアの脆弱性とライセンスを管理する5つのステップ
オープンソースの脆弱性リスクを防ぐために 第3回
2018年3月7日 06:00
オープンソースの脆弱性リスクを防ぐために(全5回)
- 1.スキャン!スキャン!スキャン!
- 2.オープンソースソフトウェアの知識のないCEOがビジネスを危険にさらす
- 3.オープンソースソフトウェアの脆弱性とライセンスを管理するための5つのステップ
- 4.オープンソースとサードパーティの使用状況に関する認識不足
- 5.オープンソース戦略のためのアプリケーションセキュリティ
外部から入手したソフトウェアコンポーネント(以下、外部コンポーネント)に起因するセキュリティとコンプライアンスのリスクがまん延しつつあり、現在のソフトウェアサプライチェーン(※)の構造自体を脅かしかねません。その例として、ハートブリードなどは、いまだ記憶に新しいと思います。
現在多くの企業や組織では、自社製品に自社開発のコードよりもオープンソースのコードの方が多く使用されています。残念なことに、ほとんどの企業が製品を迅速に作成するためにオープンソースソフトウェア(OSS)を活用していながら、自分たちが使用しているソフトウェアコンポーネントに関連付けられているオープンソースライセンスを尊重していません。
OSSは無料で入手することができますが、それに伴う義務がないということではありません。これらの義務は、著作権表示やライセンステキストのコピーを渡すことから、企業の製品に使用されたソースコードすべてを開示することまで、さまざまです。
ほとんどの企業が、自分たちが依存しているオープンソースのごく一部しか認識していないことが、データにより示されています。しかし、どのコードを使用しているかを把握していなければ、そのライセンスに指定されている義務を果たすことは不可能です。
さらに外部コンポーネントには、自社の製品に悪影響を与えるバグや脆弱性が含まれている場合があります。使用しているコードを把握していなければ、既知のソフトウェア脆弱性を修正するアップグレードやパッチの適用が遅れるおそれがあります。
とはいえ、オープンソースには大きな価値があります。こうした危険性をふまえた上で、オープンソースを活用するにはどうしたらいいかを探っていきましょう。
(※)ソフトウェアサプライチェーンとは、ソフトウェアが多段階の開発、製作等の工程から流通を経て最終需要者に提供され、運用、管理、保守、そして廃棄されるまでの一連のプロセスを指します。
5つのステップでの検出、管理、および順守
OSSのコンプライアンスや脆弱性の管理に関する問題が発生した場合に、多くの場合、最初に自問するのは、「どのようにすれば使用しているオープンソースコンポーネントを把握できるか?」ということです。
以下は、自社が実施している作業を把握し、依存しているOSSを検出、管理、および順守するためのプロセスを策定するうえで役立つ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年から現職。
工学修士(光物性工学)。