セキュリティ業界は長年、脆弱性を「個別に修正すべき終わりのないキュー」として扱ってきました。しかしCISAが最近公表した調査は、まさにこの姿勢こそが攻撃者に有利に働き続けている原因だと指摘しています。同機関が示す解決策は、弱点のカテゴリーそのものを根本から排除することです。
米サイバーセキュリティ機関であるCISAは、「ソフトウェア開発の段階でこうした根本原因を減らすことにより、脅威アクターに狙われやすい脆弱性の発生を防ぐことができる」と述べています。
とはいえ、これは口で言うほど簡単ではありません。CISAは何年も前からソフトウェアベンダーに対し、開発ライフサイクルにSecure by Design(セキュア・バイ・デザイン)の原則を組み込むよう呼びかけてきましたが、正しい方向への歩みが遅すぎるベンダーがあまりにも多いのが実情です。
繰り返し使い回される、ごく少数の欠陥
2026年8月に公表された「CISA Vulnerability Review: Fiscal Years 2024 and 2025」は、憂慮すべき事実を明らかにしています。この期間に発生した侵害の大半は、国家が関与するゼロデイ攻撃や高度な攻撃手法によるものではなく、安全性を欠いた設計のソフトウェアに起因する、既知かつ公開された脆弱性をインターネット上でスキャンして見つけ出す日和見的な犯罪者によるものだったというのです。
この結果は、今年に入って公表されたVerizonの「2026 Data Breach Investigations Report」の内容とも一致しています。同報告書は、脆弱性の悪用が現在、攻撃者が標的ネットワークへの初期侵入を果たす最も一般的な手口になっていると指摘しています。
CISAのデータからも、同じ弱点が毎年繰り返し現れていることが分かります。公開されたCVEに付与されたCommon Weakness Enumeration(CWE)タグを分析した結果、インジェクションの欠陥、不適切な入力検証、メモリ安全性の失敗、パストラバーサル、アクセス制御の不備といった、本来なら回避できたはずのコーディングミスの一群が、実際の悪用事例の中で不釣り合いなほど大きな割合を占め続けていることが判明しました。
2025年にCISAのKEV(既知の悪用済み脆弱性)カタログに追加された脆弱性と、それに関連する弱点クラス(出典: CISA)
CISAのKnown Exploited Vulnerabilities(KEV)カタログでは、登録項目の41.5%が、MITREが「stubborn weaknesses(しぶとい弱点)」と呼ぶタイプ、すなわち2019年以降ほぼ毎年CWE Top 25にランクインし続けている欠陥タイプに該当します。
CISAはまた、MITREが2007年に発表した「unforgivable vulnerabilities(許されざる脆弱性)」に関する報告書にも言及しています。これは、十分に文書化されたミスに起因し、攻撃経路が明白で、悪用も容易な欠陥を指すものです。
この基準に照らせば、現在最もよく見られるCWEトップ10のうち3つは、20年前であれば「許されざる」ものと見なされていたはずだとCISAは指摘します。これらが今も生き残っているのは技術的に解決困難な問題だからではなく、組織文化とSecure by Designの導入における失敗が原因だとCISAは主張しています。
なぜ脆弱性クラスの根絶を目指すべきなのか
ごく少数の弱点クラスが、実に多くの個別の脆弱性を生み出しているためです。そのクラス自体に対処すれば、まだ発見されていないものも含め、多数のバグを一度に取り除くことができます。
防御側にひたすら迅速なパッチ適用を求め続けるのではなく、以下によって設計段階から安全な製品を構築する責任をソフトウェア開発者側が負うべきだ、とCISAは述べています。
- 設定と更新の自動化
- 顧客に対するセキュリティ成果への責任の保有
- 設計・開発のあらゆる段階へのセキュリティの組み込み
- 一般的な脆弱性クラスの根絶(および残る部分についてはロードマップの公表)
この調査報告の中でCISAは、メモリ安全性、不適切な入力検証、インジェクション、ファイル処理、アクセス制御といった繰り返し現れる弱点を、それぞれを解消するための対策と対応づけて示しています。同時に、悪用された脆弱性の多くは複数の弱点カテゴリーにまたがっているため、開発者は脅威アクターがまとめて悪用する傾向にある弱点の修正を優先すべきだとも警告しています。
CISAは、こうした転換を実現するのは決して容易ではないと認めています。同機関いわく、セキュリティを組み込むには「技術的な規律と経営層の理解が必要」です。
より根深い経済的な障壁も存在します。例えば、メモリ安全性の欠陥を根絶するには、大規模なC/C++コードベースをメモリセーフな言語で書き直す必要があることが多く、これは数年がかりで多額の費用を要する作業になり得ます。
また今回の調査報告は、何年にもわたる自主的なSecure by Design宣言がなぜ十分な成果を上げてこなかったのか、あるいは「セキュリティ成果への責任を負う」という、法的責任を示唆する表現に対してベンダー側がなぜ抵抗を示すのかについても、解決策を提示していません。
市場を味方につける
構造的な変化を促す手段の一つは、買い手側の手に委ねられています。CISAのSecure by Demandガイダンスは、購入者にセキュリティを契約条件に組み込むよう促しています。
購入者はベンダーに対し、これまでにどの脆弱性クラスを排除してきたか、機械可読なソフトウェア部品表(SBOM)を提供しているか、製品にはフィッシング耐性のある認証がデフォルトで備わっているか、セキュリティログが基本製品に含まれているかなど、確認すべき点は数多くあります。
CISAは、消費者や中小企業がサイバーセキュリティの負担を不釣り合いなほど背負い続けている現状を認めつつも、十分な数の購入者が同じ質問を投げかけ、製品にセキュリティを組み込む開発者に見返りを与えるようになれば、ベンダー側も対応を迫られるようになると期待を寄せています。
同機関は「ソフトウェアエコシステムの安全確保は共同の責任であり、ソフトウェア開発者とエンドユーザー組織の双方が重要な役割を担っている」と指摘し、AIを活用した脆弱性発見の急増や、攻撃者が悪用の全工程を自動化できるようになるといった今後予想される事態を踏まえ、提示されたガイドラインの実装をできるだけ早く始めるべきだと述べています。
翻訳元: https://www.helpnetsecurity.com/2026/09/01/cisa-on-eliminating-recurring-security-weaknesses/
