コンプライアンス
オープンソースコードのセキュリティリスクおよびベストプラクティスは何か？
オープンソースのコードは過去10年でますます使用されるようになり、今では大多数の商用ソフトウェアで使われるようになっています。世界中の開発者が、共通の技術やコードの機能をインターネット上で絶えず共有しています。
オープンソースのコードは過去10年でますます使用されるようになり、今では大多数の商用ソフトウェアで使われるようになっています。世界中の開発者が、共通の技術やコードの機能をインターネット上で絶えず共有しています。アプリケーションチームに求められるスピードと需要は高まり、かつては年に数回のアプリケーションのリリースでビジネスが行われていたのが、今では週または日に数回の頻度となっています。この急激な加速により、業界全体が「ウォーターフォール」や「反復型」のプロジェクト開発手法から「アジャイル」への移行を後押しされ、急拡大する需要に対処しています。
オープンソースのコードは無数のソースから成り立っています。中でもコードの再利用、サードパーティライブラリ、開発者向けダウンロードが主流となる傾向にあります。また、あるプロジェクトのコードをほかで再利用することも一般的なことです。例えば、プロジェクトにコンサルタントを起用しており、1時間あたり250ドルを支払っているとします。この場合、このコンサルタントは前年に別のクライアントのプロジェクトで使ったものと同じコードを使用しているのだということを理解しましょう。（クライアントXのプロジェクトで機能しているコードがあり、クライアントYも似たようなことをしているなら、コードを再利用してお金を節約しようとなるわけです）。
（出典：https://www.slideshare.net/denimgroup/create-a-unified-view-of-your-application-security-program-black-duck-hub-and-threadfix）
オープンソースコードの利用例として、Capital One Bankを取り上げます。2010年代には、同社はウォーターフォール型の開発手法を採用していました。規制の厳しい金融業界に身を置くこの組織は、現在では日常業務の一部としてオープンソースを利用しており、自社プラットフォームの多数のコンポーネントをオープンソースで構築しているほどです。同社は2012年の時点では「オープンソースにノーと言う」という考え方であり、オープンソースに友好的ではありませんでした。しかし、やがて彼らは自分たちが以下のものを利用していることに気づき始めます。
- Java（オープンソース）
- Linux（オープンソース）
- Apache（オープンソース）
- Eclipse（オープンソース）
そしてすぐに、自社環境をオープンソースで構築していることを自覚しました。同社は商用のソースコード管理からオープンソースシステムである「Subversion」と独自のアーキテクチャを使った管理へと移行することで、オープンソースのコードを基盤の一部とした本番アプリケーション（自社開発）を立ち上げることに成功しました。立ち上げの際には法的審査など、オープンソースコードの使用に伴うリスクを軽減する具体的なプロセスを導入したことで、法令違反やサイレントなコードリリースを行うことなしに立ち上げを実施することができたのです。
Capital Oneにとってのオープンソースの価値は、次のように述べられています。「オープンソースソフトウェアを使用することで、ビジネスの観点で多くの強みが得られます。すでに動作している機能を再利用できるだけでなく、ビジネスで必要となる機能のカスタマイズや、機能自体の改善を行うための十分な柔軟性も備わっています。また、オープンソースを利用することは、本質的により大きなコミュニティが開発する技術によってソフトウェアを構築することを意味しています。これにより、旧式の技術に依存する可能性を大きく減らすと共に、より大きな人材エコシステムにアクセスすることができます」 – John Schmidt氏、プロダクトマネージャ、Capital One
オープンソースは完全無料にあらず
オープンソースのコードによくある誤解は、それが「無料」であるというものです。子犬を引き取るのと同じで、受け入れるのは良いにしても、その後世話をして餌をやる必要があります。オープンソースコードの使用から恩恵を受けるためには、適切な人材と技術を確保し、オープンソース特有のリスクを軽減する必要があるのです。
オープンソースの法的リスク
- ライセンス：ソフトウェアの著作者がコードに対する権利を所有
- パーミッシブ・ライセンス（クレジットの付与）vs.コピーレフト・ライセンス（ソースコードの配布と開示＋関係するコードの共有が必要）
- コードの使用は「あるがまま」（著作者への要求はできない）
- 変更要求またはプルリクエストが必要
- 企業秘密の開示（知的財産権侵害）
- 特許ポートフォリオに対する評価の低下
- M&Aの影響
- 風評リスク
実際、Capital OneやFacebookをはじめとする大企業の多くには、オープンソースに関する法律顧問が在籍しています。こうした人材は「法律および技術顧問」の立場にあり、上記の法的問題へのアドバイスを行っています。たとえば、M&Aにおけるデューディリジェンスの際にオープンソースの問題についてアドバイスし、買収後は統合チームと連携して作業を行います。
オープンソースのセキュリティリスク
- 脆弱性 – 平均でコードベースあたり64件の脆弱性があり、修正までに1,500日以上かかります。開発プロセスが防御の第一線となります。
- 開発者の当事者意識
- 出所不明のソフトウェア
- 設定と環境の継続的監視
リスクを軽減するためには、オープンソースのリポジトリをスキャンする技術が欠かせません。マニフェストファイルの検索（特定および分析）と、直接的・間接的な依存関係の把握（および既知の脆弱性をフラグ付け）ができるサービスは必須です。こうした技術を自社のコードリポジトリに統合すれば、自社プロジェクトに関連するリスクを特定することもできます。そして、開発者レベルでは、チケットシステムに課題管理を組み込んで（またはプルリクエストを作成して）修正に役立てます。これにより、コードに対するオーナーシップを確保し、コードをライフサイクル全体で適切に扱うことにつなげられます。また、同じプルリクエストが発生するたびに、スキャンと更新パッチのリクエストも必ず発生するため、このような課題管理に対する保守と検査（修正）も必要です。
組織において、コードに対するオーナーシップを持ち、そのコードを保守し、リリースごとのアプリケーションのセキュリティの責任を持つという文化を形成するには時間がかかります。しかし、これはオープンソースをより安全にするために最も重要なことです。オーナーシップと責任はコードを安全に保つことにつながるからです。さらに、技術的なチェックシステムを導入して継続的に実施することで、チーム全体で関与して安全性を維持することに貢献できます。
オープンソースコードの脆弱性を緩和する4つのベストプラクティス
- 特定：オープンソースのインベントリを維持
- 分析：オープンソースの脆弱性とライセンスを追跡
- 修復：修正とパッチ適用、アップデート
- 監査：継続的な監視
オープンソースの脆弱性やライセンスのリスクが手痛い失敗につながることを防ぐために、SecOpsチームはTrend Micro Open Source Security by Snykなどのソリューションも活用できます。これにより、アプリケーションの開発期間中にオープンソースのインベントリを保護し、可視性を高めてリスクを早期に特定するとともに、継続的な監視によって時間の経過に伴うリスクの拡大を最小化することができます。
参考記事：
- 「Manage Open Source Code Security Risks」
by Aaron Ansari