企業が注意すべき、オープンソース活用に共通する6つの注意点とは：脆弱性対応、セキュリティ、ライセンス、ガバナンス

オープンソースは、利用する企業に相応のメリットをもたらす。とはいえ、オープンソースを利用する過程で開発チームが直面する無視できない注意点もある。

[Chris Tozzi，TechTarget]

　オープンソースが企業にもたらす利点には、コストをあまりかけずに機能拡張を通じてソフトウェア機能をカスタマイズできる点がある。だが、オープンソースには周囲に影響を及ぼす問題点もある。オープンソースを社内コードベースに組み込む場合や、オープンソースツールを社内のツールセットの一部として利用する場合は、セキュリティ、プライバシー、管理に関して6つの重要な課題が伴う。

1. オープンソースのセキュリティの脆弱性を管理する

　オープンソースソフトウェア（OSS）だからといって、自社専用のクローズドソースソフトウェアよりもセキュリティが甘いとは限らない。ただし、大きな違いの一つとして、ソースコードに脆弱（ぜいじゃく）性が見つかった場合、その情報が開示される可能性が高い点が挙げられる。

　悪意を持つ攻撃者は、オープンソースライブラリやアプリケーションビルドの脆弱性を含むバージョンを利用する企業システムを悪用することを目的に、そうした脆弱性情報の開示を注視していることが多い。これは自社専用のコードではあまり問題にはならない。なぜなら、一般的に企業は自社ソフトウェアの脆弱性に関する情報を開示することを避けるからだ。

　脆弱性対応の課題に先手を打つには、オープンソースを使用する企業は、自社が使用するオープンソースのライブラリ、アプリケーションなどのリソースを入念に追跡する必要がある。同時に、これらのリソースに既知の脆弱性があるかどうかも確認すべきだ。この目的に役立つのがソフトウェアコンポジション解析（SCA）ツールだ。コードベースを自動的にスキャンし、コードベースに含まれるオープンソースコンポーネントを特定するとともに、セキュリティの脆弱性が潜む可能性のあるコンポーネントにフラグを立てられる。

2. OSSを最新状態に保つ

　クローズドソースソフトウェアは、ソフトウェアベンダーが自主的にメンテナンス、アップデート、パッチ適用をするのが一般的だ。そのため、メンテナンス、アップデート、パッチ適用をする時間、リソース、専門知識が不足している開発チームには大きなメリットになる。オープンソースプラットフォームの中には、Red Hatの「Red Hat Enterprise Linux」（RHEL）や「Kubernetes」の商用ディストリビューションなど、特定のソフトウェアベンダーが積極的にサポートを支援するプラットフォームもある。

　ただし、ほとんどの場合、OSSを最新状態に保つ責任は、そのソフトウェアを利用する企業にある。OSSを最新状態に保つことができなければ、バグやセキュリティの脆弱性を含む古いコードを運用するリスクが生じる。使用するオープンソースコンポーネントを全て最新状態に保つための集中管理コンソールや自動アップデートプロセスを用意しなければ、こうした課題はさらに悪化する。この点が、自社専用のソフトウェアスイートに費用をかけるメリットとして強調されることが多い。

　この課題も、オープンソースアプローチに取り組む企業にとってSCAツールが重要な理由の一つになっている。SCAツール自体が自動アップデート機能を提供するわけではないが、自社にどのようなオープンソースコンポーネントが存在し、それぞれの現在バージョンがどのようになっているかを追跡するのに役立つ。こうした追跡情報を基に、ソフトウェアチームはオープンソースコンポーネントを監査し、それを最新状態に保つ自社独自のプロセスを作成できる。幸い、「Linux」のディストリビューションなど、新たなバージョンがリリースされる都度、インストール済みのライブラリやアプリケーションを自動的にアップデートするパッケージマネジャーを提供するOSSもある。

3. 悪意を持つオープンソースコードを使用しない

　ソースコードにバグやセキュリティの問題が含まれていても、それは意図的な悪意ではなく開発者の見落としに原因があるのが一般的だ。とはいえ、第三者が悪意を持って悪用の手段としてオープンソースを利用する可能性は依然残っている。例えば、機密データを盗み出し、その情報を他のオープンソースチャネルを使って公開するよう設計されたコードなどもある。

　この問題の対処法は、コードをやみくもに信頼しないことだ。社内で作成するソフトウェアに使用するのと同等あるいはそれ以上に厳しい審査プロセスをオープンソースコードに適用する。作成者が曖昧な、または匿名のオープンソースコードを使用しないのもベストプラクティスの一つだ。実績のない開発者コミュニティーや企業が関係していないWebサイトやリポジトリから無作為にオープンソースコードをダウンロードすることには注意が必要だ。

4. オープンソースを必要以上に共有しない

　オープンソースのコードを利用する開発者が、自身が作成したコードをオープンソースプロジェクトに提供してそのプロジェクトに貢献する可能性は大いにある。例えば、そうした開発者は、既存のオープンソースライブラリを最適化またはアップデートしたいと考えたり、自身の作業をコードのオリジナルの作成者と共有したいと考えることがある。

　オープンソースの精神にものっとった素晴らしい考え方だ。とはいえ、こうした行為により、ソフトウェアチームが自社専用のコードや社内の機密データをパブリックなオープンソースリポジトリに誤ってアップロードしてしまうリスクもある。こうしたミスは、開発者がコードベースの中から意図するよりも広い範囲を共有してしまったり、日常行っているように社内システムに関する機密情報をコード内のコメントに残してしまったりするなど、さまざまな場面で起きる恐れがある。

　機密のコードやデータを誤って公開するリスクを緩和する方法の一つとして、社内開発者がオープンソースプロジェクトにコードを提供できるタイミングと方法を規定する明確なガバナンスポリシーを確立することが挙げられる。こうしたポリシーには、コードを公開する前にスキャンすることや、オープンソースリポジトリにアップロードするコードに潜む可能性のあるプライバシーやセキュリティのリスクをチェックする包括的なレビュープロセスを実施することなども含めるようにする。

5. オープンソースのライセンスに違反しないようにする

　オープンソースには多数のライセンスがあり、それぞれ条項も異なる。オープンソースのオリジナルの作成者のクレジットを利用者に求めるライセンスもあれば、帰属のルールのないライセンスもある。

　重要なのは、利用するコードのライセンス条項を理解し、順守することだ。とはいえ、オープンソースには多数のライセンスがあり、それぞれ要件が異なるため、容易ではない。その上、開発者は必ずしもライセンス条項を理解する専門家だとは限らない。オープンソースのライセンスは間違って解釈されることが多く、開発者は適切に利用していると考えていても、ライセンス条項に違反してしまうことがある。

　まずは、オープンソースの多様性と複雑性について開発者を指導すべきだ。そして、ライセンスとフェアユースの要件を明確にするのに法務チームの専門知識が必要になることがあるため、開発チームと法務チームが密接に連携することも欠かせない。最後に、全てのオープンソースコンポーネントとそれに関連付けられるライセンスを追跡することも重要だ。

6. オープンソースのセキュリティポリシーを標準化する

　オープンソースのコードの使用を統制するために、明確で一貫性のあるポリシーを確立し、それを実践するのに苦労している企業が多いことも、オープンソースに関する問題の一つだ。多種多様な開発者にオープンソース利用の判断を委ねれば、それぞれ異なる規範やプラクティスを採用する可能性があり、標準ポリシーを実現するのは難しくなる。

　この課題には簡単な解決策はない。だが、有効なプラクティスの一つは、自社のITガバナンスルール全体の一環として、オープンソースへの対処に直接取り組むことだ。例えば、次のようなことを定めるルールの設定を検討する。

• 開発者にオープンソースの利用を許可する方法を取り決める。開発者はオープンソースコードをミッションクリティカルな特定のコードベースに組み込むことができるかどうか、オープンソースツールの使用はスタンドアロンの形式に限定するかどうかといったことを定める
• コードベース内のオープンソースコンポーネントを特定し、それが最新状態に保たれているかどうかを確認するためにコードベースをスキャンする頻度の最低要件を定める
• 開発者は希望すればどのようなオープンソースコードでも利用できるのか、それとも特定のライセンスに規定されるコードしか利用できないのかを定める

　どのようなルールを定めるとしても、最も重要なのはそのオープンソースポリシーを自社全体に一貫して適用することだ。そうすれば、オープンソースコードを無計画に管理したり、場当たり的に管理したりすることがなくなる。