2020 年 脆弱性管理レポート
2020 年も半ばを過ぎましたがみなさまいかがお過ごしでしょうか。
yamory は 2019 年 8 月 27 日にサービスをリリースし、まもなく 1 年が経とうとしています。
この 1 年を振り返ると、Go 言語のサポートやIPA のセキュリティ製品の有効性検証の試行において対象製品に選ばれたり、オートトリアージ機能の特許取得、イエラエセキュリティ様との業務提携など多くの取り組みを行なってきました。
最近では、Jira Cloud 連携やライブラリの依存関係のツリー形式での表示、シングルサインオン（SSO）連携機能もリリースしました。
機能拡充と並行し、私が所属するセキュリティチームでは、日々新たに発見されるさまざまな言語のフレームワークやライブラリの脆弱性の調査・分析に力を入れております。
今回は 2020 年脆弱性管理レポートと題して、yamory 利用者様からのアンケート結果を交えて最近の脆弱性管理について紹介します。
今回のアンケートでは、開発者・セキュリティ担当者が約半数ずつ、チーム規模も 10 人以下の比較的小規模なチームから 31 ~ 60 人ほどの大きなチームまで幅広い方々に回答頂きました。
今回のアンケート回答者の役割と所属されているチームの規模感
脆弱性管理で大変なこと
昨今、毎日のように新しい脆弱性の話題が世間を賑わせているため、自分たちのソフトウェアに影響はあるのではないかと心配になる声を多く耳にします。
修正バージョンが公開されていたが適用せず、古い Apache Struts を利用していたために情報漏えいが起こってしまった、というニュースを目にしたことがある方も多いかと思います。
このような事態が自分たちのソフトウェアにも起こらないようにするために脆弱性管理を行う必要があります。
脆弱性管理を行うためには、「自分たちが利用しているソフトウェアの管理」「脆弱性情報の収集」「脆弱性の影響調査」「アップデートによる影響調査」などを実施する必要がありますが、利用しているソフトウェアの量が多いとその管理は大変なものとなります。
アンケートの結果では脆弱性管理の中でも特に「脆弱性が自分たちのサービスに影響が出るかどうかの判断」を行うことが大変だと感じている方が最も多い結果となりました。
次に多かった回答としては「脆弱性情報の収集」「脆弱性対応（アップデートなど）に伴う影響の確認」が大変だと感じるという結果でした。
これら 3 つに関して掘り下げて説明したいと思います。
脆弱性管理において大変だと感じること
脆弱性情報の収集
脆弱性を管理し対応するためには、まず脆弱性の情報を収集する必要があります。
より早く正確に必要な情報を収集することができれば、ソフトウェアに影響するかどうかの判断や、インパクトの判断、対応優先順位の判断といった後に続く作業も迅速に行うことができるようになります。
しかし、利用しているソフトウェアが多い場合には、それぞれのセキュリティ情報を収集することすらハードルが高い場合もあるでしょう。
セキュリティニュースサイトを確認するだけでは抜け漏れがあったり、脆弱性情報の公開後時間が経ってからの対応となってしまうとリスクがあります。
このような現実がアンケートには反映されていると感じました。
また今回のアンケートでは、セキュリティ担当者よりも開発者の方が脆弱性情報の収集に苦労しているという結果が得られました。
メインとなる開発の業務に加えて、セキュリティに関する対応も追加で行うことや、情報を取捨選択することに苦労を感じているのかもしれません。
脆弱性が自分たちのサービスに影響が出るかどうかの判断
脆弱性の影響範囲を判断するには、その脆弱性がどのソフトウェアの、どのバージョンに影響を及ぼすのか調査する必要があります。
その際、影響モジュールなどの情報をより細かい粒度で調査することで、誤った判断を防ぐことができます。
たとえば、CVE-2018-1270 は Spring Framework の脆弱性ですが、より細かく調査すると Spring Framework の spring-messaging に脆弱性があることがわかります。
Spring Framework の該当バージョンを利用しているため影響があると判断してしまうと、本当は必要のない緊急アップデートの実施に繋がってしまうかもしれません。
CVE-2018-1270 の詳細。yamory の脆弱性詳細画面では CVE の詳細情報はもちろん、脆弱性によるリスクや対応方法を日本語でも確認できる
また、脆弱性の中には特定の環境下でしか影響が出ないケースもあります。
たとえば、先ほど例にあげた脆弱性は、STOMP というプロトコルを WebSocket 上で利用した場合に影響を受けるものです。
このように、影響が出るかどうかの判断するために大まかなソフトウェア名とバージョンだけを使った場合には、過剰な対応をしてしまうことがあります。
正確な判断をするためにも、細かい粒度で、影響を受ける条件まで調査する必要があります。
アンケートの結果からも収集した脆弱性情報が本当に自分たちの利用しているソフトウェアで、環境で影響するものなのか判断することが難しいという悩みが表れているのかしれません。
必要な情報を収集するためには手間と時間がかかりますが、正確な判断をすることで定期的なアップデートで対応することが可能となるため、結果的に全体の負担を下げることができます。
脆弱性対応（アップデートなど）に伴う影響の確認
アップデートなどの脆弱性対応によってはソフトウェアの挙動が変わる場合があるため、影響調査を行う必要があります。
影響調査の方法としてはアップデートによる変更点をリリースノートを通じて確認したり、動作テストを行う、カナリアリリースで影響確認をするなどが挙げられます。
脆弱性対応に限らず、ソフトウェアのアップデートに伴う影響有無ならびに影響範囲の調査は、ソフトウェアを使用しているシステムの規模が大きくなるほど時間がかかります。
また、システムの規模に比例して、テストエンジニアや開発エンジニア、インフラエンジニアなど、多くの人を巻き込むことになります。
そのため、上記で書いたように正しく脆弱性を把握し、計画されたアップデート作業など適切に対応するタイミングを見極め、突発的な影響調査の頻度を減らすことが組織の負担を軽減させることになるでしょう。
その他にもアンケート内ではセキュリティ担当者から「開発者、セキュリティ担当者間でのコミュニケーションが大変と感じる」という回答もありました。
セキュリティ担当者から開発者へ脆弱性をわかりやすく伝え、脆弱性が実際の環境でどう影響するか認識を合わせることは時間のかかることであり、容易ではありません。
また、コミュニケーションの手段やフローが定まっていない場合には、上記のようなコミュニケーションを設けるまでの調整に課題感を感じることがあると思います。
yamory では上記の負担の大きい「脆弱性情報の収集」「脆弱性が自分たちのサービスに影響が出るかどうかの判断」に加えて、「影響度の確認」「開発者、セキュリティエンジニア間でのコミュニケーション」をサポートできます。
また、脆弱性の情報も細かい粒度で収集・提供しているため、過剰な検知を抑止できます。
脆弱性管理の大変さに挙げられた項目のうち、 負担の大きな項目をyamory を用いることでカバーできる
脆弱性の公開を迅速に把握する
繰り返しとなりますが、適切な脆弱性管理のために脆弱性の情報を出来るだけ早く正確に収集することが大切です。
NVD の脆弱性情報を活用する上で気をつけたいことでも触れましたが脆弱性の情報収集に NVD の情報を活用することもあると思いますが NVD の情報だけに依存すると正確さに欠けることがあります。
また NVD の情報だけに依存すると正確さだけでなく、情報を得るスピードにも影響が出てきます。
たとえば、最近の RubyのRails の脆弱性 CVE-2020-8166 を例にあげると、NVD では 2020 年 7 月 2 日に公開されています。
しかし、Rails の公式ブログでは 2020 年 5 月 18 日に公開されています。
NVD と Rails の公式との公開日の差が約 1 ヶ月半程あり、NVD に依存した脆弱性収集では脆弱性対応が遅れてしまい、結果として世の中で既知となっている脆弱性のリスクに長い期間さらされることになります。
yamory では NVD の情報だけに依存せず、メジャーなライブラリのセキュリティ情報や NVD 以外の二次情報源の確認を行うことで正確で迅速な情報提供を行なっています。
CVE-2020-8166 における、公式サイトでの情報公開と NVD での情報公開のタイムラグ。
NVD に依存した脆弱性収集では脆弱性対応が遅れてしまう
脆弱性対応にかかる日数
脆弱性は存在する期間に比例して、攻撃されるリスクが高まります。
Edgescan 社が公開した 2019 年のレポートによると脆弱性が公開されてから修正するまでの平均日数は 69 日であり、冒頭で言及した情報漏洩事故の原因である Struts の脆弱性が 4 日で悪用されたことを踏まえると、攻撃者が俄然優位の状況にあると言えます。そのため、いち早く脆弱性を把握し必要な対策や備えを行うことはリスクを低減することに繋がります。
今回のアンケートでは、重要度の高い危険な脆弱性が検知されてから対応までに、半分以上の方が 2 週間以内に対応を完了させることがわかりました。
先に紹介したレポートの日数と比べ、今回の結果では対応が行われるまでの時間が短いことがわかりました。しかしながら、攻撃者が脆弱性を悪用するまでの時間と比べると、リスクがないわけではありません。
危険な脆弱性を検知してから脆弱性対応を完了するまでにかかる日数。
半数以上の方が 2 週間以内に対応を完了していることが伺える
では、なぜ対応に時間がかかるのか、アンケート結果からは時間がかかる要因として以下の 2 点が多く見られました。
- 脆弱性対応を行う人員などのリソースが足りない
- 対応フローが定まっていないなどによるスケジュール調整の手間
また、緊急度が高いもの、そうでないものを分けて対応し、緊急度が高くないものは定期的なリリースに合わせて対応するとの回答も得られました。
上記の結果から、脆弱性はいつ発見されるか予測できず、多くの脆弱性が突発的に公開されるため、その場での対応になりがちであるという傾向が複数の開発現場では存在することが見て取れます。
一方で、完璧な対応をすることも難しいため、事前に開発チームの責任者やインフラ担当者とコミュニケーションフローや対応手順を協議しておくことが望まれます。
今回、検知されてから対応されるまでの期間を回答していただきましたが、リスクにさらされる期間に関しては世の中に脆弱性が公開されてから検知されるまでの時間が上乗せされるので早く検知できればそれだけ早くリスクを下げることができますし、検知が遅ければ長期間リスクにさらされると言えます。
yamory では利用者様に影響を与える重要度の高い脆弱性を Slack やメールにて通知を行うことができます。これにより早い段階で脆弱性に気づくことができます。
推移的な依存関係にあるライブラリの脆弱性対応
開発時に、何か処理を行いたいためにライブラリを導入するということが多くあると思います。
自分たちが使っているライブラリを把握するために Excel などを使って導入したライブラリ名とバージョンを記載し、その一覧表を元に脆弱性の管理を行うというケースもあると思います。
しかし、多くのライブラリは他のライブラリを利用して構成されているため、自分たちが直接導入したライブラリが利用している、推移的な依存関係にあるライブラリ（推移的依存ライブラリ）が実は多くあります。
以前、「ライブラリの導入、それが脆弱性の始まり」の記事でもご紹介したように、たとえば JSON 形式でデータをやり取りできるライブラリが欲しいと思い fuel と fuel-jackson を導入した場合、fuel-jackson が利用している jackson-databind に脆弱性が存在しているということがあります。
「 I 5 」「 D 25 」という数字は危険度が高い（Immediate）脆弱性が 5 件、中程度（Delayed）の脆弱性が 25 件あるということを示しています。
Webアプリ内に fuel と fuel-jackson を導入した場合の依存関係ツリー。
jackson-databind に脆弱性が存在している
推移的依存ライブラリに脆弱性がある場合には手動での管理は現実的ではなく、抜け漏れが出てしまいます。
推移的依存ライブラリの脆弱性対応に関するアンケート結果では多くの利用者様が推移的依存ライブラリに関しても直接依存ライブラリと同様に脆弱性対応を行なっているということがわかりました。
推移的依存ライブラリの優先対応度について。
多くの利用者様が直接依存ライブラリと同様に脆弱性対応を行なっている
推移的依存ライブラリの脆弱性はアップデートすることが難しい場合もあるため対応が難しい側面もありますが、悪用されるリスクはもちろんゼロではありません。
yamory では、これらの推移的依存ライブラリまで検知することができ、その中に含まれている脆弱性も検知することができます。
また、ツリー構造で可視化することでどういった依存関係の中のライブラリに脆弱性があるのかをわかりやすく見ることができます。
CI を使ったセキュリティ対策
より開発サイクルの早い段階でセキュリティの対応をするシフトレフトや、開発の日常業務の一部としてセキュリティを組み込む DevSecOps を実現するためにも、CI にセキュリティツールを組み込むことは大切です。
たとえば、CI に yamory などのセキュリティツールを組み込み、問題があった場合にはビルドが失敗するといった設定を行うことで問題のあるものを混入することから防ぐことができます。
アンケート結果でもほぼすべての組織で yamory やその他のセキュリティツールを CI に組み込んでいることがわかり、開発中におけるセキュリティの確保が浸透していることが見て取れました。
CI にセキュリティツールを組み込んで利用しているかどうかの回答。
ほぼすべての組織で開発中におけるセキュリティの確保が浸透している
8 割以上の方が yamory を CI に組み込んで利用しており、全体の 3 割の方が yamory に加えて別のセキュリティツールを組み込んで利用しているとの回答が得られました。
OWASP Devsecops Maturity Model という DevSecOps の成熟度モデルの静的解析の項目では「既知のコンポーネントの脆弱性のテスト」が Level1 とされていることからも、yamory を DevSecOps を進める初めのステップとして導入することは良いと言えます。
また、危険な脆弱性への対応日数に関するアンケート結果の多くが 2 週間以内、1 ヶ月以内と比較的早く対応ができていたのも開発の早い段階で脆弱性を発見し、対応するという仕組みや文化が出来ていたことが関係しているのかもしれません。
さいごに
2020 年脆弱性管理レポートとして、利用者様からのアンケートをもとに最近の脆弱性管理について紹介しました。
今回は初回ということもあり過去の結果を踏まえた考察はできませんでしたが、来年度にも同様のアンケートを行うことで傾向分析を行えればと考えています。
脆弱性管理に関して多くの方が共通して日々の脆弱性情報の収集、自分たちのサービスへの影響確認、アップデートによる影響の確認が特に大変だと感じていることがわかりました。
脆弱性対応は脆弱性が公開されるという外的な要因で発生し、場合によっては迅速な対応が求められることがあります。
リスクにさらされる期間を短くするためにもできるだけ早く脆弱性の情報を入手し、加えて対応方法を判断するためにも正確な情報を得ることが大切です。
アンケートの回答にあったように人手が足りていない中で上記の対応を内部の人員だけで行うことは難しいと思われます。
yamory は、脆弱性情報の収集、自分たちのサービスへの影響確認などの多くの方が大変と感じている部分の一部を支援することができます。
また、NVD に加えて複数の情報源より脆弱性情報を集めることで、早く正確な情報の提供に努めています。
セキュアなソフトウェア開発のためにエンジニアの方々を少しでも支援できればと思います。
もし興味がございましたらぜひ無料トライアルをお試しください。
