オープンソースとサードパーティの使用状況に関する認識不足

　ソフトウェア業界は時とともに変化しており、わずか10年前に使用されていた管理方法やベストプラクティスの方法だけでは、ソフトウェア製品を新たな脅威から保護するのに、もはや十分ではなくなっています。

　これらの新たな脅威により、収益性の高い製品を市場から引き上げざるを得なくなったソフトウェアベンダーもあります。その脅威にさらされていたことすら認識していなかったソフトウェアの脆弱性が原因で、ハッキングされた結果です。

「書く」時代から「つなぎ合わせる」時代へ

　では、何が変わったのでしょうか？

　私たちの業界は、コードのほとんどが一から書かれていた時代から、「コードを書く」よりも「つなぎ合わせる」方が多く行われる時代へと進んできました。つなぎ合わされているのは、多種多様な目的と出どころを持つサードパーティコンポーネント（本稿では外部から入手したソフトウェアコンポーネント）です。サードパーティコンポーネントには、オープンソースコンポーネントと商用コンポーネント（ライブラリとも呼ばれる）が含まれています。

　サードパーティコンポーネントには、それらを適正に使用するために順守するべきルールや義務があります。これらのルールは、ソフトウェアライセンス条件と呼ばれています。これらのコンポーネント内でソフトウェア脆弱性が検出された場合、企業がそのコンポーネントをアップグレードしたり修正したりする作業をしていなければ、その企業は危機に陥る可能性があります。

　実際、オープンソースコンポーネントや商用コンポーネントのライセンス条件に伴うコンプライアンスリスクと、脆弱性によるセキュリティリスクはまん延しつつあり、ソフトウェアサプライチェーン（※）の完全性をも脅かしつつあるのです。

　多くの商用ソフトウェアパッケージでは、そのコードの半分以上がオープンソースコンポーネントで構成されています。また多数のソフトウェアエンジニアが、作業を迅速化するためにオープンソースソフトウェア（OSS）と商用のサードパーティコンポーネントを使用しています。

　しかしながら、使用しているコンポーネントを管理し、コードを使用するための法的義務や含まれている可能性のあるソフトウェア脆弱性リスクを把握しているソフトウェアエンジニアはほとんどいません。

巨大な「未知」

　さらに悪いことに、ほとんどのソフトウェア企業のリーダーはこのような状況が発生していることさえ認識していません。そして、リーダーがソフトウェアコンポーネントが使用されている実態を把握していなければ、それらのコンポーネントに関連するセキュリティやコンプライアンスのリスクに対処するための適切なプロセスを構築したり、自動化を実施することができません。

　企業リーダーは、最高技術責任者、セキュリティ担当者、エンジニアと話し合い、サードパーティコンポーネントに関連するコンプライアンスとセキュリティ運用の状態を把握しておく必要があります（詳細については、本連載の第2回を参照してください）。

　これは銀行・金融のような業界においては特に重要です。?うまでもなく、何億円、あるいは何千億円もの金銭を管理する職務を担うどの業界でも、新たな脅威に迅速に対処しなければなりません。

　前述したように、従来のソフトウェアは、そのソフトウェアアプリケーションを作成している会社に雇われている従業員が1行ずつ、1ファイルずつ作っていくものでした。場合によっては、少数のサードパーティコンポーネントが、通常は商業的な契約を介してその製品に組み込まれることもありましたが、どんなコードが書かれているか、何のライセンスを取得しているかは簡単に把握することができました。必要な書類やライセンスキーを管理する必要があったからです。

　しかし過去10年ほどの間に、ソフトウェア業界はこのモデルから大きく離れることになりました。大量のサードパーティソフトウェアコンポーネント、特にオープンソース由来のものを使用する方向へと大きく転換したのです。高品質で無料のソフトウェアコンポーネントを無数に入手できるようになったことで、アプリケーションの半分以上が、それを作成している企業に雇われていない人々によって書かれている、という状況になりました。

　この変化は、経営のベストプラクティスが追いつけていない速さで起こっています。ほとんどの企業が、法的な義務を果たすために何が必要かということについて十分な知識を持っていません。その上、企業で使用している何十万ものサードパーティコンポーネント（“ソフトウェアの部品表”とも呼ばれる）を把握するためのシステムがなければ、既知の脆弱性が自社製品に影響を与えるかどうかを知ることもできません。

　金融業界に最近重大な影響を及ぼした脆弱性に、OpenSSLとStruts2のオープンソースコンポーネントが対象となるものがありました。ほとんどの組織がこれらの脆弱性により、組織内のどこかが影響を受けるだろうとわかっていたにもかかわらず、手遅れになる前に、影響を受ける製品や場所を正確に突き止めることができませんでした。

今こそ、教育が必要

　ほかのセキュリティやコンプライアンスに関するタスクと同様に、これらの対処をやり遂げるために必要なビジネスプロセスに、単一のソリューションで対応することはできません。

　このソリューションの中核となるのは、教育プログラムによって、組織内のすべてのレベルの人員が、オープンソースとサードパーティのソフトウェアに求められる義務について理解できるようにすることです。

　最も基本的なレベルでは、ソフトウェア製品の作成と管理に携わる人のすべてがオープンソースライセンス、コンプライアンス義務、それらを管理するための組織のプロセスと要件がどのようなものかについて、大まかに理解している必要があります。

　ソフトウェアを導入、配布する場合に従わなければならない多くの義務（バージョン情報ボックスにクレジットを入れる、そのアプリケーション作成に使用されたソースコードを示すなど）があることが一般的です。しかし現在のデータによると、最も基本的なソフトウェアライセンス条件の観点からしても、ほとんどの組織がコンプライアンスを満たしていません。

　これらの義務を適切に管理するには、実際にその要件を順守するための時間を開発チームに与える必要があります。コンプライアンス確認のための手段や時間を割り当てていない企業には、コンプライアンスを期待することはできません。

　教育レベルやスケジュール内に確保されている時間にかかわらず、コードを作成するエンジニアだけでは結論を出せない質問もあります。

　その場合、一般にオープンソースレビューボード（OSRB）と呼ばれる委員会形式の仕組みを活用して、サポート要求を管理したり、サードパーティソフトウェアを適切に使用するためのポリシーを策定したりします。

　OSRBでは多くの場合オープンソースに加えて、商用、サードパーティのコンポーネントの管理も行います。OSRBは通常、法務、エンジニアリング、セキュリティ部門、その他の関連部署の代表者によって構成されます。さらにOSRBは、必要に応じてさまざまな人が集まる、ゆるやかに組織されたグループから、高度に構造化された専門チームに至るまで、さまざまなタイプが可能です。

ベストプラクティスと義務

　この件に関する知識を高め、学んだことを実行するために重要なのは、ベストプラクティスと義務が順守されていることを確認することです。

　それぞれのアプリケーションにその帰属とライセンスについての表示が適切になされていることを確認すること、また、その分野における脆弱性に後れをとらないようソフトウェアコンポーネントについては必ず、最新のパッチを適用したバージョンを使用することや、定期的に脆弱性を開示するOpenSSLといった有名なコンポーネントを管理することも、安全性を保つうえで重要です。

　また埋め込まれているコンポーネントや、それほど目につかないコンポーネントを検出することも重要です。このレベルの詳細な管理は、検出された新しいコンポーネントのすべてに関するリスクを排除することに役立ちます。

　顧客やベンダー、商用サプライヤとの間の契約に基づき、使用しているオープンソースの開示や脆弱性に対するパッチ適用スケジュールを提供する必要がある、と認識する企業が増加しつつあります。

　金融業界も、規制や証明書を順守する必要があることに認識しています。多くの場合、そのソフトウェアのコードを実際に書いたのは誰か、そしてそれがどのようにアセンブルされたのかについての正しく把握する必要があります。

　過去10年の間に、ソフトウェアサプライチェーンは非常に長くなっています。そのため、さまざまなことを記録したり迅速に修正したりすることが必ずしも可能ではなくなっています。

　しかし、このサプライチェーンから受け継いだ脆弱性やコンプライアンスに関する問題のすべてについて、ソフトウェア企業が責任を負うことになるかもしれません。つまり、その責任は最終的に組織のリーダーに降りかかってくるのです。

　開発コミュニティに対する教育を行い、サードパーティに対する依存関係を間違いなく検出し、それらの依存関係や可能性のある脆弱性を継続的に管理することで、製品のセキュリティとコンプライアンスに関する問題に先手を打って対応することができます。また単なるコスト削減にとどまらない、オープンソースの利点をより的確に活用することもできるようになります。このOSS開発モデルを理解すれば、新たなオープンソースパッケージを生み出したり、既存のパッケージを改良したりオープンソースの使用をより的確に管理したりすることができるようになります。

　経営幹部が注意を払わなければ、これらはどれ1つとして実現しないでしょう。経営幹部が時間を割いて先導すれば、開発者や顧客に大きなメリットがもたらされます。

＊＊＊＊＊
　本連載の最終回となる次回は、アプリケーションセキュリティの観点から、この問題をより細かく見ていきましょう。