OSSに依存するソフトウェアに潜む危機

2017年5月25日(木)Courtney Squires（米フレクセラ・ソフトウエアリージョナル・セールス＆アライアンス・ダイレクター）

リスト

OSSの暗号化ライブラリ「OpenSSL」に潜んでいた「HeartBleed（ハートブリード）」の脆弱性により、ソフトウェア業界をはじめ世界中の企業がパニックに陥ったことは、まだ記憶に新しいでしょう。ソフトウェア開発者は自身が使用しているOSSコンポーネントの知識が不足していたため、そこに脆弱性があるかどうかを把握できていませんでした。もちろん、そのソフトウェアを使用していた顧客も知りませんでした。OSSへの依存度が増す中で今後、どのような対策を採るべきでしょうか。

　最後は、コードベースの所有者が残りのソースファイルを確認し、より大きいオープンソース・パッケージのカット＆ペースト、リファクタリング、または再編成を見つけようとするケースです。このケースは、コードベースのみを見ていては、ほとんど不可能です。

　最新のBOMを作成した後に、既知の脆弱性のあるコンポーネントが使用されていないか確認すると、脆弱性のあるコンポーネントが複数見つかることがあります。特に最初のレビューサイクルで見つかります。これらの多くは簡単に悪用可能なものもあれば、簡単には利用されない脆弱性もあります。通常は、このような結果を分類します。修正する方法には、最新バージョンへのアップグレード、パッチ適用、アクセスのブロックなどがあります。場合によっては、コンポーネントや影響を受ける製品機能を外す必要もあるでしょう。

　ソフトウェアのサプライチェーンを通じて提供された規模の大きいコンポーネントのサブコンポーネントによって脆弱性がもたらされたことが明らかになる場合があります。運が良ければ、OSSや商用サプライヤーが、影響を受けるコンポーネントにパッチを適用しておりダウンロードできます。しかし、OSSの開発者や商用コンポーネントのサプライヤーが問題を認識していない、または問題が未だ修復されていないことが判明することも少なくありません。

脆弱性のライフサイクル管理はソフトウェア企業の責務

　脆弱性のライフサイクルを管理するには、OSSや商用コンポーネントの欠陥ログプロセスを深く知っていくことが重要です。新しいバージョンが提供されれば、現在のBOMを有効に保ち、このリストを既知の脆弱性と照合するプロセスを製品が開発され使用されている限り継続しなければなりません。これは、ユーザーコミュニティーが使用するすべてのバージョンで実施する必要があります。開発チームは最新バージョンに取り組んでいるかもしれませんが、かなり古いバージョンのソフトウェアを使用しているユーザーが大勢いるからです。

　こうしたプロセスを深く認識し実行しなければと、HeartBleedのような新しい脆弱性に迅速には対応できないでしょう。HeartBleedのような脆弱性を防ぐために、使用されているOSSコンポーネントを細かく調べ追跡し管理するためのプロセスと自動化を導入する必要があります。ソフトウェアのどこにOSSコンポーネントが使用され、それらのどこに脆弱性が存在し、だれが影響を受けるのかを正しく把握できるようになります。

　さらに脆弱性にパッチを適用するシステムと自動化を導入し、開発中のソフトウェアと利用中のソフトウェアが安全であることを確認しなければなりません。こうして初めて、不注意にサプライチェーンを侵害し、ユーザーを危険にさらす恐れがある、記録されていないOSSコンポーネントと脆弱性のリスクを最小限に抑えられるのです。こうした取り組みは、OSSに依存するソフトウェア業界の責務であり、利用企業にすれば、利用している商用ソフトウェアベンダーが、OSSを正確に管理しているかどうかを確認する必要があるでしょう。

著者プロフィール

Courtney Squires

Courtney Squires（スクワィヤーズ・コートニー）
米フレクセラリージョナル・セールス＆アライアンス・ダイレクター「日本と韓国」。1977 年オーストラリア生まれ。2000 年豪Adelaide 大学卒業と同時に豪Deakin 大学の国際関係学科に入学。国際政治と貿易を専攻し、国家間の政治的関係がビジネスにどのような影響を与えるかなど「国際ビジネス」に興味を持つ。2007年Master of International Relations 終了。2004年～2012年は日本の自動車メーカーを中心に、日本と豪州企業にて営業推進を担当し、マーケティングプロセスや海外調達、M&A、新規事業などを経験。