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

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

一般的に言って、セキュリティ企業から「脆弱性を無視する」という発言が出るとは、まず考えられません。何しろ脆弱性は、事後の論評や分析、推奨事項が何か月にもわたってフィードを埋め尽くすほど大規模な侵害を引き起こす原因となるからです。

そして、「脆弱性を無視する」という言葉が「セキュリティの向上」という考え方と結び付けられることも、まずありません。

これで目にすることになりました。ただし、たいていの助言と同様、これにも注意点や条件があります。

もちろん、すべての脆弱性を無視すべきではありません。しかし、現時点では無視しても問題がない、少なくとも後回しにできる脆弱性があることが分かりました。この考え方を知ったのは、2018年オープンソース脆弱性管理の現状（WhiteSource Software）を読んでいたときです。

このホワイトペーパーでは、非常に興味深い統計に加え、オープンソースの脆弱性を「影響しないもの」と「影響するもの」の2つに分類できるという考え方が示されています。

WhiteSourceの分類は、一部の脆弱性は「非有効」、つまりカスタムコードから呼び出されないため悪用できない、という前提に基づいています。この考え方によれば、脆弱性を分析して区別できれば、セキュリティ担当者と開発者は「有効」と判断された脆弱性に注力できるため、アプリケーション全体のセキュリティを向上させながら、時間と労力を削減できます。

たとえば、脆弱な関数を含むオープンソースコンポーネントに依存するカスタムアプリケーションについて考えてみましょう。White Sourceの定義では、この例の脆弱な関数はカスタムアプリケーションから一度も呼び出されないため、「無効」と判定される可能性があります。しかし、この脆弱な関数は、別のオープンソースコンポーネントまたは同じコンポーネント内の関数から呼び出される可能性があり、その場合は「有効」になることにお気付きでしょう。この可能性についてWhiteSourceに確認したところ、この点も考慮して分類しているとの補足説明がありました。脆弱なコードがカスタムコードから直接呼び出される場合、または別のオープンソースコンポーネントを介して間接的に呼び出される場合は、「有効」と分類されます。反対に、脆弱な関数を呼び出す経路が直接的にも間接的にも存在しない場合は、「無効」と分類されます。

WhiteSourceの調査では、開発者の96.8%がオープンソースコンポーネントを利用しているだけでなく、全プロジェクトの7.5%に脆弱性があることが判明しています。そのため、対応すべき脆弱性に優先順位を付けられれば、間違いなく大きなメリットとなります。さらにWhiteSourceは、オープンソース製品の実に64%で、含まれている脆弱性が「無効な脆弱性」のみであることを明らかにしており、これらは安全に無視できるとしています。

さて、脆弱性のあるコードが実際には呼び出されていないからといって、その脆弱性を安易に無視してよいとは思いません。しかし、この区別を脆弱性管理の優先順位付けに活用することには価値があります。実際に呼び出されている脆弱なコードに重点を置くことで、開発者やセキュリティ担当者はアプリケーション全体のセキュリティを直ちに向上させることができます。また、White Sourceのレポートによると、シニア開発者はジュニア開発者よりも脆弱性への対応に費やす時間が平均して長いため、シニア開発者をより有効に活用できます。

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

言うまでもなく、カスタムコードにもオープンソースコードにも、多くの脆弱性が存在します。脆弱性が「有効」か「無効」かに基づいて修正の優先順位を決めることは、ほかの要因に加えて、現実に存在する脅威に基づいてリスクを評価する新たなセキュリティ戦略に沿ったものです。無効な脆弱性が現実にもたらす脅威は、ほぼ存在しません。とはいえ、無効な脆弱性を無視することが、長期的に見て最善のアプローチとは限りません。そうした脆弱性が、いずれ有効になる可能性があるためです。機能の追加や強化に伴うカスタムコードの変更や、時間の経過に伴うオープンソースコンポーネントの変更によって、脆弱な関数を呼び出す経路が開かれることがあります。脆弱性に特化したソースコード分析を、理想的には継続的に、少なくとも最終ビルド時には実施すべき理由の1つがここにあります。

しかし、期限を守り、開発者の時間を効率的に活用するという観点では、「影響しない」脆弱性の優先順位を下げ、「影響する」脆弱性に直ちに対処できるようにすることが、現時点で開発者がセキュリティを向上させるための有効な方法の1つかもしれません。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事