脆弱性を無視してセキュリティを向上させる

一般的に言えば、「脆弱性を無視する」という発言は、セキュリティ会社から聞かれるとは予想されないものです。 結局のところ、脆弱性は大規模な侵害の原因となり、事後解説、分析、推奨事項が数か月にわたってフィードに溢れることになります。

そして、「脆弱性を無視する」という概念が「セキュリティの向上」という概念と結び付けられることは絶対にありません。 

これで、ほとんどのアドバイスと同様に、注意事項や条件が付きます。

すべての脆弱性を無視すべきではありませんが、現時点では安全に無視できる、または少なくとも雨の日に備えて優先順位を下げられる脆弱性のクラスがあることがわかりました。 私は、WhiteSource Softwareの「2018 State of Open Source Vulnerability Management」を読んでいるときに、この概念に偶然出会いました。

この論文では、非常に興味深い統計に加えて、オープンソースの脆弱性は、無効と有効の 2 つのカテゴリに分類できるという考えを提示しています。

WhiteSource の分類の前提は、一部の脆弱性は効果がない、つまりカスタム コードによって呼び出されないため悪用できないというものです。 分析と差別化が可能ということは、セキュリティ担当者と開発者が効果的とみなされる脆弱性に集中できるため、時間と労力を削減しながらアプリケーションの全体的なセキュリティを向上できることを意味します。  

たとえば、脆弱な機能を含むオープンソース コンポーネントに依存するカスタム アプリケーションを考えてみましょう。 White Source の定義によれば、この例の脆弱な関数はカスタム アプリケーションによって呼び出されることがないため、「無効」と宣言される可能性があります。 賢明な読者は、脆弱な関数がオープンソース コンポーネント (別のコンポーネントまたは同じコンポーネント) 内の関数によって呼び出され、有効になる可能性があることに気付くでしょう。 この可能性について WhiteSource に問い合わせたところ、同社はこの可能性を考慮していることを指摘し、分類を拡張しました。 脆弱なコードがカスタム コードから呼び出されるか、別のオープン ソース コンポーネントを介して間接的に呼び出される場合は、「有効」というラベルが付けられます。 逆に、脆弱な機能を呼び出すパス（直接的または間接的）がない場合、その機能は「無効」と分類されます。  

WhiteSource の調査では、開発者の 96.8% がオープンソース コンポーネントに依存しているだけでなく、すべてのプロジェクトの 7.5% が脆弱であることが判明しているため、どの脆弱性に重点を置くかを優先順位付けできることは間違いなく有益です。 WhiteSource はさらに、オープンソース製品の 64% に、影響のない脆弱性しか含まれていないことが判明し、無視しても問題ないと判断しました。

さて、私は、積極的に呼び出されていないという理由で、あらゆるコードの脆弱性を軽々しく無視すべきだとは思いませんが、脆弱性管理の優先順位付けにこのような区別を使用することには価値があると考えています。 積極的に呼び出される脆弱なコードに焦点を当てることで、開発者とセキュリティ専門家はアプリケーションの全体的なセキュリティをすぐに向上させることができます。 これにより、上級開発者をより有効に活用できます。White Source のレポートによると、上級開発者は平均して、初級開発者よりも脆弱性の解決に多くの時間を費やしています。

何らかの優先順位付けの方法を導入する必要があります。 WhiteSource は、2017 年に報告された脆弱性は 3,500 件近くあり、2016 年より 60% 増加したと述べています。 報告された 3,500 件の脆弱性のすべてがすべてのアプリケーションや組織に影響を及ぼすわけではありませんが、これらの数字は増加傾向にあることを忘れてはなりません。 つまり、3500 は累積合計に追加された新しい脆弱性です。

言うまでもなく、カスタム コードとオープン ソース コードには多くの脆弱性が存在します。 修復が「効果的」か「効果的でない」かに基づいて優先順位を決定できることは、他の要因に加えて実存的脅威に基づいてリスクを評価する新しいセキュリティ戦略と一致しています。 効果のない脆弱性の存在に対する脅威は、ほとんど存在しません。 とはいえ、効果のない脆弱性を無視することは、長期的には最善のアプローチではないかもしれません。 最終的には、このような脆弱性が有効になる可能性があります。 機能が追加または強化される際にカスタム コードが変更されたり、オープンソース コンポーネントが時間の経過とともに変更されたりすると、脆弱な関数を呼び出すパスが開かれる可能性があります。 これが、脆弱性に特化したソース コード分析を、最善の場合は継続的に、最悪の場合は最終ビルド時に実行する必要がある理由の 1 つです。

しかし、期限を守り、開発者の時間を効率的に使用するという観点から、「効果のない」脆弱性をキューの後ろに押しやり、「効果のある」脆弱性をすぐに修正できるようにするのは、開発者が今すぐにセキュリティを改善できるより良い方法の 1 つかもしれません。