Synopsysが調査、対象コードの78％にオープンソース由来の脆弱性あり：採用が広がるOSS、脆弱性を管理すべきだ

Synopsys（シノプシス）のBlack Duckグループによると、さまざまなソースコードが含むオープンソースソフトウェア（OSS）の比率が高まっているという。それに伴い、OSSに起因する脆弱（ぜいじゃく）性をも取り込んでしまっている場合が少なくない。

» 2018年06月28日 11時00分公開

[高橋睦美，＠IT]

　アプリケーションソフトウェアのソースコードが含むオープンソースソフトウェア（OSS）やオープンソースのコンポーネントの比率が、あらゆる業界で、ますます高まっており、イノベーションを促している。

　だが同時に、OSSに由来する脆弱（ぜいじゃく）性も多数取り込んでしまっており、適切な管理が必要だという。Synopsys（シノプシス）のBlack Duckグループは2018年6月19日、「2018 Open Source Security and Risk Analysis」レポートを発表し、こうした現状に注意を呼び掛けた。

Synopsys ソフトウェアインテグリティグループシニアテクノロジーエバンジェリストティム・マッケイ氏

　Open Source Security and Risk Analysisは、2017年11月にSynopsysに買収される以前からBlack Duck Softwareがまとめてきたレポートだ。今回の調査は、エンタープライズや金融、医療、製造、車載システムやIoT（Internet of Things）など幅広い業種にまたがり、世界約500の企業が使っている1100を超える商用コードの監査結果などを基にまとめられた。

　レポートによると、調査対象アプリケーションのうち96％で何らかのオープンソースのコンポーネントが見つかった。1つのアプリケーション当たり、オープンソースコンポーネントの数は、平均すると2017年の147個から今回の257個に増えた。コードベースで見るとオープンソースの割合は平均で57％に達し、自社開発コードよりも高い比率となった。

　比率が高いこと自体は、最新のテクノロジーを活用したイノベーションの実現という意味で歓迎すべきことだが課題もある、とSynopsys ソフトウェアインテグリティグループシニアテクノロジーエバンジェリストのティム・マッケイ氏は述べた。

　課題とは脆弱性の存在だ。調査対象となったコードの78％で、少なくとも1つ以上、オープンソースに由来する脆弱性が見つかり、平均すると1つのコードベースで64個の脆弱性が発見された。「Heartbleed」や「Poodle」といった、数年前に発見済みで、しかも注目度の高い脆弱性が含まれているコードベースは17％あった。

　2017年3月に発覚したApache Strutsの脆弱性も見つかった。Equifaxや国内の複数のWebサイトで発生した情報漏えい事件の原因となり、メディアでも度々報じられた脆弱性だ。監査対象のうち8％がApache Strutsを利用していたが、うち33％、つまり3つに1つのソースコードには、依然としてApache Strutsの脆弱性（CVE-2017-5638）が含まれているという。

監査対象のうち8％がApache Strutsを利用しており、うち33％に脆弱性が残っていた（左側の円グラフ）

　こうした状況に至った原因は幾つか挙げられる。マッケイ氏は、「クローズドソースの商用コードの場合、サポート窓口や担当者がおり、パッチやアップデートのリリース、サポート終了時期について利用者に通知したり、情報交換したりする仕組みがある。これに対しOSSの場合、能動的にコミュニティーに参加していないとコミュニケーションの手段がない」と指摘した。

　深刻な脆弱性が見つかった場合には、サポート外のバージョンであっても修正をリリースする場合がOSSにはある。これはOSSの良いところだが、せっかくの情報が伝わらないケースもあるという。

増える脆弱性に立ち向かうには

　仮想化やコンテナ、クラウドといった技術の普及に伴ってOSSの利用は拡大し、それに伴って見つかる脆弱性も増えている。2017年に報告されたオープンソースの脆弱性は4800件を超えており、「1日に十数件というペースで見つかる脆弱性を全てトラッキングすることは困難だ」（マッケイ氏）。ライブラリの依存関係や、ディストリビューションごと、バージョンごとの差異まで含めて対処を考えるとなると、作業はさらに大変になる。

2017年に報告されたオープンソースの脆弱性は4800件を超えた

　その上、いわゆるIT業界だけでなく、IoTや自動車、医療など多くの業界にOSSの採用が広がっている。無視できない割合で、そこにも脆弱なコンポーネントが含まれている。この場合、多段にわたるサプライチェーンにまたがって、どのようなコンポーネントを利用しており、セキュリティリスクやライセンス違反の恐れがないかを管理することが重要になる。

　マッケイ氏は、Linux FoundationのCore Infrastructure Initiative（CII）やCHAOSSプロジェクトのように、セキュリティ意識を高め、コードの品質を高めていこうとするコミュニティーの取り組みが成果を出しつつあることに触れた。

　だがそれだけでなくユーザー側でも、「自社で開発していないものも含め、どのアプリケーションにどのようなOSSやコンポーネントが含まれているかを管理し、どのような脆弱性が存在するのかを把握することが重要だ」（日本シノプシスソフトウェアインテグリティグループカントリーマネージャー阿部浩也氏）。

　自社のコードに存在しないコンポーネントの脆弱性で右往左往することは時間の無駄だ。逆に本当に深刻で、さらに攻撃コードが出回っている脆弱性なら、速やかな対処が必要だ。Apache Strutsの例のように、脆弱性情報が更改されてから数十時間のうちに実際に攻撃がやってくるケースもあるからだ。