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

　1万4000件以上――。

　2017年に記録された脆弱性の数は、これほど膨大な数字になります。

　ソフトウェアサプライチェーン（※）やソフトウェアベンダー、IoT（モノのインターネット）におけるセキュリティを確保するため、メーカーはパッチを適用していない脆弱性を持つ製品を顧客に販売するというリスクを最小限に抑える必要があります。

　しかしながら、ほとんどのソフトウェア開発企業は、脆弱性リスクを最小限に抑えるためのプロセスを持たず、自動化を行っていないのが現状です。

文書化されていないコード

　この理由の1つに、ほとんどすべてのソフトウェアに使用されている大量のオープンソースコードと商用コードが文書化されていない、ということがあります。

　コードの開発元が自社のソフトウェアに組み込んでいるコードの半分以上が、オープンソースまたはサードパーティの商用ライセンスコンポーネントである場合が多いとされていますが、それらは事前に記録されたり管理されたりはしていません。

　実際のところ多くの場合、開発元が認識しているのは自社製品に組み込まれている、サードパーティコードの約4％にすぎないとの調査結果もあります。このため、既知の脆弱性を持つソフトウェアコンポーネントが、開発時に大量に使用されることになります。

　エンジニアリングチームに対しては、短期間で製品を発売しなければならないというプレッシャーは増すばかりです。また、高品質で簡単に再利用できるオープンソースコンポーネントが爆発的に増加していることによって、販売する製品の複雑性が高まり、ソフトウェアリリースを管理する既存の手順では対処できなくなっています。

　一般的なエンジニアリングチームでは、「求められたとしても自分たちが依存しているサードパーティコンポーネントの完全なリストを作成することはできない」ということがデータにより示されています。

　製品に使われるオープンソースのライセンスを完全に順守するために、「オープンソースコンポーネントのリストを作成しておくこと」が、製品チームに対して求められることはよくあります。

　しかし実際のところ、そのチームが正確かつ完全なリストを作成していることはほとんどありません。このことは、顧客や合併時の買収者、パートナーといった外部組織からリストを要求された時に、明らかになります。

　その場合は、企業ができるだけのことをするように求められますが、通常は25個のオープンソースコンポーネントあたり平均1個程度しか開示できません。

　このように記録ができない理由は、オープンソースコンプライアンスのプロセスが通常、手作業で行われ、また、任意のプロセスとして扱われているためです。得てして“企業買収や企業の大規模イベントのプロセスの間のみ”記録に対してきちんと取り組みますが、その時にはオープンソースライセンスを順守したり、長年見過ごされてきた、コードベース内で今にも問題が発生しそうになっている脆弱性のリスクを軽減したりするには、すでに手遅れだったりします。

　手作業での記録や、ワークフロースタイルのリクエストだけに頼る方法では、大きなアーキテクチャ上のごく一部の要素しかとらえることができません。または、熟練したチームメンバーが持ち込んだコンポーネントのみに偏ってしまいます。影響の大きい脆弱性がニュースで報道されたら、現場で使用されているすべてのコードベース（過去と現在に販売されているバージョンすべて）を集中的に調査し、影響を受けるコンポーネントをリアルタイムで検出する必要があります。

　また、開発チームとテストチームは通常作業を中止し、各ケースに限定して対応する必要性が発生してしまいます。

なぜ状況が把握されなくなってしまうのか？

　この課題に対する解決策は、スキャン実行をベースとしたプロセスを策定して実施し、開発および使用されている製品の一部として組み込まれるファイルやリソースに対して、自動的にテストすることです。“アプリケーションを開発し実行するためにどのサードパーティコンポーネントが実際に必要であるか”を完全に理解する唯一の方法は、それぞれのファイルと依存関係を確認することなのです。

　サードパーティコンポーネントは、さまざまな状況でアプリケーションに使用される可能性があります。コンポーネントが組み込まれる状況の最も新しいものの1つとして、MavenやNugetのようなリポジトリマネージャを介することがあります。

　これらのシステムは、開発者が使用したいサードパーティコンポーネントを指定するために作成した構成ファイルを読み込みます。

　その後のビルド時に、リポジトリマネージャはインターネット上から必要なコンポーネントとその依存するすべてをダウンロードします。ビルド時のこのアクションにより、実際のサードパーティコンポーネントがソースコード管理システムに保存されず、最終ビルドを見た際にのみ確認できる状況を作り出します。

　こうなると、チームはコンポーネントの存在やコンポーネントの中に存在しているサブコンポーネントを、完全に把握することができなくなってしまうのです。

　一般的なオープンソースコンポーネントは、平均して10のサブコンポーネントまたは依存関係を持っていますが、それらが最初にリクエストした人物に知られていることはあまりありません。

　さらに、チームは通常サードパーティコンポーネントのモノリシックのソースツリーを手作業で導入します。これらのツリーには明確な名前が付けられているかもしれませんが、より大きなソースツリー内に置かれると、特にアプリケーションの行数が増えるにつれて、それらはまったく目立たなくなります。

　そのコンポーネントが明確なライセンスに関する記述がなかったり、コンプライアンスを実行するチームから来たものでなかったりした場合、ソースコードフィンガープリント分析またはディープスキャン技術を使用しない限りは、それが検出不可能になります。

　また、記録されていないコンポーネントのもう1つの大きな原因として、パートナーやほかのチームから取得したコンパイル済みのバイナリがあります。これらのバイナリ・ファイル（実行可能またはリンク可能なライブラリであることが多い）は、readme.txtファイルやlicense.txtファイルといった、明確に目に見えるライセンスや所有権情報を含んでいません。

　1つのファイルに、数十個ものオープンソースや商用の依存関係が含まれている場合があります。そして、それらがコードベース内に入ってしまうと、明確な問題が検出されない限り更新されないことがよくあります。

　バイナリマテリアルはソースコードに比べて中身がより見えにくく、脆弱性が長年気づかれないまま存在することになります。暗号化ライブラリOpenSSLやlibpngのようなマルチメディア処理ライブラリといった非常に人気のあるコンポーネントは、これらのファイルの奥深くに存在していることがよくあります。それらのコンポーネントは長年使用されてきているため、周知の脆弱性を持つ旧バージョンがファイルの奥深くで見つかることもまれではないのです。

　記録されていないコードが検出される可能性のある場所としてはほかに、より大きなライブラリからコピーされたファイルやルーティンが挙げられます。これはライブラリ全体が必要でなく、一部の機能を追加するために必要な場合によく行われることです。

　コピーされたコードは自社開発のように見え、しかも元のライセンス通知や著作権なしにコピーされます。このようなファイル内のコードの脆弱性には、パッチ適用がなされません。これは、元のコンポーネントとの関連性が見えなくなっているためです。パッケージレベルの記録方法やスプレッドシートでは、これらのタイプのファイルを検出して把握することはできません。

注意すべき事項は？

　問題が発生した時に、それを検出し、記録し、修正するための手順を作成しておくために、サードパーティコードが自社製品に使用される可能性のある状況について知っておくことが大切です。

　販売しているコードベースを検証することで、実際の経験を得る前にポリシーが作成されることは非常によくあることです。

　明確なポリシーからスタートすることは重要ですが、どのようなポリシーであっても開発者の選択や開発される製品のタイプに基づく更新が必要である、と理解しておく必要があります。

　永遠に変更不要な完成されたポリシーはありません。製品に対する最初のスキャンが驚くような結果をもたらし、既存のポリシーの大幅な変更が必要になることも珍しくありません。

　例えば、商用コンポーネントによってもたらされた、問題の多いサードパーティへの依存関係に対処し修正するための方法や、以前は知られていなかったWebサービスへ送られているデータを扱う方法、そのフィールド内に長らく存在している脆弱性を扱う方法を定める新たなポリシーを定める必要が生じることがあります。

　企業をソフトウェアの脆弱性から保護するには、スキャンベースのコンポーネント管理戦略をうまく策定することが重要です。状況に対応して変更できるポリシーを策定し、そのポリシーを実行して、開発者に対し有効な修正戦略をトレーニングすれば、大量のサードパーティコンポーネントを、より安全に使用できるようになります。

　時がたつにつれ、さらに深い分析を行えるようになり、自社製品のセキュリティに影響を与え得る依存関係が次から次へと明らかになる場合があります。最近検出された影響の大きいソフトウェア脆弱性の例を見てもわかるように、企業は数日から数週間ではなく、数時間から数日の間に対応をとることを求められるようになっています。

　未知の領域を大きく減らしておけば、脅威や攻撃に対してより的確に対応することができます。

＊＊＊＊＊

　次回は、こうしたリスクに対応するために経営者が何をすべきなのか、ということを説明します。