06:00オープンソースの脆弱性リスクを防ぐために(全5回)1.スキャン!スキャン!スキャン!2.オープンソースソフトウェアの知識のないCEOがビジネスを危険にさらす3.オープンソースソフトウェアの脆弱性とライセンスを管理するための5つのステップ4.オープンソースとサードパーティの使用状況に関する認識不足5.オープンソース戦略のためのアプリケーションセキュリティ現在、多くの企業が新しいソフトウェアアプリケーションの開発に何十億ドルも費やしています。トップ企業にとって社内で開発したアプリケーションは、その競争優位性をさらに高めるものです。アプリケーションの開発では、アプリケーションの重要な機能を提供するため、多くの場合オープンソースソフトウェア(OSS)と自社開発コンポーネントが使用されます。Webベースの社外向けアプリケーションは、収益の大きなチャンスとなります。注意深い監視なしにサードパーティコンポーネント(本稿では外部から入手したソフトウェアコンポーネント)を使用すると、組織にリスクがもたらされるおそれがあります。GartnerやSymantecの調査によれば、ソフトウェア攻撃の90%近くがアプリケーション層に向けられています。このため最高セキュリティ責任者(CSO)は、ファイアウォールやWebベースの認証、侵入検知、ID管理システムに投資を行っています。これらのソリューションは、アプリケーションへのトラフィックを管理することで周辺部の安全を確保しているに過ぎません。これらのソリューションのどれひとつとして、アプリケーションコードを強化したり、脆弱性のある欠陥を管理したりすることでアプリケーションを内側から保護することに、重点を置いてはいません。サードパーティコンポーネント戦略のためのアプリケーションセキュリティには、プロセス、トレーニング、ツールの観点からの対応が必要です。セキュリティチームとエンジニアリングチームが、以下の重要な2点について協力する必要があります。1つは、使用されているオープンソースコンポーネントと自社開発のコンポーネントの正確なリストがエンジニアリングチームから提供されること。1つは、使用されているこれらのプロジェクトを既知の脆弱性と発表されている脆弱性を関連付けるシステムがセキュリティチームにより管理されることです。OSSアプリケーションに、なぜセキュリティが必要か?OSSがもたらす利点は明白です。OSSを使用すれば開発コストを下げ、開発期間を短縮し、アプリケーションの総所有コストを下げることができます(適切に管理、活用できていることが前提です)。オープンソースコンポーネントの範囲は多岐にわたっています。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は今すぐこれを検討すべきです。通信事業における事業・サービスの企画、導入に一貫して従事し、技術潮流や産業構造の変化をとらえた事業化の実績多数。経て2016年から現職。工学修士(光物性工学)。