オープンソースの脆弱性リスクを防ぐために(全5回)1.スキャン!スキャン!スキャン!2.オープンソースソフトウェアの知識のないCEOがビジネスを危険にさらす3.オープンソースソフトウェアの脆弱性とライセンスを管理するための5つのステップ4.オープンソースとサードパーティの使用状況に関する認識不足5.オープンソース戦略のためのアプリケーションセキュリティ
 収益性の高いソフトウェア製品を回収せざるを得なくなったソフトウェアベンダーや、ソフトウェアの脆弱性が検知されていなかったために何百万人ものソフトウェアユーザーが危険な状態にさらされた(ハートブリードなど)、といった事例はあまりにも有名です。
 その原因は何でしょうか?
 それは、商用ソフトウェア製品に組み込まれているオープンソースコンポーネントがオープンソースライセンスに違反していたこと、またはオープンソースコンポーネントがソフトウェア脆弱性を含んでいたことです。
 現在、オープンソースのセキュリティとコンプライアンスにかかわるリスクがまん延しつつあり、ソフトウェアサプライチェーン(※)の全体が脅かされつつあります。
 そして、その悪影響の企業における責任は最終的には、最高経営責任者(CEO)に降りかかってくるのです。
 本稿では、この問題において経営者が果たす役割を取り上げます。
(※)ソフトウェアサプライチェーンとは、ソフトウェアが多段階の開発、製作等の工程から流通を経て最終需要者に提供され、運用、管理、保守、そして廃棄されるまでの一連のプロセスを指します。
使用しているオープンソースを把握しているか?
 現在、平均すると商用ソフトウェアパッケージのコードの半分がオープンソースであるとのレポートがあります。ほとんどのソフトウェアエンジニアは、作業を迅速化するためにオープンソースコンポーネントを使用しています。
 しかしながら、使用しているオープンソースコンポーネントを管理し、コードを使用するための法的義務やオープンソースコンポーネントに含まれている可能性のあるソフトウェア脆弱性リスクを把握しているソフトウェアエンジニアはほとんどいません。
 さらに悪いことに、ほとんどのソフトウェア企業のリーダーはこのような状況が発生していることさえ認識していません。また、どのオープンソースソフトウェア(OSS)が使用されているかを把握していない場合、オープンソースのセキュリティとライセンスコンプライアンスのリスクを最小限に抑えるための適切なプロセスと自動化を確実に適用することができません。
 ソフトウェア企業のCEOは、最高技術責任者(CTO)、セキュリティ担当者、エンジニアと話し合い、使用しているオープンソースのライセンスコンプライアンスとセキュリティ運用の状態を把握しておく必要があります。自分たちの組織のソフトウェアサプライチェーンとオープンソースのライセンスコンプライアンスとセキュリティ運用について調査する場合、CEOが検討すべき重要分野は多数あります。
ソフトウェア製品開発における過去10年間の変化
 この10年間で、ソフトウェア製品の開発方法は大きく変化しています。かつてはCEOでさえ、自社が社外のサードパーティに対して持っている依存関係を明確に認識していました。この依存関係は概して商業的な性格を持っていたため、その技術の入手やライセンス供与には、NDA(秘密保持契約)や契約書、支払いなどのはっきりと目に見える活動が必要でした。
 しかしその後、非常に高品質で容易に入手でき、ライセンス料金が不要なコンポーネントが無数に得られるという、オープンソースの世界が出現しました。最初はゆっくりと、そしてその速度はどんどん増していき、まるで一夜にして爆発的に広がったかのようなありさまでした。
 このオープンソースのビジネスモデルは、迅速に常にネットワーク上で提供されることやオープンソースの使用に対する社会的な効果と相まって、数百、数千ものOSSコンポーネントがソフトウェア製品に組み込まれ、追加されることに最適な環境を生み出しました。
 場合によっては自社製品に、自社開発のコードよりもオープンソースのコードのほうが多く使用されていることもあります。残念なことに、ほとんどの企業が製品を迅速に作成するためにオープンソースを活用していながら、自分たちが使用しているソフトウェアコンポーネントに関連付けられているオープンソースのライセンスを尊重することを怠っています。
 “オープンソースは無料だが義務がないわけではない”という事実は、CEOやその他経営陣にとっては驚くべきことなのです。これらの義務は、著作権表示やライセンステキストを表示することから、その企業の製品に使用されたソースコードすべてを開示することまで、広い範囲にわたっています。
 ほとんどの企業が、自分たちが依存しているオープンソースのごく一部しか認識していないことが、調査により示されています。しかし、どのコードを使用しているかを把握していなければ、そのライセンスに指定されている義務を果たすことは不可能です。さらにソフトウェアには、企業の製品に悪影響を与えるバグや脆弱性が含まれている場合があります。
 また、どのコードを使用しているかを把握していなければ、検出されたソフトウェア脆弱性を修正するアップグレードやパッチの適用が遅れるおそれがあります。
 ほとんどの業務プロセスでそうであるように、重要または必要であると経営トップが認めない限り、それらが実行されることはありません。オープンソースのライセンスコンプライアンスは、オープンソースを使用する場合の任意事項ではありませんが、実際には技術業界では任意事項であるかのように扱われてきました。
 CEOやその他の経営陣が、オープンソースを使用する際に不可欠な、これらの法的義務とセキュリティ上の義務を尊重することの重要性を示すことが大切です。
教育や時間管理など多面的なプロセスで対応する
 オープンソースコンプライアンスにかかわる技術的な「デメリット」に対しては、多面的なプロセスが必要です。そのプロセスに従わなければならないという状況を作り出し、従うことが当然とみなされるようにしなければなりません。
 これらのプロセスのなかで最も重要なのは、教育です。企業内の全員が、オープンソースのライセンスとコンプライアンスの基礎を理解している必要があります。これは現在のテクノロジー企業では、オープンソースがほとんどのビジネスプロセスや業務で使用されているためです。
 グラフィックデザイナーはオープンソースのアートワークを使用し、IT部門はオープンソースアプリケーションをインストールし、メンテナンスしています。また、マーケティング部門は、既存のオープンソースコンテンツを基に編集や制作を行っています。同様の例は、ほかにも数えきれないほどあるでしょう。
 この基礎を学び、コンプライアンスが必要であることを知れば、残りの作業ははるかに容易になります。社員たちは、オープンソースを選択する際により注意深くなり、また、自分たちが使用しているオープンソースコンテンツを尊重できるようになります。さらには、多くの場合、適切な方法でそのコミュニティに貢献できるようになります。
 教育の次に実行すべきことは、時間管理です。さらにオープンソースコンプライアンスと脆弱性管理を組み込んだ技術/ビジネスプロセスを作り、それに従うことです。オープンソースに対する義務を順守するための時間もリソースも与えられないとしたら、これらの義務が無視されても不思議ではありません。
 法律、セキュリティ、企業イメージに対するリスクの懸念だけでも、これを企業のプロセスに組み込むのに十分な理由となりますが、これは経営トップが「コンプライアンス実現のための時間を作るように」、と命じるまで行われないのがしばしばです。
 また、オープンソースの専門家からなる社内チームを集めてオープンソースレビューボード(OSRB)を結成することも推奨されます。このチームはポリシーを作成し、オープンソースとサードパーティの使用に関する質問に答える情報センターの役割を担当できる、技術、法務、ビジネスの担当者で構成されている必要があります。
CEOによるテスト
 最後に、CEOが外部からの視点で、「オープンソースライセンスとセキュリティコンプライアンスが適切に扱われていかどうかを簡単にチェックできるかどうか」を確認する必要があります。
・自社製品のためのサードパーティライセンス通知は簡単に見つけられますか?
・コピーレフトスタイルのオープンソースライセンスを使用するためのソースコードディストリビューションは、容易に入手できますか?
・オープンソースやサードパーティのソフトウェア脆弱性によるアップグレードやパッチ適用のためのプロセスや計画は策定されていますか?
・コンプライアンス文書のスポットチェックを行ってプロセスが順守されている確認をするように求めましたか?
・使用しているオープンソースプロジェクトに対して、必要なサポートを提供していますか?
・ベンダーに対して、オープンソースの開示やコンプライアンス文書を要求しましたか?
 これらはすべて、オープンソースの適正な使用がどの程度完成しているかを測るための、有効なテストです。
 適切な規範を示し、サプライヤにコンプライアンスを求めることで、現代の企業はオープンソースを正しく使用しており、その点で立ち遅れることから来る悪影響から自分たちと顧客を保護することができるのです。
*****
 次回は、オープンソースを活用するにはどうしたらいいかを、5つのステップで説明していきます。
著者:西浦 詳二
フレクセラ・ソフトウエア合同会社 シニア事業開発マネージャー
産業制御システムの設計、開発実務から、ソフトウェア産業、電気電子産業、および通信事業における事業・サービスの企画、導入に一貫して従事し、技術潮流や産業構造の変化をとらえた事業化の実績多数。
日本ヒューレット・パッカード、ボーダフォン(現ソフトバンク)、野村総合研究所等を経て2016年から現職。
工学修士(光物性工学)。

オープンソースの脆弱性リスクを防ぐために・第1回 スキャン!スキャン!スキャン!

SD-WANに取り組むアライドテレシス、DPIによるアプリケーションルーティングで拠点のクラウド活用を支援
▲[特別企画]の他の記事を見る

関連記事

特別企画
オープンソースの脆弱性リスクを防ぐために・第1回 スキャン!スキャン!スキャン!
2018年3月5日

特別企画
オープンソースソフトウェアの脆弱性とライセンスを管理する5つのステップ
2018年3月7日

特別企画
オープンソースとサードパーティの使用状況に関する認識不足
2018年3月8日

特別企画
オープンソース戦略のためのアプリケーションセキュリティ
2018年3月9日

投稿者 semorina

コメントを残す

メールアドレスが公開されることはありません。 が付いている欄は必須項目です