使用しているものすべてを管理するとなるとうんざりするかもしれません。チーフ・インベントリ・オフィサーという肩書があったとしても、それは華やかでもなければ、権力や富とも縁がなさそうです。なにやら何日も倉庫で過ごすといった苦役の香りが漂います。でも実際のところ、華やかな仕事に劣らず重要なのです。もっと重要と言ってもいいかもしれません。
特にIT（情報テクノロジー）においては、アプリケーションの構築やネットワーク/システムの実行に使用するソフトウェアコンポーネントについて、このことが言えます。管理に失敗すると、大惨事につながる問題を招きかねません。
コンポーネントがオープンソース・ソフトウェアの場合は特に注意が必要です。
オープンソースがプロプライエタリソフトウェアより劣るとか、リスクが大きいという意味ではありません。オープンソースの方が優れている面も多々あります。オープンソースはますます広く利用されるようになっており、それには無料であること、アプリケーション開発者の必要に応じて自由に変更できることなど、相応の理由があります。オープンソースはいわば調節可能な建築ブロックです。シノプシスのサイバーセキュリティ・ストラテジスト、Tim Mackeyによると「オープンソースはイノベーションの原動力」です。
ですから、今週発表されたシノプシスの最新のオープンソース・セキュリティ＆リスク分析（OSSRA）レポートでオープンソースがコードベースの主要な要素になったという結果が出ていることは驚くにあたりません。この結果は17業種の1,200以上のアプリケーションの監査に基づいています。
オープンソースの監査が必要な理由
その1つの指標として、コードベース内に含まれるオープンソース・コンポーネントの平均数は2018年には298でした。この値は2017年の257から16%アップしています。
もう一つの指標として、多くの業種（OSSRAの報告では24業種）が、構築するアプリケーションの大部分（58～78%）にオープンソース・コンポーネントを使用しています。該当業種は、エンタープライズソフトウェア、バーチャルリアリティ、ゲーミング、エンターテイメント、メディア、インターネット/ソフトウェア・インフラストラクチャ、小売/eコマース、IoT（Internet of Things）、金融サービス、ビッグデータ/機械学習、エネルギー、サイバーセキュリティ、マーケティング技術など、多岐にわたります。
これらのすべての業種において、オープンソース・ソフトウェアを利用しなければビジネスチャンスはほとんどゼロに近いといえます。ご使用の環境では、おそらく既に手動では管理しきれないほど多くのオープンソースが使用されています。
オープンソースは料金がゼロであるからといってリスクもゼロというわけではないので、オープンソースを管理することが不可欠です。特に、大きく分けてセキュリティ面と法律面の2つの課題があります。
パッチ適用手順の違い
オープンソース・コードのセキュリティ面の安全性は専有コードの場合と変わりません。必ずパッチの適用が必要な脆弱性が存在します。
パッチを適用しなければ、膨大な時間を犠牲にする可能性があります。使用しているオープンソース・コンポーネントが不明なためにアプリケーションやネットワークが侵害された場合、IPの盗難、顧客のPII（個人識別情報）の盗難、ランサムウェア攻撃、信用失墜、法的責任、コンプライアンス違反による罰金など、続々と惨事に見舞われる可能性があることが現在ではよく知られています。
また、オープンソースのパッチの適用は、ユーザー環境に自動的にパッチを「プッシュ」する商用ソフトウェアの「自動更新」の有効化ほど単純ではありません。オープンソースにもパッチはありますが、ユーザーが自己責任で管理し、リポジトリから「プル」してインストールしなければなりません。
これを怠ると、Equifaxの二の舞になりかねません。2017年7月29日、巨大消費者信用情報会社 Equifaxで、データ侵害により1億4,700万人以上の顧客の社会保障番号などの個人情報が漏洩したことが発覚しました。その理由は、広く利用されているオープンソースWebアプリケーションフレームワーク、Apache Strutsのパッチを適用していなかったためです。そのパッチは数か月前から提供されていたものでした。
脆弱性は低減しても根絶はされない
オープンソースの脆弱性には勇気づけられる傾向も見られます。OSSRAレポート向けに2018年に監査を受けたアプリケーションのうち脆弱性が見られるものは60%でした。2017年の78%からは大幅に減少しています。
ただし、そのうち43%は10年以上前から存在する脆弱性です。しかも事態は容易に悪化する可能性があります。National Vulnerability Database（NVD：脆弱性情報データベース）は2018年に16,500件以上の新しい脆弱性をリストアップしましたが、そのうち7,393件はオープンソースの製品で発見されたものです。
そのため、インベントリが重要になります。ソフトウェアの専門家によって10年以上前から指摘されていることですが、使用していることを知らなければパッチを適用することはできません。
ライセンス無視によるトラブルを防ぐ
もう一つのリスクは法的なものです。オープンソース・コードは無料ですが、ライセンス要件があり、これを無視するとトラブルになる可能性があります。
しかも存在するライセンスの数は膨大です。OSSRAレポートでは、使用されているオープンソースの約98%が最も一般的な20のライセンスでカバーされていることがわかっていますが、Black Duck KnowledgeBase™には2,500以上のオープンソース・ライセンスが含まれています。
「多くのライセンスは寛容で、遵守することはそれほど難しくありません」シノプシスのプロフェッショナル・サービス部門シニア・ディレクター、Phil Odenceはこう語ります。「ただし、いかに友好的なオープンソース・ライセンスに対しても義務があり、少なくとも著作権者への帰属を示す必要があります。ライセンスを遵守するためには、義務が生じるのはどのライセンスかを知っておくこと、したがってコードベースに存在するオープンソース・コンポーネントの内容を把握しておくことが必要です。
「ライセンスが問題になる場合もあります。ライセンスに違反する方法でソフトウェアを利用すると、ライセンスのコンフリクトが生じます。極端な場合には、ソフトウェアの使用権を喪失したり、会社が訴えられることもあります。」とOdenceは語ります。
「ライセンスがない」ことは「責任がない」ことを意味しない
オープンソース・コンポーネントに明確なライセンス条件がなかったとしても、依然として訴えられる危険を免れる術はありません。ライセンス条件が明示されていない場合でも、ソースコードの使用、変更、共有はできない可能性があります。これは、創造的な作品（コードを含む）ははじめから独占的な著作権の下にあるためです。ライセンスとは、基本的に使用許諾のことです。ライセンスがなければ許諾もされません。
ここでも勇気づけられる傾向が見られます。OSSRAによると、2018年には監査対象となった業種のほとんどでライセンスのコンフリクトが減少したことがわかりました。それでもまだ52%～79%と十二分にリスクにさらされているといえる範疇にあります。
「全体的にはコードベースの68%にライセンス・コンフリクトがありました。」Odenceはこう語ります。「また、61%がGPL [General Public License]ファミリに関連していました。これにより前述の点で問題が生じやすくなります。」
したがって、やはりインベントリが重要になります。
オープンソースを管理するためにツールボックスでSCAを維持する
オープンソース・コード・コンポーネントを手動で管理できないとすれば、どうしたらよいでしょうか。
そのためのアプリケーションはありませんが、必要な作業を自動化するツールがあります。
ソフトウェア・コンポジション解析（SCA）は、コードベース内のオープンソース・コンポーネントを検出すると共に、使用しているバージョン、コンポーネントの既知のセキュリティ脆弱性も報告します。
また、SCAは対象コンポーネントに関連するライセンス・コンプライアンス要件も報告します。
これらの報告は、アプリケーションの開発中に、ソフトウェア・ライフサイクル（SDLC）全体にわたって行われます。
ソフトウェアを完全無欠にする術はありませんが、SCAツールを利用することにより、セキュリティや法律上の問題への対処に追われることなく、事業の発展に時間を活用できる程度にまでリスクを低減することが可能です。
オープンソースを使用する場合はSCAが欠かせません。
Continue Reading
2024 OSSRA レポート：オープンソース・コンポーネントの古いコードのリスク
Apr 17, 2024 / 1 min read
