リスクマネジメント リスクマネジメント記事一覧へ

[戦うソフトウェア資産管理、無駄な資産を一刀両断!]

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

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

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

 HeartBleedの教訓をソフトウェアエンジニアは生かしているか−−。こう問うならば、その答えは明確に「No」です。

 今、オンラインニュースを読んでいると想像してください。新しい名前が付けられたOSS(オープンソースソフトウェア)コンポーネントの脆弱性に関する書き込みが次々と流れ出しました。最初は、ゆっくりと知れ渡り、その後は情報の信憑性や攻撃に利用されるのかについてのコメントやリツイート、そして質問が加速度的に増えていきます。

 さらに責任の追求や、コードレビュー、事後の検証が始まり、そのうち会社の上司や製品マネジャーから連絡が入り始めます。「このニュースは当社に、どんな影響があるのか」「会社としての対応やアクションプラン、ユーザーへの連絡状況はどうなっているのか」「この脆弱性が悪用され自社ユーザーへの攻撃に既に利用されているのか」などなどです。

 多くの企業では今も、OSSコンポーネントの利用状況をしっかりリストとして管理していません。ソフトウェア企業であっても、大半はHeartBleed以後もリスト作成は難しいままです。ある調査によれば、リストを作成しているソフトウェア企業でも、把握しているコンポーネントは利用している全コンポーネントの4 %にすぎませんでした。つまり、既知のコンポーネントが1つあれば、管理されていない未知のコンポーネントが 24 個もあり、それらが利用企業の元に配信されているということです。

ソフトウェアの部品表(BOM)が必要に

 10 年から20 年も前なら、ソフトウェア企業の技術担当副社長にとって、出荷内容の把握は簡単なことでした。キャビネットを開け、ライセンスを付与しているライブラリーの製品ボックスを確認できたからです。一部はデジタル的にダウンロードしたり、有名な本からコードを入手したりしていたかもしれませんが、自社製のソフトウェアが大半で、商用ライブラリーを少数だけ含むという開発モデルだったのです。

 そのモデルが、当初はゆっくり、そして一気に切り替わりました。少なくともソフトウェアの半分以上がOSSになり、それもソースツリーの出所が必ずしも明確でない、デジタル的に入手したコードを含む場合もあるという開発モデルです。

 「この最新の脆弱性は自社に影響があるか」という疑問に答えるには、ソフトウェアの依存関係の最新リスト、つまり部品表(BOM)が必要になります。疑問への簡単なチェック方法は、最新のBOMを作成できるかどうか、BOMを前回更新したのはいつかを確認することです。セルフテストによってBOMの不備や期限切れを簡単に確認できます。

 BOMの作成が開発者の自己報告のみであれば、正しい情報はわずか数%しかないと考えるのが妥当でしょう。コードベースのサンプリングを実行し、報告されているバージョン番号が最新かどうか、ライブラリー名や著作権文字列、ライセンス、 COPYINGファイルのクイック検索、そして第三者のものである可能性が高い拡張子を持ったファイル(例えば.JAR、.DLL など)を調べます。

 こうしたクイックレビューだけでも、これまで知らなかった多くのサードパーティー製ソフトウェアが見つかることでしょう。文字列「OpenSSL」を検索すれば、場合によっては、さらに驚くべきことが分かります。これまで知られていなかったOpenSSL のインスタンスが、OSSの中で複数使用されていたり、商用コンポーネントに組み込まれていることが明らかになるはずです。ソースとバイナリの両方で使用されていることが分かります。このようなことが明らかになるのは好ましいことではありませんが、ソフトウェア業界には似た状況にある企業が少なくありません。

影響を受ける可能性があるOSSコンポーネントを見つける

 公開されている脆弱性の影響を受ける可能性があるOSSコンポーネントは、次のようなステップで見つけられます。まず、トップレベルのコンポーネントの多くは、名前が付けられたファイルやディレクトリにあります。これらは可視性が高いため一般的に開示されていますが、それですべてではありません。

 次に見つけやすいコンポーネントは、トップレベルのサブコンポーネントです。この種のOSSの使用例が見つかるのは稀で、HeartBleedのように良く知られた脆弱性でも、見過ごされることがよくあります。このようなコンポーネントがコンパイルされ、より大きいパッケージにリンクされてしまうと、一般的な開発者が依存関係に関するリストを把握しようとしても、ほとんど見つかりません。

バックナンバー
戦うソフトウェア資産管理、無駄な資産を一刀両断!一覧へ
関連キーワード

IT資産管理 / Flexera / OSS

関連記事

トピックス

[Sponsored]

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

PAGE TOP