2017年9月のEquifaxハッキングによる衝撃にもかかわらず、業界は製品の保護において依然として長い道のりを歩んでいます。特に注目すべき重要な領域は、現代のアプリケーションのコードベース全体の60～80%を占めるオープンソースコンポーネントです。脆弱なオープンソースコンポーネントを検出し、製品のセキュリティを確保する方法を見ていきましょう。

昨年9月、信用格付け会社Equifaxへのハッキング事件が報じられると、世界中の若者の多くがオープンソースの脆弱性という概念に突如として目覚めました。攻撃者はApache Struts2オープンソースコンポーネントの脆弱性を悪用し、約1億4,790万人の個人情報を盗み出しました。その大半はアメリカ人でした。

表面上、同社は自社の Web アプリケーションが脆弱なオープンソース コンポーネントを使用していることを認識しておらず、攻撃を防ぐために適切なタイミングでパッチを適用していなかった。

Heartbleed のようなハッキングは短期的には世間の注目を集めましたが、この攻撃で盗まれた情報の量と質の高さは、さらに大きな世間の注目を集めました。

これは組織にとって警鐘となり、たとえ自社で作成したものでなくても、ユーザーのデータ保護に使用されるコードを保護する責任がますます重くのしかかっていることを浮き彫りにしています。こうしたコードは多くの場合、オープンソースコンポーネントの形で提供され、無料トライアルで利用でき、製品を期日通りに市場に投入することを目指す開発者に広く採用されています。開発者はオープンソースコンポーネントが提供する便利な機能に頼っています。オープンソースコンポーネントがなければ、独自に開発しなければなりません。オープンソースコンポーネントの利用は増加傾向にあり、ガートナーは、私たちがよく知っているほとんどの製品のコードのうち80%がオープンソースコードで構成されていると推定しています。

しかし、これらの脆弱性にもかかわらず、オープンソースコンポーネントのセキュリティは依然として多くの企業で見過ごされています。脅威の規模や、実際に使用しているオープンソースコンポーネントの数さえも認識していないのです。

この注目度の低さの主な理由の 1 つは、これらの組織がオープンソースの脆弱性とは何か、それがどのように発見されるのか、そして組織自身と顧客をどのように保護すべきかについて無視していることにあるようです。

最も基本的な質問に戻ります。オープンソースの脆弱性とは何でしょうか?

オープンソースの脆弱性は、プロプライエタリ製品の脆弱性と似ています。これらの脆弱性は、ハッカーが悪用できるほど不適切に記述されているか、開発者が意図しない方法でハッカーが有害なアクションを実行できるようになっています。

場合によっては、オープンソースの脆弱性を悪用してサービス拒否 (DoS) 攻撃を開始し、サービスをオフラインにすることができますが、他のより深刻な脆弱性により、ハッカーがリモート アクセスを取得し、システムに侵入するための「鍵」を手に入れる可能性があります。

しかし、オープンソースコードとプロプライエタリコードの類似点はそれだけです。社内コードは、組織内の中央集権的なガイドラインに従って開発者グループによって作成されますが、オープンソースコードは、プロジェクトの作成、修正、保守を行うコミュニティメンバー間で高度に分散されています。

集中制御システムと分散システムは、しばしば「大聖堂」と「バザール」と呼ばれます。オープンソースコードには、ロジックを計画するための中央集権的な設計が欠如しており、新機能の追加や修正のための標準化されたシステムも存在しません。オープンソースコードは、異なる、しばしばより緩いルールセットに従うため、管理がより困難になっています。

組織にとって、この混沌とし​​た領域に踏み込むのは複雑で管理が困難ですが、ハッカーにとっては、オープンソースコードに対する集中管理の欠如は大きなメリットとなります。開発者は、GitHubなどのサイトにある多数のリポジトリからソースコードをスクレイピングするだけで、コンポーネントに既知の脆弱性がないか確認することができません。さらに悪いことに、自社のコードベースや製品に含まれるオープンソースソリューションを把握している人はほとんどいません。

したがって、Equifaxの事例で明らかになったように、同社は脆弱なコードに依存していることに気づいておらず、これらの脆弱性の存在も認識していなかったため、パッチ適用が不可能でした。コードを開発する多くの組織と同様に、Equifaxもアプリケーションのコードをテストするために何らかのツールを使用していたかもしれませんが、オープンソースコンポーネントを分析するために特別に構築されたツールを持っていなかったことは明らかです。

オープンソースコードの脆弱性はどのようにして発見されるのでしょうか？誰がこれらの脆弱性を探しているのでしょうか？

静的アプリケーションセキュリティテスト（SAST）や動的アプリケーションセキュリティテスト（DAST）などのセキュリティツールは、プロプライエタリコードとの連携に優れています。組織内でのコード記述ロジックに基づき、ホワイトリストなどの一連のルールを用いて、攻撃者に悪用される可能性のあるコードの潜在的な脆弱性を探します。

しかし、オープンソースコンポーネントはそれぞれ異なる方法で構築されているため、これらのツールは脆弱性の発見にはあまり役立ちません。代わりに、コード全体に潜む脆弱性を探すために時間を費やす、多数の研究者やコミュニティメンバーに頼る必要があります。彼らはコードに深く入り込み、綿密に調査し、プログラムが失敗する可能性のある様々な理論を試し、アプリケーションが自己防御できないようにするための攻撃コードを作成します。

コード内の容易に検出可能な脆弱性を見つけるために自動化ツールが活用されているものの、テストプロセスは長く困難な作業です。研究者はたった1つの脆弱性を見つけるのに平均3ヶ月かかると推定されています。

本質的に、オープンソースソフトウェアは、より良いプロジェクトを構築するために時間を捧げる開発者グループによって維持されている、生き生きとした存在です。プロジェクトをより堅牢にするために、多くのコミュニティメンバーが時間をかけて脆弱性を発見し、不満を持つ個人、犯罪者、場合によっては国家機関に悪用される可能性のあるコードを発見すると、プロジェクト管理者に警告を発します。このような研究者の多くは、オープンソースコードへの愛と敬意から、コードの安全性向上に貢献しています。

そして、（最も婉曲的な言い方をすれば）賞金稼ぎたちは、現金報酬のために脆弱性を探します。近年、ハッカーの更生を支援し、その悪徳スキルを善のために活用できるようにする小さな産業が台頭しています。マイクロソフトをはじめとする多くの大規模組織は、ホワイトハットハッカーが脆弱性を報告して報酬を受け取るためのバグバウンティプログラムを設立しています。

HackerOneとBugcrowdは、様々な企業や米国政府のためにバグ報奨金プログラムを運営する二大巨頭です。この機会を逃さないために、オープンソースコミュニティ内にもバグ報奨金制度があり、主要なステークホルダーからの支援を受けています。

2014年、Linux FoundationはHeartbleed脆弱性に対処するため、Core Infrastructure Initiativeを設立しました。Microsoft、Intel、Google、IBM、Amazon、VMwareをはじめとする多くの業界リーダーを巻き込み、300万ドルを超える報奨金を獲得しました。もう一つの有名なオープンソースイニシアチブは、非営利のInternet Bug Bounty（IBB）プログラムです。このプログラムはFacebook、Ford Foundation、そして最も重要なGitHubからそれぞれ10万ドルの支援を受け、研究者への報酬として提供されました。

オープンソースの脆弱性が露呈した後の対応

研究者が最終的にプロジェクトの脆弱性を発見すると、関係者全員に通知して一連のアクションを開始します。

研究者の最初のステップは、調査結果をMITRE（米国政府支援の非営利団体で、共通脆弱性識別子（CVE）レジストリを管理する組織）に提出することです。MITREのスタッフは脆弱性を分析し、その存在を確認し、情報を提供します。情報提供には通常、深刻度評価、脆弱性の悪用方法の詳細、そしてできれば修正パッチへのリンクが含まれます。この段階で、脆弱性にはIDが割り当てられます。IDには、報告された年と固有のID番号が含まれます。例えば、Equifaxへの攻撃に使用されたApache Struts2の脆弱性は、CVE-2017-5638として識別されます。

MITREが管理するCVEシステムの構成は、到底適切とは言えません。そのため、脆弱性情報はNational Vulnerability Database（NVD）に掲載されており、これは優れたディレクトリです。

同時に、研究者はオープンソースコンポーネントのプロジェクトマネージャーにも連絡を取り、問題について報告します。通常、公正な競争原則に基づき、研究者はプロジェクトマネージャーに対し、調査結果を公開する前に脆弱性の修正プログラムを見つけるための期間として約60～90日間を与えます。すべてが順調に進んだ場合、プロジェクトマネージャーは期限前に解決策を提案します。

CVEが公開されると、その情報は誰もが利用できるようになり、既知の脆弱性となります。これには、その情報を利用して自社のアプリケーションにパッチを適用する善良な人々だけでなく、情報を無料で入手し、パッチ適用が遅れている企業を攻撃する悪意のある人々も含まれます。

これが、既知の脆弱性がオープンソースコンポーネントにとって最大の脅威となる理由です。多数の脆弱性に関する詳細情報がNVDで無料で公開されている以上、ハッカーが自ら脆弱性を探すのに時間を無駄にする理由はありません。

オープンソースコンポーネントを保護する

ここでわかるように、オープンソース コードの場合、セキュリティ チームにとっての課題は、コード自体の脆弱性を見つけることではなく、既知の脆弱性が利用可能になったときに備えることです。

これらのオープンソース コンポーネントを安全に保つには、2 つの点に対処する必要があります。

最初に確認すべきことは、コードベースと製品で使用されているオープンソースコンポーネントに既存の脆弱性が含まれていないかどうかです。開発者が所有するコンポーネントとそのセキュリティ状況を追跡するためのツールを使用していない場合、Equifax社のような、重要な可視性情報が不足している状況に陥る可能性があります。

さらに、脆弱性のある「必須」コンポーネントの問題を修正することは可能ですが、開発者は新製品の開発において、既知の脆弱性を持つコンポーネントの使用を避けるべきです。つまり、オープンソースコンポーネントをコードベースや製品に追加する前に、脆弱なコンポーネントを検出できるソリューションを活用すること、さらには開発者がリスクの高いコードをコミットしようとした際にビルドが失敗しないようにする自動化戦略を活用することが重要です。

製品とその中に含まれるデータのセキュリティを確保することは顧客の期待となっており、ハッカーが攻撃を開始する前に、既知の脆弱性を持つコンポーネントを識別するための適切なツールの適用が求められています。

業界では多数のオープンソース コンポーネントが広く使用されているため、開発者とセキュリティ チームは、コードベースと製品で使用されるすべてのオープンソース コンポーネントを追跡する自動化ソリューションを導入するとともに、NVD などの脆弱性データベースを監視して、研究者が新しい脆弱性を発見したときにアラートを受信する必要があります。

WhiteSourceやFlexeraのようなソフトウェア・コンポジション分析（SCA）ツールは、この目的のために設計されており、アプリケーション・セキュリティ戦略に不可欠な要素です。これにより、ハッカーの先手を打つことができ、顧客の信頼を維持しながら製品のセキュリティを確保することができます。SCAツールを導入しないと、組織は攻撃に対して脆弱な状態に置かれます。正直なところ、誰も次のEquifaxになりたくありません。