オープンソース戦略のためのアプリケーションセキュリティ

　現在、多くの企業が新しいソフトウェアアプリケーションの開発に何十億ドルも費やしています。トップ企業にとって社内で開発したアプリケーションは、その競争優位性をさらに高めるものです。

　アプリケーションの開発では、アプリケーションの重要な機能を提供するため、多くの場合オープンソースソフトウェア（OSS）と自社開発コンポーネントが使用されます。Webベースの社外向けアプリケーションは、収益の大きなチャンスとなります。

　しかし注意深い監視なしにサードパーティコンポーネント（本稿では外部から入手したソフトウェアコンポーネント）を使用すると、組織にリスクがもたらされるおそれがあります。GartnerやSymantecの調査によれば、ソフトウェア攻撃の90％近くがアプリケーション層に向けられています。

　このため最高セキュリティ責任者（CSO）は、ファイアウォールやWebベースの認証、侵入検知、ID管理システムに投資を行っています。しかしながらこれらのソリューションは、アプリケーションへのトラフィックを管理することで周辺部の安全を確保しているに過ぎません。これらのソリューションのどれひとつとして、アプリケーションコードを強化したり、脆弱性のある欠陥を管理したりすることでアプリケーションを内側から保護することに、重点を置いてはいません。

　サードパーティコンポーネント戦略のためのアプリケーションセキュリティには、プロセス、トレーニング、ツールの観点からの対応が必要です。またセキュリティチームとエンジニアリングチームが、以下の重要な2点について協力する必要があります。

　1つは、使用されているオープンソースコンポーネントと自社開発のコンポーネントの正確なリストがエンジニアリングチームから提供されること。もう1つは、使用されているこれらのプロジェクトを既知の脆弱性と発表されている脆弱性を関連付けるシステムがセキュリティチームにより管理されることです。

OSSアプリケーションに、なぜセキュリティが必要か？

　OSSがもたらす利点は明白です。OSSを使用すれば開発コストを下げ、開発期間を短縮し、アプリケーションの総所有コストを下げることができます（適切に管理、活用できていることが前提です）。

　オープンソースコンポーネントの範囲は多岐にわたっています。LinuxやOpen Office、Androidのように、外部から見えるメジャーなコンポーネントやアプリケーションもあれば、OpenSSLやzlibのように、広く使われているものの外部からあまり見えないコアインフラストラクチャコンポーネントもあります。そしてそれ以外にも、何百万ものオープンソースコンポーネントが存在しています。

　一般的なアプリケーションの構成は、過去にはいくつかのサードパーティコンポーネントのみで構成されていました。しかし現在では、何百のサードパーティコンポーネントに依存するものとなり、その大半がオープンソースプロジェクト由来のものです。

　オープンソースコンポーネントと従来の自社開発コンポーネントにはこのような違いがあるため、商業的にサポートされているOSSオペレーティングシステムやパッケージアプリケーションとは異なり、主なオープンソースプロジェクトの中で、商業的なサービスコミュニティでサポートされているものは、10件に1件程度に過ぎません。

　OSSコンポーネントを使用している開発組織は、パッチ、アップグレード、脆弱性評価などの商用サービス契約であれば通常含まれているタスクに関しては、かなり"独自の方法"で行っています。

　さらに世界中に散らばっている開発者たちは、コードを書く際にオープンソースやフリーウェア、パブリックドメイン、評価版（商用ソフトウェアのデモバージョン）等を使用することができます。

　この時、開発者たちは購買プロセスの通常のチェックポイントを通過することはありません。このような管理が行われないと、このサードパーティソフトウェアに対しては検知、監視、記録のいずれも行われない可能性が高くなります。

　その結果、IT企業が自社のコードベースの構成を把握していない、ということになります。

　フレクセラでは最近の調査から、過去5年間に作成されたアプリケーションは、コードの行数ベースで50％以上のオープンソースコードを含んでいることを把握しています。その50％のオープンソースコードの70％以上が文書化されておらず、エンジニアリングチームは把握していません。

　したがってオープンソースコードが文書化されないままになると、企業のアプリケーション内でのそのコードの存在が、企業にとって不可欠な無形資産のセキュリティを脅かすことになります。

アプリケーションセキュリティ戦略を策定する

　自社で安全なソフトウェアを開発できるプロセスを使用できるようにすることは、セキュリティ、開発、ITの各チームの責任です。この3つのチームは協力して、以下の方法で、オープンソースのためのアプリケーションセキュリティをセキュリティ戦略全体に組み込む必要があります。

　開発組織は、セキュリティに関する高度な専門知識を獲得し続け、安全なソフトウェアを作成するプロセスを構築し、強力なアプリケーションインフラストラクチャをサポートするソフトウェアを作成し、改良し、維持し、修正する際にそれらのプロセスを適用し、一貫して使用する必要があるのです。

　これに際し、アプリケーション開発チーム、セキュリティチーム、ITチームの3チームが協力することは極めて重要です。それぞれが孤立していてはどの役割にもメリットがありません。例えばアプリケーション開発において、品質保証とウイルス予防は互いに相いれないものではありません。

　開発チームが、セキュリティに対する責任は専門のセキュリティ要員のみが負うものと誤解していることがよくあります。多くの組織で開発プロセスは、機能要件を満たすことを目的として、アプリケーションの設計、構成、コード化、テストにのみ焦点を絞っています。現在の予算やリソースが限られている状況では、アプリケーションのコードの欠陥や脆弱性、アプリケーションをハッカーの攻撃にさらしてしまう状況を十分にテストすることができません。

　同様にセキュリティチームとITチームの任務は通常、外部からの攻撃に対する境界防御に集中しています。しかしセキュリティの専門家は、コード記述に通じていないことが多く、多くの場合保護しなければならない導入済みのアプリケーションに大きな影響を与える決断が開発中に下されていることを認識していません。

　開発、セキュリティ、ITのどのチームも単独ではアプリケーションのセキュリティ問題に十分に対応できないのに対して、ハッカーはコード作成方法やセキュリティ上の問題に精通しており、このギャップを突いた攻撃を行います。

　CSOはエンジニアリングマネージャに対して、開発、セキュリティ、ITの全チームが協力して、導入済みのアプリケーションのセキュリティを確保するよう措置する必要があります。

　チームのスタート地点として適切なのは、オープンソースプロジェクトのサイトやその他のソースに脆弱性アラートがないか監視することです。これは既存のOSSリストに基づき、社内での使用されているソフトウェアコンポーネントの部品表に照らしてアラートの関連性を見極め、必要な場合はバージョンやパッチのアップグレードに関する推奨を行います。

　その後アプリケーションセキュリティ戦略を策定し実行すれば、その組織は最高レベルのセキュリティを確保しながら、OSSを利用できることになります。

　現在では実際的な方法でアプリケーションのセキュリティを確保することに役立つ、OSS管理ツールが使用できます。CSOは今すぐこれを検討すべきです。