Coders Conquer Security: シェア＆ラーニングシリーズ - 既知の脆弱性を持つコンポーネントの利用

すべてのアプリケーションに共通するものとは何でしょうか？それはコンポーネント（依存関係やライブラリとも呼ばれます）です。世界中のコードのほとんどは、何らかの形で他のコードに依存しています。アプリケーションを作成したその瞬間から、すでに膨大な依存関係の中にいるのです！

すべてのアプリケーションはコンポーネントを利用しており、その大半は自作したものではありません。そのため、使用しているコンポーネントの脆弱性がそのままリスクとなる可能性があります。既知の脆弱性を持つコンポーネントを使用することの意味、その危険性、そして解決策について解説します。

既知の脆弱性を持つコンポーネントの使用について理解する

複雑なソフトウェアには必ず脆弱性が存在します。これは避けられない性質です。つまり、コンポーネントが100%安全であることはあり得ません。では、コンポーネントに脆弱性が見つかったとき、あなたはそれを把握できていますか？そして、対策はできていますか？

問題は、コンポーネントが寿命を過ぎて使用されたり、脆弱性が発見された後に放置されたりすることで発生します。ほとんどのコンポーネントやライブラリでは、脆弱性が公表されるのと同時、あるいはそれ以前にセキュリティパッチがリリースされます。したがって、コンポーネントの脆弱性が発見・公表されたら、可能な限り迅速にアップデートすることが極めて重要です。脆弱なソフトウェアを本番環境に残してはいけません。

コンポーネントの入手元はさまざまです。自社のカスタムコードと直接統合するサードパーティ製品を購入する場合もあります。これらのコンポーネントはコードの一部となり、同じ権限レベルで動作します。もう一つの入手元は、GitHubなどのサイトで公開されているオープンソースプロジェクトです。オープンソースは、すべてのライブラリが脆弱性について慎重に精査・監査されているわけではないため、危険を伴う可能性があります。

攻撃者はコンポーネントの脆弱性情報を悪用します。脆弱性は公開されるため、攻撃者はあなたと同じタイミングでその情報を入手します。また、攻撃者はあなたがどのコンポーネントを使用しているかを特定する手法も持っています。この情報が知られてしまえば、パッチが適用されていない場合、アプリケーションは攻撃の標的となります。

脆弱なコンポーネントがなぜ危険なのかを知る

既知の脆弱性を持つコンポーネントを使用することの危険性を示す証拠が必要なら、2017年に発生したEquifaxのデータ漏洩事件を見れば明らかです。

2017年7月、米国の信用調査機関であるEquifaxは、1億4700万人以上の個人情報が流出した大規模なデータ漏洩を発見しました。このデータ漏洩の規模と影響は前例のないものです。最近では、Equifaxのずさんなセキュリティ対策についても報じられています。

そのずさんな対策の一つがパッチ管理でした。Equifaxには適切なパッチ管理体制がなく、コンポーネントが長期間パッチ未適用のまま放置されていました。これが漏洩の直接的な原因となりました。

Equifaxのウェブサイトでは、Apache Strutsウェブフレームワークが使用されていました。攻撃者がネットワークに侵入する数ヶ月前、Strutsフレームワークに脆弱性（Apache Struts CVE-2017-5638）が発見されていました。しかし、Equifaxはこの脆弱性にパッチを適用しませんでした。攻撃者はこの脆弱性を悪用してEquifaxのネットワークに侵入し、そこから膨大な個人情報にアクセスしたのです。

多くのウェブサイトは、自社で開発したものではないウェブフレームワークを基盤としています。必要な機能をすべてゼロから構築するのはあまりに膨大な作業となるため、これは標準的な手法です。しかし、フレームワークに強く依存することは、脆弱性を抱えるリスクにもつながります。次のEquifaxにならないようにしましょう。

脆弱なコンポーネントから身を守る方法

脆弱なコンポーネントの使用を防ぐ特効薬はありません。しかし、脆弱なコンポーネントが悪用されてシステムが侵害されるリスクを軽減するためのポリシーや管理策は存在します。

アプリケーションの構築にどのコンポーネントのどのバージョンを使用しているかを把握する必要があります。OWASP Dependency Checkのような依存関係管理ツールは、使用している依存関係を把握するのに役立ちます。Dependency Checkは、使用しているコンポーネントに公開された脆弱性があるかどうかも教えてくれます。

パッチ管理手法も不可欠です。脆弱性が発見された際に、パッチをダウンロードし、テストを行い、本番環境へスムーズにリリースするためのシステムを構築しておきましょう。ソフトウェアに常にパッチを適用しておくことで、数ヶ月前の脆弱性を攻撃者に悪用される事態を防ぐことができます。

最後に、オープンソースやサードパーティ製コンポーネントの利用に関するポリシーを策定してください。開発者が煩雑な手続きを嫌うのはもっともですが、自社で作成していないコードには審査プロセスが不可欠です。過度に厳格である必要はありませんが、未知のコンポーネントが使用されるのを防ぐために必須です。少なくとも、使用しているコンポーネントのインベントリを常に最新の状態に保つようにしてください。

サードパーティ製コンポーネントのリスクを回避する

コンポーネントには脆弱性がつきものです。ビジネスアプリケーションでは、ベンダー製かオープンソースかを問わず、何らかのコンポーネントが使用されます。しかし、それによって組織が攻撃の脅威にさらされる必要はありません。

攻撃者が脆弱性を知るタイミングは、多くの場合、パッチが公開されるタイミングと同時です。そのため、自社のアプリケーションで何が使用されているかを把握しておくことが重要です。どのコンポーネントに脆弱性があるのかを理解し、常に最新のパッチを適用してください。

脆弱なコンポーネントを発見（そして撃退）する準備はできましたか？アリーナへ向かい、戦いに挑みましょう： [こちらから開始]