2025年4Q KEVカタログ掲載CVEの統計と分析

Share
2025年4Q KEVカタログ掲載CVEの統計と分析アイキャッチ画像

米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)から公開されている「KEVカタログ(Known Exploited Vulnerabilities)」は、実際に攻撃に悪用された脆弱性の権威あるリストとして、組織のセキュリティ対策の優先順位付けに不可欠なツールとなっています。本記事では、KEVカタログに2025年10月1日~12月29日に登録・公開された脆弱性の傾向を整理・分析します。

本記事は2025年1Q:第1四半期~3Q:第3四半期の分析レポートに続く記事となります。過去記事もぜひあわせてご覧ください。
2025年1Q KEVカタログ掲載CVEの統計と分析
2025年2Q KEVカタログ掲載CVEの統計と分析
2025年3Q KEVカタログ掲載CVEの統計と分析

はじめに

2025年第四四半期(10月~12月)における既知の悪用された脆弱性の統計分析レポートです。本記事は最新のデータから見える傾向を解説します。前回までの分析ではMicrosoftやCisco製品への攻撃の多さや古い脆弱性が依然悪用されている実態が明らかとなりました。今回は第四四半期のデータを掘り下げ、攻撃トレンドの変化やリスクの深刻度を検証します。経営層に有用な全体像の把握と、技術担当者向けの詳細な分析を両立させ、組織が取るべき対策についても提言します。

2025年4Qの統計データ概要

2025年第四四半期に新たにKEVに追加・公開された脆弱性は62件でした。第三四半期(51件)から増加に転じ、2025年1月~12月29日時点で245件(2024年累計186件から約30%増)となっています。まずは月別推移や脆弱性の種類・深刻度について、データの全体像を俯瞰し、特にランサムウェア関連の脆弱性や影響度の大きい脆弱性、自動化攻撃が可能な脆弱性に着目します。

登録件数の月別推移

10月に追加件数が31件と突出し、11月は11件、12月は20件となりました(図1参照)。月ごとのばらつきが大きく、10月に集中して脆弱性が公表・追加されたことが分かります。これは各メーカーの定例アップデート直後に既知悪用事例が判明したケースが多いためと考えられ、特定の月に攻撃が急増する傾向が引き続き見られます。4Q全体では3Qからの増加により、年末にかけて脅威が再び活発化したことを示唆します。

2025年4Q 月別KEV登録件数の推移グラフ
図1:2025年4Q 月別KEV登録件数の推移グラフ

主要ベンダー別の内訳

4Qに新規追加された脆弱性のベンダーを見ると、Microsoftが10件と突出して最多でした。次いでOracle、Fortinet、Gladinetが各3件、Google、Samsung、Kentico、Android、OpenPLC、Dassault Systèmes、WatchGuardなどが各2件で続きます。3Qで多かったCiscoは1件に留まり、Microsoft製品への攻撃集中が際立つ結果です。一方、新たにGladinet(クラウドストレージ)やOpenPLC(産業制御システム)といったベンダーの脆弱性が複数追加されており、攻撃対象の幅が広がっていることが分かります。これは企業向けソフトウェアから家庭用/産業用機器まで攻撃者の関心が及んでいることを示し、ITインフラ全体で対策が必要です。

脆弱性タイプ(CWE)の分布

CWE脆弱性タイ
CWE-7875範囲外の書き込み
CWE-784OSコマンドインジェクション
CWE-8623認可の欠如
CWE-2843不適切なアクセス制御
CWE-202不適切な入力検証
CWE-4162解放済みメモリの使用
CWE-4342危険なタイプのファイルのアップロード許可
CWE-222パストラバーサル
CWE-792クロスサイトスクリプティング (XSS)
CWE-3062重要な機能の使用に対する認証の欠如
2025年4Q CWE分布表

悪用された脆弱性の種類としては、範囲外の書き込み(CWE-787)が5件で最多となりました。次いでOSコマンドインジェクション(CWE-78)が4件で続きます。認証・認可に関わる欠陥(CWE-862, CWE-284, CWE-306)も合計8件と多く、アクセス制御の不備が依然として攻撃者に悪用されやすいことが分かります。また、メモリ管理上の欠陥である解放済みメモリの使用(CWE-416)や範囲外の書き込み(CWE-787)など、低レベルのプログラムバグも上位を占めており、メモリ安全性の欠陥が攻撃に利用されるケースが増えています。

過去頻出したパストラバーサル(CWE-22)も複数含まれており、データから見ると、入力検証検証の不備を突いた攻撃(インジェクション系)、認証・認可の不備、そしてメモリ安全性の欠如という3つの古典的な脆弱性カテゴリーが依然悪用の中心であることが読み取れます。

攻撃の自動化容易性(Automatable)

4Qに登録された脆弱性のうち、約48%(30件)は自動化攻撃が容易である「Yes」と分類されました。これは自動スキャンやマルウェアボットによる大規模攻撃に適した脆弱性が増えたことを意味します。残る52%(32件)は「No」(手動操作や特定条件が必要)ですが、スクリプトキディでも悪用できる脆弱性が半数近くを占める状況は深刻です。(2025年年間累計は図3参照)攻撃者は脆弱性を迅速にスキャン・悪用する自動化ツールを駆使するため、組織側も早期パッチ適用と防御網の自動化で対抗する必要があります。

攻撃の自動化容易性“Yes/No”割合の円グラフ
図2:攻撃の自動化容易性“Yes/No”割合の円グラフ(2025年累計)

技術的影響範囲(Technical Impact)

62件中55件(約89%)は「Total」(=脆弱性を突かれるとシステムを完全制御されてしまう深刻な影響を持つもの)でした。(図3参照)。攻撃者がシステム全面乗っ取り可能な脆弱性を優先的に悪用していることがわかります。特に単独で完全権限を奪える脆弱性は魅力的な標的であり、一方部分的な影響に留まる脆弱性も他のTotalな脆弱性と組み合わせて攻撃チェーンに利用される恐れがあります。

Total/Partial割合の比較チャート
図3:Total/Partial割合の比較チャート

※注)KEVカタログ掲載時点で実害確認済みである以上、CVSSスコアの大小や影響範囲の違いに関わらず優先度高く対処すべきである点に留意が必要です。

CVSSスコア分布

4Qに追加された脆弱性のCVSS基本値は、最大が10.0(3件)、9.8が数件含まれ、9.0以上の「Critical(緊急)」帯が約39%(24件)、7.0~8.9の「High(高)」帯が約52%(32件)を占めました。残り約10%がMedium以下です。平均値は8.48で、前四半期同様に高スコアの欠陥が大半を占めています。3QではCVSS10.0が5件含まれていましたが、4QではCritical帯比率は維持しつつ極端に満点の脆弱性は減少しました。それでもなおHigh以上が全体の9割を超えており、KEVカタログに登録される脆弱性がいかに深刻度の高いものに偏っているかを裏付けています。Criticalでなくとも攻撃に利用され得る(実際に悪用された)ことを示すデータでもあり、スコアに油断せず注意が必要です。

攻撃手法・影響の深掘り分析

前述の統計情報を踏まえ、4Qに観測された攻撃の特徴や脅威動向をさらに分析します。ランサムウェアなどサイバー犯罪による悪用事例や、国家支援型グループ(APT)の関与、古い脆弱性の再悪用など、データから読み取れるポイントを考察します。

実際にランサムウェア攻撃に悪用された脆弱性

3Qと同様、ランサムウェア攻撃での悪用が確認された事例はごく少数に留まります。4Qに追加された62件中、実際にランサムウェアに悪用されたと判明しているのは3件(約5%)でした。具体的にはオラクルの Oracle Concurrent Processing における認証に関する脆弱性/Oracle E-Business Suite(EBS)のSSRF(サーバサイドリクエストフォージェリ)の脆弱性(CVE-2025-61882および61884)やReact Server Componentsにおける認証不要のリモートコード実行の脆弱性(CVE-2025-55182)がランサムウェア攻撃で利用された例です。これらはいずれも企業の基幹システムや広く使われるフレームワークに関わる欠陥で、金銭目的の攻撃者に狙われたと考えられます。ただしKEVカタログ全体で見ると、依然として国家主体・高度なAPT攻撃での悪用例が多く、ランサムウェアによる事例は氷山の一角です。これは、KEVカタログが単なる理論上の危険性ではなく、「現在進行形で利用されている攻撃手法」を反映したリストであることを示しています。高度な攻撃者はゼロデイ脆弱性を含む様々な欠陥を悪用しており、ランサムウェア以外の脅威にも引き続き注意が必要です。

古い脆弱性の再注目

4Qに新規登録された脆弱性の中には、2024年以前に発見されたものが17件(約27%)含まれていました。最も古いものは2010年公表のMicrosoft製品の脆弱性(CVE-2010-3962)で、15年以上前の欠陥が今になって攻撃に利用されたことになります。前四半期にも2020年公表のD-Link製品脆弱性が複数追加されており、サポート切れの古い機器・ソフトが依然として攻撃対象になる実態が浮き彫りです。こうした古い脆弱性はパッチ未適用のまま放置されている資産が狙われており、攻撃者は年代を問わず利用可能な欠陥を有効活用しています。組織内に残存するレガシーシステムの脆弱性管理を怠ると、想定外に古いバグで侵入を許すリスクがあることに注意が必要です。

脆弱性悪用の手口

攻撃者の手口としては、引き続きリモートコード実行(RCE)や権限昇格といった直接的にシステム乗っ取りに繋がる攻撃が顕著です。例えば前述のCWE分布にあるCWE-787, CWE-416などのメモリ破壊型脆弱性は、悪用された場合、ターゲットプロセス内で任意コード実行やサービス停止を引き起こします。またCWE-78等のコマンドインジェクションは、サーバー上で攻撃者のコマンドを実行させる手段として多用されています。4Qにはこれらテクニカルな攻撃に加え、認証・認可の不備(CWE-306/862等)を突いて管理者権限を不正取得するケースも見られ、攻撃パターンは多岐に及びます。総じて攻撃者は最も効率よく高い権限を得られる脆弱性の組み合わせを模索しており、一つでも未対策の弱点があれば連鎖的に侵入を許す恐れがあります。

影響とリスクの評価

攻撃者は完全なシステム制御が可能な脆弱性(=「Total」)を好んで悪用します。CVSSスコアが「High」や「Critical」の深刻度であればなおさらですが、たとえ中程度でも「KEVカタログに掲載=実害発生済み」である以上、油断は禁物です。特にランサムウェア攻撃では、初期侵入に使った脆弱性自体はさほど目立たない中~高程度の欠陥であっても、内側で別のCritical脆弱性と組み合わせて横展開・権限昇格することが知られています。部分的な影響の脆弱性であっても他の欠陥と組み合わされば致命傷となり得るため、既知の悪用脆弱性は大小問わず優先的に潰す姿勢が重要です。経営層にとっても、これらの統計が示すリスクの高さを踏まえれば、脆弱性対応に十分なリソース投資と適切な意思決定を行う必要性が理解できるでしょう。

組織が取るべき対策

4Qの分析レポートの結果を受け、組織として優先的に講じるべき脆弱性管理策を整理します。経営層は戦略的視点から、現場のセキュリティ担当者は実践的観点から、以下のセキュリティ対策の実施をおすすめします。

KEV掲載脆弱性の最優先パッチ適用

CISAは継続的にKEVカタログ掲載項目を優先的に修正するよう勧告しています。自社で利用する製品・システムに該当する脆弱性が公開された場合、定例パッチを待たず緊急で対応する体制を整えましょう。自動アラートによる通知や情報資産との照合などによって見落としを防ぐ運用が有効です。特に公表から日が浅い脆弱性は攻撃者も素早く狙ってくるため、初動対応のスピードが重要になります。

主要ベンダー製品の迅速なアップデート

MicrosoftやOracle、Cisco、Googleなど主要ベンダーのソフトウェアや機器は引き続き攻撃者の主要標的です。毎月発表されるセキュリティ更新プログラム(例: Microsoftの月例パッチ)や緊急アップデート情報を速やかに収集し、適用テストを経て迅速に全社展開する習慣をつけましょう。4QではMicrosoft製品の脆弱性が突出しましたが、他ベンダーでもゼロデイが報告されればすぐ悪用される可能性があります。例えば「重要なアップデートは可能な限り2週間以内に適用」などといった内部目標を設定し、経営陣もその重要性を認識すべきでしょう。

ネットワーク機器・IoT/産業機器の点検

企業ネットワークや工場内に設置されたルーター、NAS、監視カメラ、制御システム等も忘れてはいけません。4QにもD-LinkルーターやOpenPLCなどIoT/OT機器の脆弱性が含まれており、これらは往々にしてファームウェア更新が滞留しがちです。サポート切れやアップデート未適用の機器がないか棚卸しし、可能な限り最新ファームウェアへの更新や機器リプレースを実施しましょう。どうしても更新できない場合は、ネットワーク分離やアクセス制限など緩和策を講じ、インターネットから直接アクセスできる状態を放置しないことが重要です。

脅威検知とインシデント対応の強化

脆弱性への対策だけでなく、悪用された際に速やかに検知・対応する能力も不可欠です。IPS/IDSやエンドポイント検知(EDR)のシグネチャを最新化し、KEVに掲載された脆弱性の既知の攻撃パターンやIoC(Indicators of Compromise)を監視します。CISAやセキュリティベンダーから提供される検知ルールやYARAルールを活用し、ログ分析やトラフィック監視に組み込みましょう。また万一侵入を許した場合でも、早期にそれを発見し被害を最小化できるようインシデント対応訓練を積んでおくことも有効です。

資産管理と内部教育の徹底

攻撃者に狙われる脆弱性は多岐にわたるため、まずは自社システムの全容を把握することが出発点です。ハードウェア・ソフトウェア資産の最新インベントリを整備し、使用中の全ての製品についてサポート状況や最新パッチ適用状況をチェックします。使われていないシステムや旧式OSは計画的に撤去し、やむを得ず残す場合もネットワークを分離するなどリスク低減策を講じます。またIT部門や開発部門に対し、「古い脆弱性を放置しない」「定期的なアップデート適用は必須」といった意識付けを行います。定期的なセキュリティ研修や訓練で、脆弱性管理の重要性を全社員と共有することも大切です。

脆弱性管理プロセスの強化と自動化

増加する脆弱性に対処するには、属人的な対応から脱却しプロセスとツールの整備を進める必要があります。脆弱性情報収集から評価、パッチ適用状況のトラッキングまで一元管理できる仕組みを整えましょう。例えばKEVカタログのデータを自社資産データベースと照合する自動ツールを導入すれば、新たな緊急欠陥の検知と対応指示を迅速化できます。また定期的に脆弱性対応状況をレビューし、未対応件数や所要日数といったKPIを計測・改善することも効果的です。経営層は必要な人員・予算を投じ、継続的に脆弱性管理体制を進化させることが求められます。

脆弱性管理プロセスの概要とポイントについては以下の記事でも解説しています。あわせてぜひご覧ください。
脆弱性管理とIT資産管理-サイバー攻撃から組織を守る取り組み-

まとめ

2025年4QKEVカタログ分析レポートからは、攻撃者の手口がより広範かつ巧妙になっている実態が浮き彫りになりました。特に今年はKEVカタログへのCVE追加件数が前年より増加し記録更新となったことから、従来以上のハイペースで緊急脆弱性が発生・悪用される可能性が高まっています。侵入前提での備えを強化すべきでしょう。

2025年を通じて言えることは、脆弱性対応のスピードと徹底度を組織文化として根付かせることです。経営層はリスクと投資対効果を理解し、現場は技術的施策を愚直に実行する。そして最新の脅威情報をキャッチアップし続けることで、組織全体のサイバー耐性を高められるでしょう。来たる2026年も同様のレポートを継続し、変化する攻撃者の戦術に対抗すべく知見をアップデートしていきます。

BBSecでは

脆弱性の悪用リスクに迅速に対応するには、専門家の支援を仰ぐことも有効です。ブロードバンドセキュリティ(BBSec)では、発覚した脆弱性への対応支援や緊急インシデント対応サービスをご提供しています。自社だけでは対応が難しいゼロデイ攻撃の発生や、大規模サイバー攻撃の兆候を検知した際はぜひご相談ください。経験豊富なセキュリティ専門チームが、お客様のシステム状況の迅速な把握、攻撃の封じ込め、再発防止策の導入まで包括的にサポートいたします。また、平時からの脆弱性診断サービスやセキュリティ研修なども取り揃えており、脆弱性管理体制の構築から有事の対応までワンストップで支援可能です。BBSecのサービスを活用し、貴社のセキュリティレベル向上にぜひお役立てください。

サイバーインシデント緊急対応

セキュリティインシデントの再発防止や体制強化を確実に行うには、専門家の支援を受けることも有効です。BBSecでは緊急対応支援サービスをご提供しています。突然の大規模攻撃や情報漏洩の懸念等、緊急事態もしくはその可能性が発生した場合は、BBSecにご相談ください。セキュリティのスペシャリストが、御社システムの状況把握、防御、そして事後対策をトータルにサポートさせていただきます。

サイバーセキュリティ緊急対応電話受付ボタン
SQAT緊急対応バナー

ウェビナー開催のお知らせ

  • 2026年2月4日(水)13:00~14:00
    【好評アンコール配信】「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
  • 2026年2月10日(火)14:00~15:00
    Web攻撃の“今”がわかる OWASP Top 10 2025で読み解く脆弱性の狙われ方と対策の考え方
  • 2026年2月18日(水)14:00~15:00
    急増する「LINE誘導型」ビジネスメール詐欺の実態 ―社長になりすます最新BEC手口と組織で取るべき対策―
  • 最新情報はこちら

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    CWE Top 25 2025年版(後編)– メモリ安全性が上位に増えた理由と対策の要点

    Share
    CWE Top 25 2025年版– メモリ安全性が上位に増えた理由と対策の要点アイキャッチ画像

    CWE Top 25:2025」では、もう一つ見逃せない特徴があります。それが、メモリ領域の安全性に関わる弱点が複数上位に含まれている点です。本記事では、CWE Top 25 2025年版で目立つメモリ系弱点を整理したうえで、なぜ上位に増えているのか、Webサービス運用の観点でどのように備えるべきかを解説します。

    はじめに:前編の振り返り(Web/API 12項目)

    前編では、CWE Top 25 2025年版のうち、WebアプリケーションやAPIで特に問題になりやすい弱点をピックアップし、リスクと診断観点を整理しました。具体的には、XSSやCSRFといった入力・リクエスト起点の脆弱性に加え、「認可の欠如不備」のようにログインしていても不正操作が成立するタイプの脆弱性が、実被害につながりやすいポイントとして挙げられます。Web/APIは機能追加や仕様変更が多いため、対策しているつもりでも抜けが生まれやすく、定期的な点検が重要です。

    前編の記事はこちらからご覧いただけます。
    CWE Top 25 2025年版(前編)– Web/APIで狙われやすい弱点12項目と診断ポイント」(https://www.sqat.jp/kawaraban/41257/

    前編で取り上げたWeb/APIの脆弱性は、日々の開発や運用の中で発生しやすく、脆弱性診断でも頻出する領域です。一方で、CWE Top 25 2025年版を俯瞰すると、もう一つ見逃せない特徴があります。それが、メモリ領域の安全性に関わる脆弱性が複数上位に含まれている点です。

    メモリ系の脆弱性は、C/C++など低レベル言語で起きやすい印象が強く、「Webアプリ中心の開発では関係が薄い」と思われることもあります。しかし実際には、Webサービスを支える基盤やOSS、ミドルウェア、各種ライブラリにはネイティブ実装が含まれることも多く、アプリケーションの外側でリスクが顕在化するケースも少なくありません。また、メモリ破壊系の脆弱性は、単なるサービス停止(DoS)に留まらず、条件次第では任意コード実行など深刻な侵害につながる可能性があります。攻撃の影響が大きく、対応にも専門性が求められることから、近年あらためて注目されている領域といえます。

    そこで後編では、CWE Top 25 2025年版で目立つメモリ系弱点を整理したうえで、なぜ上位に増えているのか、Webサービス運用の観点でどのように備えるべきかを解説します。

    メモリ領域の安全に関する脆弱性が上位に増えている理由

    CWE Top 25 2025年版ではメモリ安全性に関わる脆弱性が複数ランクインしている傾向もみてとれます。一見すると「これはC言語など低レベル言語の話で、Webアプリ開発とは関係が薄いのでは?」と思われるかもしれません。しかし実際には、Webサービスを提供する側にとっても無視できないテーマになっています。ここでは、2025年版で目立つメモリ系の脆弱性と、上位に増えている背景を整理します。

    2025年に目立つメモリ系6項目

    CWE Top 25 2025年版の中で、特にメモリ領域の安全性に関連する項目としては以下が挙げられます。

    1. CWE-787:範囲外の書き込み
    2. CWE-416:解放したメモリの使用
    3. CWE-125:範囲外の読み取り
    4. CWE-476:NULLポインター逆参照
    5. CWE-121:スタックベースバッファオーバーフロー
    6. CWE-122:ヒープベースバッファオーバーフロー

    これらは主にC/C++言語などで発生しやすい脆弱性で、メモリ破壊を起点としてアプリケーションの異常動作やクラッシュ、条件次第では任意コード実行にまでつながる可能性があります。

    メモリ系が“ランク上昇”した背景

    OSS・ミドルウェア・実行環境の影響が大きい

    近年のシステム開発では、自社でゼロからすべてを実装することはほとんどありません。
    Webアプリケーション自体は高水準言語(Java、PHP、Python、Ruby、JavaScriptなど)で書かれていたとしても、実際には裏側で多くのソフトウェア資産に依存しています。 例えば、以下のような領域はネイティブ実装(C/C++など)が含まれることが多く、メモリ安全性の影響を受けやすい代表例です。

    • 画像・動画の変換や解析
    • 圧縮・解凍処理
    • 暗号処理
    • OSやコンテナの周辺コンポーネント
    • Webサーバやロードバランサなどの基盤ソフトウェア

    つまり「アプリはWebだからメモリ破壊は関係ない」と切り分けるのではなく、サービス全体を構成する要素としてメモリ安全性の弱点が影響し得る、という視点が必要になります。

    「攻撃が成立した時のインパクト」が大きい

    メモリ破壊系の脆弱性は、単にアプリがダウンする(DoS攻撃等の影響による)だけでなく、条件がそろうと攻撃者にとって非常に強力な結果につながることがあります。たとえば、任意コード実行や権限奪取の足がかりになるケースもあり、被害の深刻度が高くなりやすい点が特徴です。

    Webアプリケーションの脆弱性は「データが漏れる」「不正操作される」といった被害が中心になりやすい一方で、メモリ系は侵害の方向性が変わり、“システムそのものの制御”に影響する可能性がある点で性質が異なります。このインパクトの大きさが、ランキング上でも目立ちやすい要因の一つです。

    “開発者の気付き”だけでは防ぎにくい

    XSSやSQLインジェクションは、実装者の意識と共通部品の整備で減らしていける領域です。一方でメモリ安全性の弱点は、そもそも自社コードではなく、依存しているライブラリやミドルウェアの脆弱性として露出することも少なくありません。この場合、開発者が気を付けて実装していても防ぎきれず、必要になるのは次のような対策です。

    • 利用コンポーネントの把握(棚卸し)
    • 脆弱性情報の継続的な収集
    • バージョンアップ・パッチ適用の判断と運用
    • 影響範囲の評価(どの機能が影響を受けるか)

    つまり、メモリ系の脆弱性は「作り込みで防ぐ」だけではなく、運用で守る力も問われる領域だと言えます。

    脆弱性対応は「作り込み」+「運用」の両輪

    Webアプリケーションのセキュリティ対策というと、入力チェックや認可実装など“作り込み”に注目が集まりがちです。もちろんこれは重要ですが、メモリ系の弱点が示すように、脆弱性対応には運用面の強さも求められます。

    運用面で意識したいポイントは、以下のように整理できます。

    • 利用しているライブラリ/ミドルウェアの把握(棚卸し)
    • 脆弱性情報の継続的な収集と影響評価
    • パッチ適用・アップデートの判断と実施
    • 監視・ログによる異常兆候の検知
    • 必要に応じた防御策(WAFなど)による被害軽減

    特に「アップデートできる体制があるか」「影響範囲を素早く見積もれるか」は、脆弱性が公開された際の対応スピードに直結します。メモリ系の脆弱性は影響が大きくなりやすい分、発覚後の初動が被害を左右するため、日頃から“運用で守る仕組み”を整えておくことが重要です。

    脆弱性診断でどう確認するか(診断観点の例)

    メモリ領域の安全性の脆弱性は、Web/APIの脆弱性とは性質が異なり、「画面やAPIを触るだけでは見えにくい」ケースもあります。そのため、脆弱性診断ではアプリケーションの挙動確認に加えて、実装・構成・依存関係といった複数の観点からリスクを洗い出すことが有効です。

    Webアプリケーション診断/API診断

    実際の画面・APIに対して攻撃パターンを当て、脆弱性が成立するかどうかを確認します。
    メモリ系の弱点そのものを直接検出するのは難しい場合もありますが、前編で整理した認可不備・IDOR・SSRF・ファイル関連など、実被害につながりやすい脆弱性を網羅的に確認できる点が強みです。

    ソースコード診断(SAST)

    危険な実装パターンや、入力値の扱い方、権限判定の実装の偏りなどを、コードレベルで洗い出せる手法です。メモリ領域の安全性の観点でも、ネイティブコードを含む箇所や危険APIの利用状況、例外処理の不足などを確認することで、潜在的なリスクを把握しやすくなります。特に、開発を継続しながら対策を積み上げる場合、設計や共通部品の見直しにも活用できます。

    プラットフォーム診断/OSS観点(依存関係・構成)

    メモリ系の脆弱性を含む“依存資産のリスク”に対応するには、構成・依存関係の観点が欠かせません。アプリケーションの外側に原因がある場合、どれだけアプリの実装を直してもリスクが残るためです。「脆弱性が出たときに、すぐ把握できる・すぐ対応できる」状態を作ることが、結果的にリスクを下げる近道になります。

    まとめ

    CWE Top 25 2025年版から読み取れるのは、Webアプリ・APIで頻出する脆弱性が依然として事故につながりやすい一方で、メモリ安全性のように“アプリの外側”に潜むリスクも無視できない存在になっているという点です。この2つを両立できるかどうかが、2025年のセキュリティ対策の分かれ道になると言えます。

    “定期的な診断+改善”でリスクを下げる

    脆弱性対策は、一度対応して終わりではなく、仕様変更・機能追加・依存資産の更新によって状況が変化します。だからこそ、CWE Top 25のような指標を参考にしながら、第三者視点の脆弱性診断で現状を確認し、優先度を付けて改善していくことが有効です。Webアプリケーション診断・API診断・ソースコード診断を組み合わせることで、「攻撃が成立するポイント」と「根本原因」を整理しやすくなり、修正の手戻りを減らしながら安全性を高められます。継続的な診断と改善を通じて、インシデントの予防と品質向上につなげていきましょう。

    BBSecでは

    「どこが危ないのか」を把握しないまま対策を進めると、重要な弱点が残ったり、修正の手戻りが増えたりすることがあります。Webアプリケーション/APIの脆弱性診断により、実際に攻撃が成立するポイントを洗い出し、優先度を付けて改善につなげることが可能です。まずは現状の課題や診断範囲について、お気軽にご相談ください。

    限定キャンペーン実施中!

    ソースコード診断 アップチャージプランのご案内

    Web診断に加えて、アプリケーション内部の脆弱性を確認できるソースコード診断(アップチャージプラン)もご用意しています。

    詳細・お申し込みボタン

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    CWE Top 25 2025年版(前編)– Web/APIで狙われやすい弱点12項目と診断ポイント

    Share
    「CWE Top 25 2025年版(前編)– Web/APIで狙われやすい弱点12項目と診断ポイント」アイキャッチ画像

    2025年12月、MITREより「CWE Top 25:2025」が公開されました。本記事では、CWE Top 25 2025年版のうち、WebアプリケーションやAPIに直結する12項目をピックアップし、リスクと診断観点を整理します。

    CWE Top 25とは

    Webアプリケーションや業務システムを狙った攻撃は年々巧妙化していますが、実は“よく悪用される脆弱性”には一定の傾向があります。限られた工数の中で効果的に対策を進めるには、脆弱性を闇雲に潰すのではなく、被害につながりやすい弱点から優先して対応することが重要です。そこで参考になるのが、MITREが公開している「CWE Top 25」です。CWE(Common Weakness Enumeration、共通脆弱性タイプ)は、ソフトウェアに潜む弱点を体系的に整理したもので、CWE Top 25はその中でも特に危険度が高く、実際の攻撃にもつながりやすい弱点をランキング形式でまとめたものです。開発・運用の現場で「どこから手を付けるべきか」を判断するための指標として活用できます。

    CWE Top 25は毎年アップデートされるため、年ごとの傾向を追うことで「長年狙われ続けている脆弱性」や「新たに注目されているリスク」も見えやすくなります。2024年版の内容は過去記事でも解説していますので、あわせてご覧ください。
    【CWE TOP 25 2024年版】にみる新たなセキュリティ脅威と指針」(https://www.sqat.jp/kawaraban/33156/

    CWE Top 25 2025年版

    順位CWE ID脆弱性名称
    1CWE-79入出力の不適切な無害化(クロスサイトスクリプティング(XSS))
    2CWE-89SQLコマンドの特殊要素の不適切な無害化(SQLインジェクション)
    3CWE-352クロスサイトリクエストフォージェリ(CSRF)
    4CWE-862認可の欠如
    5CWE-787範囲外の書き込み
    6CWE-22制限ディレクトリへのパス制限不備(パストラバーサル)
    7CWE-416解放したメモリの使用
    8CWE-125範囲外の読み取り
    9CWE-78OSコマンドで使用される特殊要素の不適切な無効化(OSコマンドインジェクション)
    10CWE-94コード生成の不適切な制御(コードインジェクション)
    11CWE-120入力サイズチェックなしのバッファコピー(古典的バッファオーバーフロー)
    12CWE-434危険なタイプのファイルのアップロード許可
    13CWE-476NULLポインター逆参照
    14CWE-121スタックベースバッファオーバーフロー
    15CWE-502不適切なデータ逆シリアル化
    16CWE-122ヒープベースバッファオーバーフロー
    17CWE-863不適切な認可
    18CWE-20不適切な入力検証
    19CWE-284不適切なアクセス制御
    20CWE-200権限を持たないユーザへの機密情報の漏洩
    21CWE-306重要な機能の使用に対する認証の欠如
    22CWE-918サーバサイドリクエストフォージェリ(SSRF)
    23CWE-77コマンドで使用される特殊要素の不適切な無害化(コマンドインジェクション)
    24CWE-639ユーザ制御キーによる認可バイパス
    25CWE-770制限やスロットリングなしのリソース割当

    Web/APIに直結する“狙われやすい12項目”

    CWE Top 25 2025年版には、メモリ安全性の弱点など幅広い項目が含まれていますが、脆弱性診断会社の視点で特に注目したいのは、WebアプリケーションやAPIに直結し、実被害につながりやすい脆弱性です。Web/APIは外部からアクセス可能な入口が多く、仕様変更や機能追加も頻繁に発生します。その結果、実装ミスや設計の抜けが生まれやすく、攻撃者にとっても狙いやすい領域になりがちです。ここでは、Top 25のうちWeb/APIに絡む以下の12項目をピックアップし、リスクと脆弱性診断の観点を整理します。

    Web/APIで特に重要な12項目一覧

    1. CWE-79
    2. CWE-352
    3. CWE-862
    4. CWE-22
    5. CWE-434
    6. CWE-863
    7. CWE-20
    8. CWE-284
    9. CWE-200
    10. CWE-306
    11. CWE-918
    12. CWE-639

    入力・出力の不備(攻撃の入口になりやすい)

    CWE-79:クロスサイトスクリプティング(XSS)

    コメント欄のような分かりやすい入力欄だけでなく、検索結果、プロフィール、管理画面のメモ欄など「入力した内容が表示される場所」全般が対象になります。XSSが成立すると、セッション情報の窃取によるアカウント乗っ取り、偽画面による情報詐取、管理者権限での操作悪用などにつながる可能性があります。特に管理画面で発生した場合、被害が大きくなりやすい点が特徴です。

    脆弱性診断では、入力点の洗い出しに加え、“どこで入力が表示されるか(出力箇所)” を意識して確認します。実装側で「入力チェックをしている」つもりでも、表示時のエスケープが不十分なケースは多く、テンプレートの扱いや出力文脈(HTML/属性/JavaScript)まで含めた確認が重要になります。

    SQAT.jpでは過去にもクロスサイトスクリプティングについて、初心者向けの解説記事を公開しています。こちらもあわせてご覧ください。
    クロスサイトスクリプティング(XSS)の脆弱性 -Webアプリケーションの脆弱性入門 1-」(https://www.sqat.jp/tamatebako/27269/

    CWE-20:不適切な入力検証

    入力検証不備は、受け取った値が想定どおりかどうかの確認が不足している状態です。一見すると地味な問題に見えますが、WebアプリやAPIでは、入力値がそのままDB検索、権限判定、外部連携、ファイル処理などに渡ることが多く、他の脆弱性の引き金になりやすい“起点”です。特にAPIでは、フォーム入力だけでなくJSON形式のリクエスト、配列やネスト構造、数値・文字列の型違いなど、入力のバリエーションが増えます。その結果、「画面側では弾けているのにAPI直叩きで通ってしまう」「境界値や異常値で想定外の挙動になる」といった事故が起きやすくなります。

    脆弱性診断では、正常系だけでなく、境界値・異常系・型違い・過剰な長さ・未定義パラメータなどを含めて入力を揺さぶり、想定外の処理やエラー露出が起きないかを確認します。

    リクエスト偽装・処理のすり抜け(攻撃者が「操作」を作る)

    CWE-352:クロスサイトリクエストフォージェリ(CSRF)

    CSRFは攻撃者が用意したページやリンクを踏ませることで、ユーザ本人が操作したように見えるリクエストが送信され、設定変更や登録情報更新などが実行されてしまう可能性があります。特に危険なのは、パスワード変更、メールアドレス変更、権限変更、退会処理など「状態を変える操作」です。攻撃が成立しても操作主体が正規ユーザに見えるため、被害に気づきにくい点もCSRFの厄介なところです。

    脆弱性診断では、重要操作にCSRFトークンが実装されているか、SameSite属性が適切か、Origin/Refererの扱いがどうなっているかなどを確認します。SPAやAPI中心の構成では「CSRFは関係ない」と思われがちですが、認証方式によっては成立するため、設計前提から整理して確認することが重要です。

    SQAT.jpでは過去にもクロスサイトリクエストフォージェリについて、初心者向けの解説記事を公開しています。こちらもあわせてご覧ください。
    クロスサイトリクエストフォージェリ(CSRF/XSRF)とは?狙われやすいWebアプリケーションの脆弱性対策」(https://www.sqat.jp/tamatebako/12249/

    CWE-918:サーバサイドリクエストフォージェリ(SSRF)

    SSRFは、サーバ側が外部へアクセスする仕組みを悪用され、攻撃者が任意の宛先にリクエストを送らせる脆弱性です。たとえば「指定したURLから画像を取得する」「外部APIのURLを登録する」といった機能がある場合、入力値の制御が不十分だとSSRFにつながる可能性があります。SSRFが危険なのは、外部から直接アクセスできない内部ネットワークや管理系サービスに到達できてしまう点です。環境によっては、クラウドのメタデータ(認証情報)取得など、重大な侵害につながるケースもあります。

    脆弱性診断では、URL入力や外部通信の機能を洗い出し、許可リスト制御があるか、名前解決やリダイレクトがどう扱われるか、内部アドレス(localhostやプライベートIP)へのアクセスが可能かなどを確認します。外部連携機能は便利な反面、攻撃の入口になりやすいため、重点的な確認が必要です。

    認証・認可の不備(ログインしていても守れていない)

    CWE-306:重要な機能の使用に対する認証の欠如

    重要な機能の使用に対する認証の欠如は、本来ログインが必要な操作が、認証なしで実行できてしまう状態です。代表例としては、管理者向けのAPIや運用機能が「画面からは触れない」ために見落とされ、URL直叩きで実行できてしまうケースが挙げられます。 この弱点があると、攻撃者はアカウントを用意する必要すらなく、いきなり機能を悪用できてしまいます。影響範囲は機能次第で、情報閲覧だけでなく、設定変更やデータ削除などにつながる可能性もあります。

    脆弱性診断では、ログイン前に到達できるURL・APIを洗い出し、認証が正しくかかっているかを横断的に確認します。特に、管理系の機能や“メンテナンス用”に追加されたエンドポイントは、抜けが起きやすいポイントです。

    CWE-862:認可の欠如

    認可の欠如は、「ログインしているユーザが、その操作をしてよいか」の判定が不足している状態です。認証が正しく実装されていても、認可が抜けていると、一般ユーザが管理機能を実行できたり、他人の情報にアクセスできたりするリスクが生まれます。現代のWebアプリはAPI化が進み、画面とAPIが分離されているケースも多くあります。その結果、「画面上ではボタンが表示されないが、APIを直接叩くと通ってしまう」といった問題が発生しやすくなります。認可は“画面制御”ではなく“サーバ側判定”が必須です。

    脆弱性診断では、ユーザ権限を切り替えながら同じAPIを試す、IDを変更して他人データに触れないか確認するなど、権限境界を意識したテストを行います。認可不備は事故につながりやすい一方で見落とされやすいため、重点的に確認すべき項目です。

    CWE-863:不適切な認可

    誤った認可は、認可チェック自体は存在するものの、判定条件が不十分・誤っている状態です。たとえば「ロール(一般/管理者)は見ているが、所属組織や契約単位の制御が抜けている」「閲覧は制御できているが更新だけ抜けている」など、複雑な仕様ほど起きやすい傾向があります。このタイプの問題は、単純な“認可チェックの抜け”よりも発見が難しく、機能仕様を理解したうえでテストしないと見落とされがちです。結果として、公開後に利用者からの指摘やインシデントで発覚することもあります。

    脆弱性診断では、ロールだけでなく、組織・契約・所有権などの境界を整理し、境界を跨ぐ操作ができてしまわないかを確認します。実装だけでなく、設計段階での権限モデルの整理が重要になります。

    CWE-284:不適切なアクセス制御

    不適切なアクセス制御は、認証・認可・制限の仕組み全体が適切に機能していない状態を指す、非常に重要なカテゴリです。CWE-862やCWE-863、CWE-639などと密接に関係し、実際のインシデントでは“アクセス制御の穴”としてまとめて問題になるケースも少なくありません。アクセス制御の難しさは、実装ミスだけでなく、仕様変更や機能追加によって整合性が崩れやすい点にあります。APIが増えるほど確認対象も増え、権限チェックの一貫性を保つのが難しくなります。

    脆弱性診断では、画面・API・直接URLアクセスなど複数経路からの到達性を確認し、「見えないはずの機能が触れてしまう」「アクセスできないはずの情報が見えてしまう」といった問題を洗い出します。アクセス制御は“守りの土台”であり、最優先で見直すべき領域です。

    CWE-639:ユーザ制御キーによる認可バイパス

    ユーザ制御キーによる認可バイパスは、ユーザが指定できるIDやキーを悪用し、認可を回避できてしまう問題です。いわゆるIDOR(Insecure Direct Object Reference)として知られるケースが多く、例えば「注文ID」「請求書ID」「ユーザID」などを変更するだけで他人の情報にアクセスできてしまうといった形で発生します。この脆弱性が厄介なのは、画面上では正しく動いて見えることが多い点です。正規ルートでは問題がなくても、パラメータを改ざんすると成立してしまうため、悪意ある操作を前提にした確認が欠かせません。

    脆弱性診断では、IDやキーを意図的に変更し、他人データの閲覧・更新・削除ができないかを確認します。設計としては、IDを推測しにくくするだけでなく、サーバ側で必ず所有権チェックを行うことが重要です。

    情報の露出(「次の攻撃」の起点になる)

    CWE-200:権限を持たないユーザへの機密情報の漏洩

    機密情報の露出は、権限のない相手に情報が見えてしまう状態です。例としては、APIレスポンスに不要な項目が含まれている、エラーメッセージに内部情報が出ている、管理画面の情報が一般ユーザから参照できる、といったケースが挙げられます。情報漏洩は、それ単体でも重大な事故ですが、攻撃者にとっては“次の攻撃を成功させる材料”になります。たとえば、ユーザ情報や内部構成が漏れることで、なりすましや権限突破、別の脆弱性悪用が容易になることがあります。

    脆弱性診断では、画面表示だけでなくAPIレスポンスの内容、エラー出力、ログ出力の扱いまで含めて確認します。「返さなくてもよい情報を返していないか」を見直すことは、対策コストに対して効果が大きいポイントです。

    ファイル・パスの取り扱い(“便利機能”が事故の原因になる)

    CWE-22:パストラバーサル

    パストラバーサルは、ファイル・パスの指定を悪用され、想定外のファイルにアクセスされてしまう脆弱性です。例えば、ダウンロード機能や画像表示機能で、パラメータがそのままファイル・パスに使われている場合に発生しやすく、設定ファイルや機密ファイルの閲覧につながる可能性があります。この問題は、アプリケーション内部の設定情報や秘密鍵などの露出を招くことがあり、被害が“情報漏えい”に留まらず、侵入やなりすましの起点になることもあります。

    脆弱性診断では、パス指定のパラメータを揺さぶり、制限ディレクトリ外の参照ができないかを確認します。設計としては、ファイルはIDで管理し、サーバ側で実体パスに変換する方式が安全です。

    CWE-434:危険なタイプのファイルのアップロード許可

    危険なファイルアップロードは、攻撃者が悪意あるファイルをアップロードできてしまう脆弱性です。拡張子チェックだけで判定している場合、実体がスクリプトや実行形式であってもすり抜けられることがあり、Webシェル設置やマルウェア配布などにつながる危険があります。また、アップロードしたファイルがそのまま公開ディレクトリに置かれている場合、アクセスされるだけで攻撃が成立するケースもあります。ファイル機能はユーザにとって便利な一方で、攻撃者にとっても“侵入口”になりやすい領域です。

    脆弱性診断では、アップロード可能な拡張子・MIME・実体判定、保存先、参照方法、実行可否などを確認します。特に「アップロード後にどう扱われるか(公開されるか、変換されるか)」まで含めて評価することが重要です。

    【補足】なぜこの12項目が脆弱性診断で重要なのか
    ここまで見てきた12項目は、いずれもWebアプリやAPIで発生しやすく、攻撃者が外部から試行しやすい弱点です。また、認可やアクセス制御のように、仕様・設計・実装が絡み合う領域は、チェック漏れが起きやすい一方で、発見が遅れると影響が大きくなりがちです。 そのため、開発時のレビューや自動テストだけでなく、第三者視点での脆弱性診断によって「実際に攻撃が成立するか」を確認し、優先度を付けて改善していくことが有効です。

    現場での優先度付け(Web/API向け)

    CWE Top 25に含まれる弱点は幅広く、すべてを一度に潰すのは現実的ではありません。そこで重要になるのが、「被害が大きいもの」「攻撃者が試しやすいもの」から優先して対策する考え方です。ここでは、WebアプリケーションやAPIを前提に、現場で取り組みやすい優先順位を整理します。

    認可

    まず最優先に見直したいのは、認可(Authorization)に関する脆弱性です。認証(ログイン)が正しく動いていても、「そのユーザがその操作をしてよいか」の判定が甘いと、他人の情報閲覧や不正更新、管理機能の悪用につながります。特にAPIが増えるほど、権限チェックの抜けや判定ミスが起きやすく、事故の原因になりがちです。認可の問題は、攻撃が成立すると影響範囲が大きく、かつログ上は正規ユーザの操作に見えることもあります。Web/APIにおけるセキュリティの土台として、まずは認可を最優先で点検することが重要です。

    入出力・CSRF

    次に優先したいのは、入出力の取り扱い(XSSや入力検証不備など)と、CSRFです。
    入力値は、画面表示・DB操作・外部連携など多くの処理に影響するため、わずかな実装ミスが攻撃の入口になりやすい領域です。またXSSは、利用者のアカウント乗っ取りや管理画面の悪用につながる可能性があり、優先度の高い脆弱性です。CSRFについても、状態変更系の操作(変更・更新・削除)がある限り、対策の抜けがあると被害につながります。「ログインしているから安全」ではなく、“正しい意図の操作かどうか”を担保できているかを確認する必要があります。

    SSRF・ファイル関連

    SSRFやファイル関連の脆弱性は、システムに該当機能がある場合、優先度を一段階上げて確認すべき項目です。たとえば、URL入力を受け付ける機能(外部連携、Webhook、画像取得など)がある場合、SSRFが成立すると内部ネットワークへのアクセスや情報取得につながる可能性があります。また、ファイルアップロード/ダウンロード機能がある場合は、危険なファイルの混入やパストラバーサルによる情報漏えいなど、攻撃の入口になりやすい要素が揃っています。利便性の高い機能ほどリスクも増えやすいため、仕様として存在するなら“重点確認対象”として扱うのが安全です。

    情報露出・認証の欠如

    最後に、見落とし厳禁として挙げたいのが「情報露出」と「認証欠如」です。機密情報の露出は、単体でも重大な事故ですが、攻撃者にとっては次の攻撃を成立させるための材料にもなります。APIレスポンスの過剰返却やエラーメッセージの出し方など、“つい残ってしまう情報”が原因になることも少なくありません。また、重要機能の認証欠如は、成立すると攻撃者がログインすらせずに機能を悪用できてしまいます。管理用のエンドポイントや運用機能など、「利用者が限られるから大丈夫」と思われがちな部分ほど抜けが起きやすいため、公開前後での棚卸しが重要です。

    Web/APIは定期診断が有効

    Web/APIは機能追加や仕様変更が多く、開発時点で対策していたとしても、改修のたびに新しい抜けが生まれる可能性があります。だからこそ、開発段階での対策に加えて、第三者視点の脆弱性診断で「実際に攻撃が成立するか」を確認し、優先度を付けて改善することが効果的です。定期的に診断を実施することで、仕様変更による取りこぼしを早期に発見し、インシデントを未然に防ぐことにつながります。

    後編では、CWE Top 25 2025年版で目立つもう一つのポイントとして、メモリ領域の安全に関わる脆弱性が上位に増えている背景を整理します。なぜ今メモリ系が注目されているのか、どのように備えるべきかを、診断・運用の観点も含めて解説します。


    ―後編に続く―

    BBSecでは

    「どこが危ないのか」を把握しないまま対策を進めると、重要な弱点が残ったり、修正の手戻りが増えたりすることがあります。Webアプリケーション/APIの脆弱性診断により、実際に攻撃が成立するポイントを洗い出し、優先度を付けて改善につなげることが可能です。まずは現状の課題や診断範囲について、お気軽にご相談ください。


    限定キャンペーン実施中!

    今なら新規お申込みで 初回診断料金 10%OFF
    短期間での診断が可能な「SQAT® with Swift Delivery」で、あなたの企業をサイバー脅威から守りませんか?

    詳細・お申し込みボタン

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像

    プログラミング言語の脆弱性対策を考える

    Share

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る

    プログラミング言語のセキュリティは、組織のシステム全体のセキュリティに大きな影響を与えます。「アプリケーションの脆弱性の半数はC/C++に起因する」という報告もあり、プログラミング言語における脆弱性の特徴を理解し、適切な対策を講じることは、いまや組織のセキュリティに不可欠な取り組みといえます。本記事では、プログラミング言語の最新動向、脆弱性が生まれる背景を解説します。

    プログラミング言語のトレンド

    言語 使用している
    開発者の比率
    JavaScript69.7%
    HTML/CSS 62.4%
    SQL 56.9%
    Python 41.6%
    Java 38.4%
    Bash/Shell/PowerShell 34.8%
    C# 32.3%
    TypeScript 28.3%
    PHP 25.8%
    C++20.5%
    C 18.2%
    Go 9.4%
    Kotlin8.0%
    言語 使用している
    開発者の比率
    Ruby7.5%
    VBA6.2%
    Swift6.1%
    R5.5%
    Assembly4.9%
    Rust4.8%
    Objective-C4.4%
    Scala3.9%
    Dart3.7%
    Perl3.3%
    Haskell1.8%
    Julia0.9%

    Stack Overflow Developer Survey 2020 より弊社作成
    https://insights.stackoverflow.com/survey/2020#technology-programming-scripting-and-markup-languages-professional-developers

    JavaScript、HTML/CSS、SQLなどが上位に並んでいますが、皆さんの予想どおりでしょうか?ちなみに冒頭で述べた、「脆弱性の半数」を生み出すとされるC/C++に関しては、昨今IoTデバイスなどの組込機器やデスクトップアプリケーション等に利用目的が収れんしてきているといわれ、その使用率は減少傾向にあります。また、リストには記載がありませんが、日本に限ってみると、COBOLなどのレガシーシステム向けの言語がいまだ根強いシェアを保っているのはご存じの方も多いことでしょう。

    なお、弊社での診断傾向としては、JavaScriptのほか、Pythonが目立っています。今後については、「オーバーヘッドが少なく、静的型付け言語である」という特徴をもつTypeScriptなどが、軽量さの望まれるサーバレス環境での需要につながるものとみられます。また、Android端末向けにKotlinの需要も高まると予測しています。以下、ご参考に、プログラミング言語と主な利用分野のマッピングを示します。

    図:主要プログラミング言語と現在利用されている代表的分野

    プログラミング言語の脆弱性 ― 言語ごとに異なる特徴を知る

    プログラミング言語の脆弱性を考える場合、特定の言語に固有のものと、言語間で共通のものを押さえておく必要があります。

    例えば、C/C++では、その脆弱性の7割がメモリハンドリングのミスに起因するといわれており、メモリ関連処理のロジックを正しく制御させ、ソースコード内に脆弱性を作りこまないようにすることが、重要なセキュリティ対策となります。そのほか、言語固有の脆弱性として代表的なものは、Javaでの「安全でない入力に対するデシリアライゼーション」の問題、JavaScriptでの「パストラバーサル」や「暗号」の問題、PHPでの「クロスサイトスクリプティング(XSS)」や「SQLインジェクション」などになります。

    なお、2000年代後半以降にリリース開始された比較的新しいプログラミング言語(Kotlin、Golang、Rustなど)については、上記とは若干が異なる観点からの注意が必要です。まず、こうした言語では、セキュアコーディングのための様々な関数やライブラリなどが用意され、セキュリティに関する手厚い対策が組み込まれているのですが、その一方で、セキュリティの機能が増えれば増えるほど関連ドキュメントが膨大になり、把握が追いつかないという課題が生じています。例えば、Kotlinの場合、Kotlin自体のドキュメンテーションではセキュリティ関連の記述はNULLの安全性に触れる程度なのですが、セキュアコーディングに取り組もうとすると、膨大なAndroid Developer Guideを参照する必要があります。また、相互運用性への配慮も必要です。例えばKotlinやGolangはJavaと一緒に利用するケースが多いため、こうした言語で開発を行う場合には、Java側の環境を考慮したうえでのセキュアコーディングが不可欠になり、それが開発の難易度を押し上げているという状況があります。

    プログラミング言語の脆弱性 ― 全言語に共通の特徴を知る

    続いては、すべての言語に共通する脆弱性です。これは大きく以下の3つに分類できます。

    情報漏洩
    ・表示する必要のない機微な情報(ユーザ名やIDなど)の露呈
    ・不要なシステム情報の公開
    入力検証の不備
    ・不正なパラメータの許容、XSS、SQLインジェクション
    ・HTTPヘッダ分割
    認可・認証関連の脆弱性
    ・オブジェクトやファイルなどへのアクセス認可の不備
    ・認証情報の保護機構や暗号化の不備

    脆弱性が発生する背景

    以上述べてきたような脆弱性は、なぜ発生するのでしょう。その背景には、開発現場における以下のような課題があると考えられます。

    ・プロジェクトベースで人員が変わることが多く、知識や経験の共有が行われることがまれ
    ・脆弱性やセキュアコーディングに対する意識、知識レベルがプログラマによって異なる
    ・ギリギリのスケジュールでプロジェクトが進むことが多く、知識や経験の共有まで手が回らない
    ・セキュリティへの対応が明示的な業務として遂行されるのではなく、プログラマやプロジェクトメンバー1人1人の善意に依存する面が強い

    具体例で説明しましょう。先ほど、PHPではXSSやSQLインジェクション等の脆弱性がよく見られると述べました。しかし、PHPでも、バージョン4以降であれば「htmlspecialcharacters」という関数を利用することでXSSの回避に必要な特殊文字のエスケープ処理ができます。SQLインジェクションについても、プレースホルダの利用による回避が可能です。このように、すでに対策が存在する場合であっても、プログラマ間で知識や経験の共有が行われていない場合、ソースコード診断やステージング環境でのWebアプリケーション脆弱性診断が実施されない限り、脆弱性は放置されることになります。また、「機微な情報の露呈」という問題については、個人情報保護などの法制度に対する知識が共有されておらず、そもそも課題として認識されていないという可能性があります。なお、知識共有のハードルは、セキュリティ機能が充実しているゆえに把握すべき情報量が膨大で、他の言語との互換性等まで含めた配慮が求められる最近のプログラミング言語では、さらに高いといえるでしょう。

    こうした課題を解決するには、プログラマ個人の知識・技術レベルを高めることはもちろんですが、それ以上に重要なのは、組織を挙げての体系的な取り組みであるといえます。

    先手を打った対処がカギ

    そこでぜひ取り入れたいのが、プログラミング言語に関わる脆弱性が生じていないかを、開発の初期段階から継続的に点検する取り組みです。これは「DevSecOps」とも呼ばれる考え方で、「開発(Dev)」・「運用(Ops)」に「セキュリティ(Sec)」の観点を組み込むことで、システムのセキュリティ強化を図るものです。開発プロジェクトは常に時間との闘いですが、だからといって脆弱性への対応を先送りしてはなりません。対処が事後になればなるほど、影響範囲が広がり、コストも肥大する恐れがあります。

    以前の記事でも解説しましたが、何よりも、初期段階からの取り組みが重要です。例えば、人員の流動が激しいプロジェクトベースの現場では、開発の早期からソースコード診断を含むテスト活動を実施し、脆弱性をコード単位で効率的に解消していくことによって、各段階で積み上げられた知識や経験を、後続の工程で活用することが可能になります。また、近年主流になっているアジャイル型の開発手法でもこれは有効で、短い開発サイクルが繰り返される中で早期に・こまめにテストや修正を行うようにすることで、セキュリティを強化できるのみならず、プロジェクト全体の工数も抑制できます。なお、短いサイクルでテストを回すには、SaaSタイプのソースコード診断サービスの利用を検討してもよいでしょう。

    先手を打って脆弱性に対処できれば、脆弱性の要因となっていた様々な課題に取り組む余裕も生まれます。結果として、セキュリティと開発効率をともに高められる好循環を実現できるのではないでしょうか。

    Security NEWS TOPに戻る
    バックナンバー TOPに戻る


    資料ダウンロードボタン
    年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。
    お問い合わせボタン
    サービスに関する疑問や質問はこちらからお気軽にお問合せください。

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    セキュリティトピックス動画申し込みページリンクへのバナー画像