オープンソース・ソフトウェアと脆弱性の関係:実際に攻撃可能なものは3%に過ぎない

Only 3% of Open Source Software Bugs Are Actually Attackable, Researchers Say

2022/06/25 DarkReading — ソフトウェア・サプライチェーンにおけるセキュリティ・リスクが高まる中、脆弱性管理の作業負荷が増大しているが、今日の Shiftleft レポートでは、現存の脆弱性のうち、実際に攻撃者が到達可能なものは約3%に過ぎないことが示されている。このデータは、アプリケーション・セキュリティ (appsec) の専門家と開発者たちが、攻撃可能な脆弱性の修正と軽減に注力すれば、チームの負担を劇的に軽減できることを示唆している。

ShiftLeft の最新の調査 2022 AppSec Progress Report では、アプリケーション・セキュリティ担当者と開発チームが、「実際に攻撃が可能な」脆弱性に焦点を当てることで、より効果的に脆弱性を選別できることが述べられている。このレポートでは、開発者は、深刻な評価を受けた脆弱性のある使用中のパッケージを調査する際に、攻撃可能性を考慮したことにより、偽陽性のライブラリ・アップグレード・チケットが 97%減少したと報告されている。

もし本当なら、これは多くの人にとって喜ばしいことだろう。脆弱性の管理は現状でも十分に困難だが、多くの製品に波及し、多大な影響をおよぼすサードパーティの複雑な脆弱性が加わることにより、さらにその作業負荷が増加している。したがって、管理のための効果的な優先順位付けが不可欠となっている。セキュリティや開発の担当者たちは、限られた時間内に、きわめて大量のアプリケーション脆弱性にアクセスする必要があるため、代替コントロールにより脆弱性を修正/緩和することを、重要なものとして認識する必要がある。

セキュリティ脆弱性における「攻撃可能性」とは

ShiftLeft の CEO である Manish Gupta は、脆弱性が攻撃可能か否かを判断するには、既知の脆弱性を持つオープンソースの依存関係の存在を確認し、それらが実際にどのように使用されているかを検証する必要があると述べている。

Gupta は、「これらの脆弱性を簡単に発見/報告できるツールが数多く存在しているが、その調査結果の多くにはノイズが含まれている。たとえば、それらのツールは、アプリに依存関係が存在しているのか、また、どのように使用されているのかという点について考慮していない」と指摘している。

攻撃の可能性を分析するという考え方は、CVE を含むパッケージがアプリケーションによりロードされているか/アプリケーションにり使用されているか/攻撃者の制御するパスにパッケージが存在するか/データフローを介して到達可能かなどの、追加の要因を評価することも含んでいる。つまり、オープンソースの脆弱性に対して、簡略化された脅威モデリング・アプローチを取ることで、非生産的な作業を大幅に削減することを目的としているのである。

各企業の CISO たちは、すでにこのような火消し作業には慣れっこになっている。Log4Shell や Spring4Shell のようなサプライチェーンの脆弱性が業界のバックチャネルで話題になると、彼らは招集され、これらの脆弱性が自社のアプリケーションへ与える影響を特定し、リスクを最小限に抑えるための修正/緩和の適用に、長い時間を費やさなければならない。

このレポートでは、脆弱性のある Log4J の依存関係の 96% が、攻撃されないことが指摘されている。

注目が高まるソフトウェアの依存関係

最近の開発スタックでは、オープンソースの依存関係 (直接/サードパーティの両方) が増加しつつある。

Gupta は、「一般的に、多数の依存関係を使用する主要なアプリケーションでは、月に何度も新しい CVE が発生する。組織で使用しているすべてのアプリケーションで、すべてのアップグレードに対応するのは容易でないことは想像に難くない」と述べている。

パッケージのアップデートは簡単かもしれないが、アップデートに関する開発作業は、重大なものになる。多くの場合、1つのライブラリのアップグレードが、セキュリティだけでなく、機能性や品質に関する一連の新しいテストを引き起こし、コードのリファクタリングを必要とする可能性がある。

Gupta は、「製品の品質に真剣に取り組む組織であれば、徹底的なテストをせず製品を出荷することはない。また、ライブラリのアップグレードは常に安全とは限らない。オープンソース・ライブラリの新バージョンが完全に下位互換性を持つ保証はない。そのため、ライブラリのアップグレードを行う前に、アプリの動作方法を変更しなければならないケースもある」と指摘している。

攻撃可能性判定は実現可能か

OWASP の創設者であり、長年にわたってアプリ・セキュリティを提唱してきた Mark Curphey によると、このような優先順位付けモデルを求めることは、決して新しいことではないようだ。しかし、何が危険か、何が攻撃可能かを、判断するための分析の手段を選ぶことは、今日のアプリケーション環境では、ShiftLeft が提案するものよりも複雑になり得るようだ。

彼は、「オープンソース・ライブラリにおける脆弱なメソッドの大部分に、攻撃者たちは到達が不可能なため、悪用されないというのは事実である。しかし、現在、オープンソース・ライブラリは、開発者のための様々なグッズの販売店のようになっている。我々は、最近の Log4J の事例から、利用者が少ない JNDI インターフェイスのような問題であっても、悪用される可能性は存在し、皆で問題に向き合わなければならないことを学んだ」と述べている。

Mark Curphey は、「最新の appsec スタートアップである Crash Override のリスニング・ツアーで、いまの CSO たちが抱える最大の appsec 問題は何かと尋ねたところ、ほぼ全員が優先順位付けだと答えた。優先順位付けがアプリケーション・セキュリティの、次の大きな問題になるかもしれない。しかし、今回のインタビューで分かったのは、この質問に答えることは非常に難しく、”特定のコードを使用しているか” よりも、複雑な問題であるということだった。一連の質問には、システムのユーザー数/マネー・フロー/公共性/処理するデータの種類/物理的な場所/適用される法律などが含まれる。他のシステムと、どのように接続されているか、どのような制御/監視/警告が行われているかなど、技術的なこと多く含まれていた」と述べている。

Sonatype の VP of Product Innovation である Stephen Magill は、「攻撃可能性や到達可能性を、優先順位付けのフィルタとして使用する際に、もう一つ問題が生じる。それは、攻撃者が到達可能なものを決定するために用いられる、基礎的な技術データを理解することだ」と述べている。

攻撃可能性の優先順位付けは、脆弱性の概要と同じくらい重要なものであるため、セキュリティ・チームが、どのように脆弱性データを入手しているかを調べる必要がある。

Magill は、「セキュリティ・チームが脆弱性データをどのように入手しているのか、また、依存関係がどのように追跡されているかも調査する必要がある。マニフェスト・ファイルで宣言された依存関係だけなのか、それともバイナリ/アーカイブ/JAR などの分析に対応しているのか。こうした、一連の問いかけが、優先順位付けされる調査結果の質を判断するのに役立つ」と述べている。

さらに Magill は、「オープンソース・プロジェクト内で偶発的に発見される通常のバグの乱立以上に、ソフトウェアのサプライチェーンには多くの脅威が存在することを、セキュリティ・リーダーは覚えておく必要がある。ソフトウェア・サプライチェーンにおける最大の脅威は、オープンソースに対する悪意のある意図的な攻撃であり、これは、攻撃可能性とは全く関係のない、我々が注目すべきもっと大きな問題である」と指摘している。

とても元気づけられる、とても良い記事だと思います。なんぜ、年間で2万件も出てくる脆弱性ですから、なんらかの絞り込みができないと、現実的に対応できないという問題があるのです。2022年3月の「CISA の脆弱性カタログ:悪用という現実に基づく素晴らしい出発点」も、同じ報告性を示唆する記事であり、とても興味深い内容となっています。CISA が Known Exploited Vulnerability Catalog を提供し始めたことで、この流れが加速され、脆弱性対応が前進するのではないかと期待しています。

%d bloggers like this: