今すぐ対応を!Citrix Bleed2(CVE-2025-5777)の脆弱性情報まとめ

Share

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

米サイバーセキュリティ・社会基盤安全保障庁(以下CISA)は2025年7月10日、Known Exploited Vulnerability(KEV)カタログ*1(悪用が確認された脆弱性のカタログ)にCitrix NetScaler ADCおよびNetScaler Gatewayの脆弱性であるCVE-2025-5777を追加、更新しました。本脆弱性は本年6月17日に公開されたメモリ境界外読み取りの脆弱性となり、Webセッションのトークンの奪取が可能となる脆弱性となります。

2026年3月、CitrixBleed 3(CVE-2026-3055)の脆弱性が新たに公開されました。こちらの脆弱性については以下の記事でご紹介しています。
CitrixBleed 3(CVE-2026-3055)の脆弱性:NetScaler ADC / Gatewayの影響・リスク・対策

NetScaler ADC/NetScaler Gatewayの脆弱性

NetScaler ADCはアプリケーションベースでの配信パフォーマンスの最適化やWAFの役割を果たすアプライアンスです。NetScaler Gatewayは社内および社内で使用しているSaaSなどへの単一のゲートウェイとして機能し、シングルサインオン(SSO)などの機能を持つものとなっています。いずれもDMZ上に存在することから外部からのアクセスが可能なアセットの代表格であり、過去にも脆弱性が悪用されてきたものとなります。このため特に悪用への対応が急がれるアセットといえます。

CVE-2025-5777の対象バージョン

CVE-2025-5777の対象となるバージョンは以下の通りです。いずれも更新バージョンへのアップデートが推奨されています。いずれも更新バージョンへのアップデートが推奨されています。

製品バージョン対象のビルド
NetScaler ADCおよびNetScaler Gateway14.114.1-43.56未満
13.113.1.58.32未満
NetScaler ADC13.1-FIPSおよびNDcPP13.1-37.235未満
NetScaler ADC12.1-FIPS12.1-55.328未満

詳細については以下をご確認ください。

https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX693420

CVE-2025-6543の対象バージョン

なお、CVE-2025-5777の後に公開された、同じくKEVカタログに掲載されている脆弱性CVE-2025-6543の対象バージョンは以下の通りです。こちらも併せて対応されることをおすすめします。

製品バージョン対象のビルド
NetScaler ADCおよびNetScaler Gateway14.114.1-47.46未満
13.113.1.58.32未満
NetScaler ADC13.1-FIPSおよびNDcPP13.1-37.236未満

詳細については以下をご確認ください。

https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX694788
※CVE-2025-6543はNetScaler ADC 12.1-FIPSの対象外となっています。
※NetScaler ADCおよびNetScaler Gatewayの12.1と13.0はEOL(End of Life、サポート終了)となっており、アプライアンスをサポートされたバージョンにアップグレードすることが推奨されています。

なお、NetScalerを14.1 47.46または13.1 59.19にアップグレードした際に認証関連で問題が発生する可能性があることが公開されています。以下のナレッジベースの記事を参考までに掲載します。このほかにも冗長構成でのアップデートについては注意が必要となります。詳しくはご購入された販売代理店のサポート窓口やCitrixまでご相談ください。

https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX694826

SQAT.jpではKEV Catalogについて以下の記事でも取り上げています。ぜひあわせてご参照ください。
2024年のサイバーセキュリティ振り返り-KEVカタログが示す脆弱性の実態- | SQAT®.jp
2025年Q1のKEVカタログ掲載CVEの統計と分析 | SQAT®.jp

CVE-2025-5777(Citrix Bleed2)の脆弱性の概要とリスク

  • リモートから認証なしで悪用可能
  • 2023年に公開され、のちに悪用が確認された同様の脆弱性・Citrix Bleed(CVE-2023-4966)と同様にメモリ境界外読み取りの脆弱性であり、Citrix Bleed2と名付けられている
  • 複数のセキュリティ企業から脆弱性公開後、脆弱性の再現などを含む分析や侵害に関する情報が公開されている
    ただしCitrixは公に侵害事例や攻撃兆候について認めていない(日本時間2025年7月11日正午時点)

脆弱性公開からKEVカタログ掲載までの時系列まとめ

日付経緯
2025年6月17日CitrixによるCVE-2025-5777の公開
2025年6月20日Reliaquestによる侵害事例の公開
2025年6月24日セキュリティ研究者によるCVE-2023-4966との類似性の指摘を含む注意喚起
2025年6月25日CitrixによるCVE-2025-6543とCVE-2025-6543の悪用兆候の公開
2025年6月26日CitrixによるCVE-2023-4966との類似性の指摘の否定・CVE-2025-5777の悪用の否定
2025年7月4日Watchtowrによる再現と原因分析、注意喚起を含む情報の公開
2025年7月7日Horizon3.aiによる、同時に修正・公開された脆弱性を含む分析、注意喚起を含む情報の公開
2025年7月9日Health-ISACが公開PoCの存在を根拠とする脅威情報の注意喚起を公開
2025年7月10日CISAがKEVカタログにCVE-2025-5777を追加

【参考情報】

Citrixからの情報

  • CVE-2025-5777関連:https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX693420
  • CVE-2025-6543関連:https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX694788
  • アップデート時の認証関連の問題:https://support.citrix.com/support-home/kbsearch/article?articleNumber=CTX694826
  • ブログ

  • https://www.netscaler.com/blog/news/critical-security-updates-for-netscaler-netscaler-gateway-and-netscaler-console/
  • https://www.netscaler.com/blog/news/critical-severity-update-announced-for-netscaler-gateway-and-netscaler/
  • https://www.netscaler.com/blog/news/netscaler-critical-security-updates-for-cve-2025-6543-and-cve-2025-5777/
  • セキュリティ各社・研究者による分析および侵害事例報告

  • https://reliaquest.com/blog/threat-spotlight-citrix-bleed-2-vulnerability-in-netscaler-adc-gateway-devices/
  • https://doublepulsar.com/citrixbleed-2-electric-boogaloo-cve-2025-5777-c7f5e349d206
  • https://labs.watchtowr.com/how-much-more-must-we-bleed-citrix-netscaler-memory-disclosure-citrixbleed-2-cve-2025-5777/
  • https://horizon3.ai/attack-research/attack-blogs/cve-2025-5777-citrixbleed-2-write-up-maybe/
  • Health-ISACの注意喚起(American Hospital Associationから配信されたもの)

  • https://www.aha.org/system/files/media/file/2025/07/h-isac-tlp-white-threat-bulletin-poc-exploits-available-for-citrix-netscaler-adc-and-netscaler-gateway-flaw-cve-2025-5777-7-9-2025.pdf
  • BBSecでは

    当社では様々なご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

    アタックサーフェス調査バナー
    ペネトレーションテストバナー

    公開日:2025年7月14日
    更新日:2026年4月22日

    編集責任:木下

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

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

  • 2026年5月13日(水)13:00~14:00【好評アンコール配信】
    攻撃は本当に成立するのか?ペネトレーションテストで検証する実践的セキュリティ対策(デモ解説)
  • 2026年5月20日(水)14:00~15:30 <BBSec/Future/ハンモック共催>
    脆弱性管理の最適解 ― ASM・IT資産管理・脆弱性管理を分けて考え、統合するという選択
  • 2026年5月27日(水)14:00~15:00
    ~取引先から求められる前に押さえる~ SCS評価制度への対応準備と現実的な進め方
  • 最新情報はこちら


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

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

    CitrixBleed 3(CVE-2026-3055)の脆弱性:NetScaler ADC / Gatewayの影響・リスク・対策

    Share
    CitrixBleed 3(CVE-2026-3055)の脆弱性:NetScaler ADC / Gatewayの影響・リスク・対策アイキャッチ画像

    CVE-2026-3055が注目される背景(CitrixBleedとの関連)

    2026年3月、Cloud Software Groupは、Citrix NetScaler ADCおよびNetScaler Gatewayに関する複数の脆弱性情報を公表しました*2。その中でも特に注意が必要なのが、CVE-2026-3055です。

    CVE-2026-3055は、NetScaler ADCおよびNetScaler GatewayがSAML IDPとして構成されている場合に影響を受ける、入力検証不備に起因するメモリオーバーリードの脆弱性です。Citrix公式アドバイザリでは、CWE-125、CVSS v4.0のベーススコア9.3Criticalとして評価されています。本脆弱性は、通称「CitrixBleed 3」と呼ばれています。JPCERT/CCは、過去に大きな問題となったCitrix Bleed系の脆弱性、CVE-2023-4966CVE-2025-5777との類似点が海外セキュリティ企業によって指摘されていると説明しています*2

    2025年7月に公表されたCitrix Bleed2(CVE-2025-5777)の脆弱性については以下の記事でご紹介しています。こちらもあわせてご覧ください。
    今すぐ対応を!Citrix Bleed2(CVE-2025-5777)の脆弱性情報まとめ

    企業にとって重要なのは、この脆弱性が単なる製品不具合ではなく、外部公開されている認証基盤やリモートアクセス基盤から情報漏洩につながる可能性がある点です。NetScaler GatewayはVPNやリモートアクセス、SSO連携の前段に置かれることが多く、侵害された場合の影響が社内ネットワーク全体に及ぶおそれがあります。

    CVE-2026-3055の概要

    CVE-2026-3055は、NetScaler ADCおよびNetScaler Gatewayにおけるメモリオーバーリードの脆弱性です。NVD(National Vulnerability Database)では、NetScaler ADCおよびNetScaler GatewayがSAML IDPとして構成されている場合、不十分な入力検証によりメモリオーバーリードが発生すると説明されています*3

    メモリオーバーリードとは、本来読み取るべきではないメモリ領域のデータが読み取られてしまう問題です。JPCERT/CCは、CVE-2026-3055について、遠隔の第三者によって意図しないメモリ領域のデータが読み取られる可能性があると注意喚起しています。この種の脆弱性で問題になるのは、攻撃者が直接ファイルを盗み出さなくても、メモリ上に一時的に残っていた情報が漏洩する可能性があることです。NetScalerのような認証や通信制御に関わる装置では、セッション情報、認証処理に関係する情報、SAML連携に関する情報などがメモリ上で扱われるため、情報漏洩の影響を慎重に評価する必要があります。

    影響を受ける製品とバージョン

    CVE-2026-3055の影響を受けるのは、NetScaler ADCおよびNetScaler Gatewayの一部バージョンです。Citrix公式アドバイザリでは、NetScaler ADCおよびNetScaler Gateway 14.1の14.1-60.58より前、13.1の13.1-62.23より前、NetScaler ADC FIPSおよびNDcPPの13.1-37.262より前が影響を受けるとされています。

    ただし、バージョンだけでなく構成条件も重要です。Citrix公式は、CVE-2026-3055について、Citrix ADCまたはCitrix GatewayがSAML IDP Profileとして構成されていることを前提条件として示しています。確認方法として、NetScalerの設定内に “add authentication samlIdPProfile .*” が存在するかを確認するよう案内しています。つまり、NetScalerを利用しているすべての環境が同じ条件で影響を受けるわけではありません。しかし、SAML IDPはSSOや認証連携に関わる重要な構成で使われるため、該当する場合は優先度を上げて確認すべきです。

    CVE-2026-3055はKEVカタログ登録済みの脆弱性

    CVE-2026-3055は、すでに米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)のKEVカタログ(Known Exploited Vulnerabilities Catalog)に追加されています。NVD上でも、CVE-2026-3055がCISA KEVに登録されていること、追加日が2026年3月30日であること、米国連邦政府機関向けの対応期限が2026年4月2日であることが確認できます。KEVカタログへの追加は、少なくともCISAが既知の悪用済脆弱性として扱っていることを意味します。そのため、CVE-2026-3055は「将来的に悪用されるかもしれない脆弱性」ではなく、実際の攻撃リスクを前提として対応すべき脆弱性です。

    JPCERT/CCも、2026年3月31日時点で海外セキュリティ企業から悪用に関する観測情報や詳細な技術情報が公表されていると説明しています。 公開インターネット上にNetScaler ADCやNetScaler Gatewayを設置している企業は、すでに攻撃対象として探索されている可能性を考慮する必要があります。

    CVE-2026-3055が「CitrixBleed 3」と呼ばれる理由

    CVE-2026-3055は、正式名称として「CitrixBleed 3」と命名されているわけではありません。しかし、セキュリティ業界では、過去に大きな影響を与えたCitrix Bleed系の脆弱性との類似性から、このように呼ばれることがあります。過去のCitrix Bleedでは、NetScaler ADCやNetScaler Gatewayにおける情報漏洩が問題となり、認証情報やセッション情報の悪用が懸念されました。今回のCVE-2026-3055も、NetScaler製品におけるメモリ読み取りの問題であり、境界装置から情報が漏えいする可能性があるという点で、過去のCitrix Bleed系の問題を想起させます。JPCERT/CCも、CVE-2023-4966およびCVE-2025-5777との類似点が指摘されているとしています。

    企業のセキュリティ担当者がこの名称に注意すべき理由は、名前そのものではなく、攻撃者が狙いやすい外部公開機器で、認証に関わる情報が漏洩する可能性があるという構図です。これは、ランサムウェア攻撃や標的型攻撃の初期侵入経路として悪用されるリスクを高めます。

    悪用された場合のリスク

    CVE-2026-3055を悪用された場合、最も懸念されるのは、NetScalerのメモリ上に存在する情報が第三者に読み取られることです。JPCERT/CCは、遠隔の第三者によって意図しないメモリ領域のデータが読み取られる可能性があると説明しています。

    NetScalerは、社外から社内システムへアクセスする際の入口として利用されることがあります。SSL VPN、リモートアクセス、SSO、認証連携の前段に配置されることも多く、ここで情報漏えいが発生すると、単一システムの問題にとどまらず、社内ネットワークへの不正アクセスやアカウント悪用につながる可能性があります。

    特に注意すべきなのは、パッチ適用だけでリスクが完全に消えるとは限らない点です。メモリ情報漏えい型の脆弱性では、修正前に何らかの情報が読み取られていた場合、その情報が後から悪用される可能性を否定できません。そのため、アップデートとあわせて、ログ調査、セッションの無効化、認証情報の見直し、関連アカウントの監視を実施することが重要です。

    企業がまず確認すべきポイント

    CVE-2026-3055への対応では、まず自社がNetScaler ADCまたはNetScaler Gatewayを利用しているかを確認する必要があります。特に、VPN、リモートアクセス、SSO、認証連携、社外公開システムの前段にNetScalerが配置されていないかを確認することが重要です。

    次に、対象バージョンに該当するかを確認します。Citrix公式アドバイザリでは、NetScaler ADCおよびNetScaler Gateway 14.1の14.1-60.58より前、13.1の13.1-62.23より前、NetScaler ADC FIPSおよびNDcPPの13.1-37.262より前がCVE-2026-3055の影響を受けるとされています。

    さらに、SAML IDPとして構成されているかを確認します。Citrix公式は、NetScaler Configuration内に”add authentication samlIdPProfile .* ”が存在するかを確認するよう案内しています。 この設定が存在する場合、CVE-2026-3055の影響を受ける条件に該当する可能性があります。

    対応方針:アップデートが最優先

    CVE-2026-3055について、JPCERT/CCは、Cloud Software Groupが本脆弱性に対する回避策を提供していないと説明しています。 そのため、アクセス制限や監視強化だけで対応を完了させるのではなく、修正済みバージョンへのアップグレードを基本方針とすべきです。Citrix公式アドバイザリでも、影響を受ける顧客に対して、関連する更新済みバージョンをできるだけ早くインストールするよう強く推奨しています。 本番環境では検証や切り戻し計画が必要になる場合がありますが、KEVカタログに登録されていることを踏まえると、通常の月次パッチ対応よりも高い優先度で扱うべき脆弱性です。

    侵害有無の確認方法

    CVE-2026-3055では、パッチ適用と同時に侵害有無の確認も重要です。JPCERT/CCは、watchTowr Labsの情報として、CVE-2026-3055を悪用する攻撃の試行は、/saml/login への細工したPOSTリクエストや、/wsfed/passive?wctx へのGETリクエストによって行われると紹介しています。通常運用で想定されない送信元IPから、これらのエンドポイントへのアクセスがログに記録されていないか確認することが推奨されています。また、JPCERT/CCは、DEBUGレベルのログを有効化している場合、/var/log/ns.log に意図しない文字列が挿入される点もwatchTowr Labsが指摘していると説明しています。 侵害が疑われる場合は、ログの保全、関係者への報告、メーカーや専門事業者への相談を検討すべきです。重要なのは、「アップデートしたから終わり」としないことです。すでに攻撃を受けていた場合、攻撃者が取得した可能性のある情報を前提に、セッションの無効化や認証情報の更新、管理者アカウントの確認、異常なログイン履歴の調査を進める必要があります。

    なぜ境界装置は狙われるのか

    近年、VPN装置、ADC、認証ゲートウェイ、ファイル転送装置など、インターネット境界に置かれる機器の脆弱性が繰り返し悪用されています。これらの機器は社内ネットワークへの入口に位置し、多くの場合、認証情報やセッション情報、社内システムへのアクセス経路を扱います。攻撃者にとっては、境界装置の侵害が効率のよい初期侵入手段となります。一般的な端末を一台ずつ狙うよりも、外部公開された認証基盤やリモートアクセス装置を突破する方が、社内環境へ到達しやすい場合があるためです。CVE-2026-3055は、まさにこの文脈で捉える必要があります。NetScaler ADCやNetScaler Gatewayを導入している企業は、単に脆弱なバージョンを更新するだけではなく、外部公開資産の棚卸し、設定確認、ログ監視、脆弱性情報の継続的な収集を組み合わせて対応する必要があります。

    脆弱性管理で求められる実務対応

    CVE-2026-3055のような重大なリスクレベルの脆弱性に対応するには、まず資産を把握していることが前提になります。どの拠点、どのクラウド環境、どのネットワーク境界にNetScalerが存在するのかを把握できていなければ、脆弱性情報が公開されても迅速に判断できません。また脆弱性の深刻度だけでなく、自社環境での露出状況を評価する必要があります。CVE-2026-3055はCVSS v4.0で9.3のCriticalと評価されていますが、実務上は、インターネットから到達可能か、SAML IDPとして構成されているか、認証基盤としてどの範囲に影響するかを確認することが重要です。さらに、KEVカタログへの登録の有無も優先順位付けの重要な判断材料になります。CVE-2026-3055はKEVカタログへ登録済みであり、NVD上でもその情報が確認できます。 既知悪用脆弱性に該当する場合、通常の脆弱性対応よりも優先度を上げ、短期間での対応計画を立てるべきでしょう。

    この脆弱性から学ぶべきポイント

    CVE-2026-3055は、個別の製品脆弱性であると同時に、企業の脆弱性管理体制を見直すきっかけにもなります。特に、VPNや認証ゲートウェイのような外部公開機器は、業務継続に不可欠である一方、攻撃者にとっても魅力的な標的です。今後も、境界装置や認証基盤に関する脆弱性は継続的に公表されると考えられます。そのたびに場当たり的に対応するのではなく、外部公開資産の一覧化、バージョン管理、設定管理、ログ監視、緊急パッチ適用の判断基準をあらかじめ整備しておくことが求められます。特に、情シス部門やセキュリティ担当者が少人数で運用している企業では、脆弱性情報の収集、影響調査、優先順位付け、パッチ適用、侵害調査をすべて自社だけで行うことが難しい場合があります。その場合は、外部診断やセキュリティ監視サービス、インシデント対応支援を組み合わせ、重要な境界装置を継続的に確認できる体制を整えることが現実的です。

    まとめ:CVE-2026-3055への対応ポイント

    CVE-2026-3055は、NetScaler ADCおよびNetScaler GatewayがSAML IDPとして構成されている場合に影響を受ける、メモリオーバーリードの重大脆弱性です。この脆弱性の本質は、NetScalerという外部公開されやすい認証・通信制御基盤から、意図しないメモリ領域のデータが読み取られる可能性がある点にあります。企業は、NetScaler ADC / Gatewayの利用有無、対象バージョン、SAML IDP構成の有無を確認し、該当する場合は修正版へのアップグレードを速やかに進める必要があります。あわせて、/saml/login/wsfed/passive?wctxへの不審なアクセスの有無を確認し、侵害が疑われる場合はログ保全と専門的な調査を行うことが重要です。

    CVE-2026-3055は、単なる一製品の脆弱性ではなく、外部公開資産と認証基盤の管理が企業のセキュリティに直結することを示す事例です。脆弱性管理は、パッチを当てる作業だけではありません。資産を把握し、影響を判断し、優先順位を付け、侵害有無まで確認する一連の運用として整備することが、今後ますます重要になるでしょう。

    【参考情報】


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

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

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

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

  • 2026年5月13日(水)13:00~14:00【好評アンコール配信】
    攻撃は本当に成立するのか?ペネトレーションテストで検証する実践的セキュリティ対策(デモ解説)
  • 2026年5月20日(水)14:00~15:30 <BBSec/Future/ハンモック共催>
    脆弱性管理の最適解 ― ASM・IT資産管理・脆弱性管理を分けて考え、統合するという選択
  • 2026年5月27日(水)14:00~15:00
    ~取引先から求められる前に押さえる~ SCS評価制度への対応準備と現実的な進め方
  • 最新情報はこちら

    編集責任:木下

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


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

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

    IPA情報セキュリティ10大脅威2026にみる、AI時代のサイバーリスク

    Share
    「IPA情報セキュリティ10大脅威 2026に見る、AI時代のサイバーリスク」アイキャッチ画像

    近年、生成AIをはじめとするAI技術の進展により、組織におけるAIの活用は急速に広がっています。本記事では、IPA「情報セキュリティ10大脅威 2026」の内容をもとに、AIの利用をめぐるサイバーリスクについて整理するとともに、企業に求められる対応の方向性について解説します。

    IPA「情報セキュリティ10大脅威」速報版の記事はこちら。「AIの利用をめぐるサイバーリスク」以外の脅威の項目についても知りたい方は、こちらもぜひあわせてご覧ください。
    【速報版】情報セキュリティ10大脅威 2026 -脅威と対策を解説-

    はじめに

    業務効率の向上や新たな価値創出の手段として、多くの企業がAIの導入を進めています。一方でAI利用に伴うリスクについても、十分な注意が求められています。こうした状況を反映して、IPA(独立行政法人情報処理推進機構)が公表した「情報セキュリティ10大脅威 2026」において、「AIの利用をめぐるサイバーリスク」という脅威が初めてランクインし、3位に位置付けられました。

    なぜいま「AIの利用」が脅威として注目されるのか

    IPA「情報セキュリティ10大脅威」は、前年に発生した社会的影響の大きい事案等をもとに選定されたものであり、順位は単純に危険度の高さを示すものではありません。しかし、AI利用に関するリスクが新たに選出されたことは、企業や組織におけるAI活用の拡大と、それに伴う課題の顕在化を示すものといえるでしょう。

    2026年3月12日に公開された、IPA「情報セキュリティ10大脅威 2026」解説書では、AIは有用なツールである一方で、十分な理解がないまま利用した場合、情報漏洩や権利侵害といった問題につながる可能性があると指摘されています。特に、生成AIへの入力内容が外部に取り扱われることによる機密情報の漏洩や、生成された情報の正確性を確認せずに業務に利用することによって発生するトラブルなど、従来の情報システム利用とは異なる観点でのリスクが挙げられています。 また、AIは利用者の裾野が広く、専門的な知識がなくても活用できるという特性を持っています。そのため、組織として利用状況を把握しきれないまま、個人単位で業務利用が進むケースも想定されます。このような利用形態は、管理の行き届かないリスク、いわゆるシャドーITに類似した問題を引き起こす可能性があります。

    AI利用をめぐる主なリスク

    IPAはAIの利用拡大に伴い、いくつかの代表的なリスクが指摘しています。これらは、AIの技術そのものというよりも、その利用方法や特性に起因するものが多い点が特徴です。

    • 情報漏洩リスク
    • 誤情報生成リスク(ハルシネーション)
    • サイバー攻撃の高度化リスク
    • 利用実態の把握困難(シャドーAI)
    • 権利侵害リスク

    生成AIへの入力内容に起因する情報漏洩

    クラウドサービスとして提供されるAIに対し、機密情報を入力することで、意図せず外部に情報が送信される可能性があるというリスクです。

    AIの出力結果に関するリスク

    対話型AIは実在しない情報を生成する(=ハルシネーション)場合があり、このことを十分に理解せずに利用すると、誤った判断や誤情報発信につながるおそれがあります。

    AIの悪用によるサイバー攻撃の高度化

    AIを活用することで、攻撃の効率化や手口の巧妙化が進む可能性があります。さらに、組織における利用実態の把握が難しい点も重要なリスクです。

    シャドーAIのリスク

    個人単位でAIサービスを利用されてしまうことで、組織の目の届かない範囲での利用が発生する可能性があります。

    著作権侵害などの権利問題

    AIの利用に関する理解不足により、著作権侵害などの権利問題が生じる可能性も指摘されています。

    AI利用において想定される主な事例

    AI利用に伴うリスクは、特別な環境でのみ発生するものではなく、日常業務の中で自然に発生し得るものです。例えば業務の効率化を目的として、従業員が個人で利用している生成AIサービスを業務に活用するケースが考えられます。メール文面の作成や資料作成の補助としてAIを利用する延長で、社内資料の内容や顧客情報をそのまま入力してしまうことがありえます。生成AIはクラウド上で動作しており、入力した内容はサービス側で処理されます。場合によっては、入力内容がサービスの改善や学習に利用されることもありえます。この点を十分に理解しないまま利用すると、機密情報を外部サービスに送信してしまうことになり、情報漏洩につながるおそれがあるのです。

    また、対話型AIの回答をそのまま精査せずに業務に利用してしまうことで問題に発展する可能性もあります。調査や資料作成の過程でAIが生成した情報を十分に確認せずに利用した結果、ハルシネーションの内容を含んだまま社内外に共有してしまうといった事態が起こり得ます。このように、AI利用に伴うリスクは特定の専門領域に限らず、日常業務の延長線上で発生する点に特徴があります。

    組織における課題

    AIの利用が広がる一方で、組織としてこれらのリスクを適切に管理することにはいくつかの課題があります。

    社内でのAI利用の促進とルールの策定のバランス

    まず、AI利用に関するルールやガイドラインの整備が追いついていない点が挙げられます。現場での利用が先行する中で、組織としての利用方針が明確でない場合、統一的な管理が難しくなります。また、利用状況の把握が困難であることも大きな課題です。クラウド型のAIサービスは個人単位で容易に利用可能なため、組織として誰がどのように利用しているかを正確に把握することが難しくなります。実際には、想定以上に広範囲で利用が進んでいるケースも少なくありません。さらに、ポリシーを整備しても現場に浸透しないという課題もあります。AIは業務効率の向上に直結するため、利便性を優先してルールが守られないケースや、現場ごとに独自の運用が行われるといった状況も発生し得ます。加えて、AI利用と既存のセキュリティ対策との間にギャップが生じる点も課題です。従来のセキュリティ対策は想定していなかった利用形態が増えることで、管理や統制が追いつかない場面が生じる可能性があります。さらに、利用者への教育不足も課題の一つです。AIの特性やリスクに関する教育や周知が十分でないために、組織として意図しない利用が広がり、統制が効かなくなるおそれがあります。

    このように、AIの活用においては、ルール整備や利用状況の把握といった基本的な対応に加え、実際の運用における課題も踏まえた継続的な対応が求められます。

    企業が取るべきアクション

    AIの利用に伴うリスクに対応するためには、個別の技術対策にとどまらず、組織としての管理と運用の整備が重要となります。AI利用に関しては、ルール整備や教育、基本的なセキュリティ対策の徹底といった観点での対応が求められています。

    1. AIの利用に関するルールやガイドラインの整備
      どのような用途でAIを利用してよいのか、入力してよい情報の範囲、利用してはならない行為などを明確に定めることで、利用に伴うリスクを一定程度抑制することが可能となります。
    2. 利用状況の把握と管理
      AIサービスは個人単位でも容易に利用できるため、組織としてどのように利用されているかを把握し、必要に応じて管理の対象とすることが重要です。これにより、管理の行き届かない利用、いわゆるシャドーAIの発生を抑制することが期待されます。
    3. AI利用者への教育
      AIの特性やリスクについて正しく理解させることで、生成結果の確認や適切な情報の取り扱いといった基本的な行動を促すことができます。技術的な制御だけでなく、利用者の理解を前提とした運用が不可欠です。
    4. 基本的なセキュリティ対策の徹底・見直し
      認証の適切な運用や情報管理の強化といった既存の対策は、AI利用においても引き続き基盤となるものです。その上で、AIの利用が業務に広く組み込まれる中では、従来の対策だけでは対応しきれない場面も想定されるため、AI利用を前提としたセキュリティの見直しや再設計が必要となる可能性もあります。

    このように、AIの安全な活用には、ルール、管理、教育、AIを前提とした基本的なセキュリティ対策といった複数の観点からの継続的な取り組みが重要です。

    AI時代に求められるセキュリティ支援

    こうした課題に対応するためには、組織単独での取り組みだけでなく、専門的な支援の活用も有効です。以下のようなセキュリティ支援の例が挙げられます。

    • セキュリティ診断・リスクアセスメント
      AI利用に伴うリスクを把握するためのセキュリティ診断やリスクアセスメントが重要となります。現状の利用状況や潜在的なリスクを可視化することで、適切な対策の検討につなげることができます。
    • 運用監視体制の強化
      AIの利用状況を継続的に監視し、問題の早期発見や対応を行う体制を整備することで、リスクの低減が期待されます。
    • AI利用ガイドライン策定支援
      組織の実態に即したルールを整備し、現場で実際に運用可能な形に落とし込むことが求められます。

    さいごに

    「情報セキュリティ10大脅威 2026」において、「AIの利用をめぐるサイバーリスク」が新たにランクインしたことは、AI活用の拡大と、それに伴う課題の顕在化を示すものといえます。AIに関するリスクは、新たな技術そのものに起因するというよりも、その利用方法や理解不足に起因する側面が大きい点が特徴です。そのため、対策としては、ルール整備や利用状況の把握、教育といった組織的な対応に加え、基本的なセキュリティ対策を継続して実施することが重要となります。

    また、IPAが示す通り、10大脅威の順位は危険度の高さを示すものではなく、自組織の状況に応じて適切にリスクを評価し、優先順位を定めて対策を講じることが求められます。 AIの活用は今後さらに進むことが想定されますが、その利便性を最大限に活かすためにも、リスクを正しく理解し、組織として適切に管理・運用していくことが重要です。


    【関連ウェビナーのご案内】
    本記事では、生成AIの利用に伴うサイバーリスクと、企業への影響について整理しました。AIの活用が進む一方で、情報漏えいや誤利用、統制の難しさといった課題が現実のものとなっています。では、こうしたリスクは実際にどのように悪用され、どのような攻撃として現れているのでしょうか。2026年4月15日に開催のウェビナーでは、生成AIを悪用した具体的な事例をもとに、サイバー脅威の実態と防御戦略を詳しく解説します。リスクの「背景」だけでなく、「実際に何が起きるのか」を理解したい方は、ぜひご参加ください。

    ウェビナー最新情報はこちら


    BBSecでは

    当社では様々なご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。当当サイトSQAT® jpのお問い合わせページよりお気軽にお問い合わせください。後日営業担当者よりご連絡させていただきます。

    SQAT® 脆弱性診断

    BBSecの脆弱性診断は、精度の高い手動診断と独自開発による自動診断を組み合わせ、悪意ある攻撃を受ける前にリスクを発見し、防御するための問題を特定します。Webアプリケーション、ネットワークはもちろんのこと、ソースコード診断やクラウドの設定に関する診断など、診断対象やご事情に応じて様々なメニューをご用意しております。

    SQAT脆弱性診断サービスバナー画像

    SQAT® ペネトレーションテスト

    「ペネトレーションテスト」では実際に攻撃者が侵入できるかどうかの確認を行うことが可能です。脆弱性診断で発見したリスクをもとに、実際に悪用可能かどうかを確認いたします。

    編集責任:木下

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


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

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像

    Claude Code流出問題の全体像 ―事件からわかるAI開発リスクとサプライチェーンリスク―

    Share
    「Claude Code流出問題の全体像 ―事件からわかるAI開発リスクとサプライチェーンリスク―」アイキャッチ画像

    はじめに

    「Claude Code」で起きたソースコード流出問題の経緯、なぜnpm公開物から内部ソースへ到達できたのか、何が漏れ、何が漏れていないのかを整理します。またソースコード流出によって浮き彫りになるAI開発リスクとソフトウェア供給網のリスクについても解説します。

    Claude Codeソースコード流出の概要

    「Claude Code」はAnthropic社が提供する公式のコーディング支援ツールです。Anthropicが公開している「Claude Code Doc」の中でも、Claude Codeはコードベース理解、ファイル編集、コマンド実行、各種開発ツール連携を行う製品として説明されています。

    Claude Code流出は、単なる「話題のAIニュース」では終わりません。今回、ターミナルやIDE(統合開発環境)からコード編集、コマンド実行、検索、Git操作まで担う実運用の開発基盤の中核にあたる実装の一部が、npm配布物に含まれたソースマップ(source map)を起点に外部から参照可能な状態になっていたことがわかりました。本事件はAIエージェント時代のソフトウェアサプライチェーン問題として捉える必要があります。

    流出の発端と技術的な経路(source map問題)

    本事件で最初に押さえるべきなのは、「Claude本体のモデル重みが漏れた」のではなく、「Claude Codeという周辺プロダクトのソースコードが到達可能になった」という点です。事件の発端となったのは、Chaofan Shou氏(@Fried_rice)によるXの投稿です。2026年3月31日、Chaofan Shou氏は「Claude code source code has been leaked via a map file in their npm registry」(訳:Claude Codeのソースコードが、npmレジストリ内のmapファイルを通じて流出した)と投稿しており、少なくとも現時点で公開されている初動情報の起点は、この発見報告にあると考えられます。

    その後に作成されたいくつかの公開GitHubリポジトリでは、漏洩経路について「npmパッケージに含まれたソースマップが、難読化前のTypeScriptソースを指しており、その参照先からsrc一式を取得できた」と説明しています。GitHubリポジトリ自体はAnthropicの公開情報ではないため、そこに書かれた全内容を鵜呑みにするべきではありませんが、少なくとも複数の公開Claude Artifacts(アーティファクト)が同じ経路を示していること、そして後述するAnthropic公式のGitHub上のIssueでも「流出またはデコンパイルされたClaude Codeのソースコード」を前提に議論が進んでいることから、ソースマップ起点として内部実装が可視化されたという大筋は相当に確度の高い情報だと言えます。さらに公開リポジトリのREADMEでは、「約1,900ファイル、51万行超のTypeScriptコードが露出した」と説明しています。

    流出した内容と影響範囲

    本事件が注目を集めた理由は、Claude Codeが単なるCLIラッパーではなく、幅広い機能群を内包したAI開発支援基盤であるためです。Anthropicの公開リポジトリと公式リリースノートを見るだけでも、Claude CodeにはIDE連携、MCP、プラグイン、履歴再開、権限管理、Web検索、各種設定や運用補助機能が継続的に追加されていることがわかります。また公開GitHubスナップショットREADMEでも、ツールシステム、コマンド群、IDEブリッジ、マルチエージェント協調、スキル、プラグイン、メモリやタスク管理など、多層的な構造が記述されています。

    つまり今回のClaude Code流出問題は、AIコーディング支援の表面だけでなく、その実装思想や運用機能の一端まで外から読める状態になったという意味を持ちます。

    何が漏れ、何が漏れていないのか

    Anthropic公式情報でも、Claude Codeの内部実装に関するソースコード断片や構成が公開状態になったことは裏づけられています。Anthropic公式GitHubのIssueでも、流出コードを前提とした解析が行われていました。

    Anthropicの公式GitHubリポジトリに2026年3月31日付で立てられたIssueでは、「source code isn’t publicly available, so this analysis is based on the leaked/decompiled Claude Code source」(訳:ソースコードは公開されていないため、本分析は流出またはデコンパイルされたClaude Codeのソースコードに基づく)と投稿され、Xでの発見報告とGitHub上の流出スナップショットを参照していたということがわかります。つまり、少なくともコミュニティ側では流出コードを参照した解析が現実に行われ、それがAnthropicの管理下のIssue空間にも持ち込まれていたということです。

    一方で、複数の報道機関によれば、「Anthropicが今回の件を「人為的ミス」によるものと認め、顧客データや認証情報、Claudeモデルそのものの重みは流出していない」と説明したとしていますが、この点は一次ソースではなく報道ベースの情報として慎重に扱う必要があります。

    なぜ深刻なのか:AIエージェント時代のリスク

    それでも、このClaude Codeソースコード流出が深刻なのは、顧客データ漏洩の有無だけでは影響範囲が測れないからです。AIエージェント製品では、モデル重みそのものに価値があるのはもちろんですが、実際の使い勝手や競争力は、その周囲にあるハーネス、権限管理、ツール呼び出し、コンテキスト処理、UI、IDE統合、再開機能、運用設計によって大きく左右されます。公開スナップショットにあるディレクトリ構成やコマンド一覧、サービス層の説明を見ると、Claude Codeがかなり成熟した「製品化されたAIエージェント」であることが読み取れます。競合や研究者にとって、こうした実装知見が外から見える状態になることの意味は小さくありません。

    特に重要なのは、Claude Codeが単にコードを生成するAIだけではなく、ローカル環境や周辺ツールに触れながら作業を進めるAIエージェントとして設計されている点です。漏洩したとされる公開スナップショットにも、Bash実行、ファイル読み書き、Web取得、Web検索、MCP、LSP、タスク作成、スケジュール実行などの機能が列挙されています。これは、今後のAIセキュリティを考える際に、モデル単体の安全性だけでは足りず、エージェントの実行基盤や配布パッケージの安全性まで視野に入れなければならないことを示しています。

    AIエージェント時代の新課題、Non Human Identity(NHI)のセキュリティ課題と今後のAIコーディングに求められる実践的な視点を解説した記事はこちら。ぜひあわせてご覧ください。
    AIコーディング入門 第5回:NHI(Non‑Human Identity)とAIエージェントのセキュリティ課題

    ビルド・配布プロセスにおける問題の本質

    さらに今回の一件は、ソースコード流出そのものだけでなく、公開物のビルド管理や配布管理の問題としても重要です。ソースマップ(source map)は本来、デバッグや解析のためには有用ですが、公開パッケージに不用意に含めれば、難読化やバンドルの前提を崩し、実装内部への入口になります。もしREADME記載どおり、ソースマップが外部ストレージ上の元ソース一式を指していたのであれば、問題は単なる「mapファイル混入」で終わりません。公開パッケージ、参照先URL、ストレージ公開設定、リリース工程のチェック体制まで含めた、供給網全体の設計ミスになります。ここにClaude Codeソースコード流出問題の本質があります。

    「影響は限定的」という見方の限界

    本事件をめぐる議論では、「どうせAIのコードはすぐ変わるから被害は限定的だ」という見方もあります。これは半分正しいです。たしかにプロダクトコードは日々更新されます。それでも、ある時点の設計方針、抽象化の仕方、権限制御、内部機能のつながり、未公開機能の痕跡は、競争戦略や攻撃面の理解に十分な価値を持ちます。現に公開スナップショットには、マルチエージェント協調、チーム作成、スキル実行、メモリ同期、リモートトリガーといった、単純なCLI以上の発想が読み取れる記述が含まれています。AI開発企業にとって、こうしたプロダクト実装の漏えいは、顧客情報漏えいとは別種の経営リスクです。

    企業が取るべき対応と実務上の教訓

    企業の情報セキュリティ担当者や開発責任者にとって、本事件から学ぶべき教訓は明確です。第一に、公開パッケージの中身を「本番ビルド成果物」だけでなく、「付随ファイル」まで含めて検査する必要があります。第二に、ソースマップやデバッグアーティファクトの扱いを、開発者の善意や慣習に任せてはいけません。第三に、クラウドストレージの参照先や署名URL、生成物の格納ルールを、CI/CDと一体で見直すべきです。第四に、AIエージェント製品では、モデルAPIの保護だけでなく、CLI、IDE拡張、SDK、プラグイン、MCP連携のような周辺面を含めてセキュリティレビューをかける必要があります。Claude Codeの公式リリースノートを見るだけでも、製品は短い周期で多機能化しており、変化の速さ自体がリスク管理を難しくしています。

    もう一つ重要なのは、事故後の透明性です。現時点で確認できるAnthropic公式情報は、Claude Codeの製品説明やリリースノートが中心で、今回のソースコード流出事件についての障害報告書は見当たりません。そのため、実務的には「発生原因」「影響範囲」「再発防止策」を公式にどこまで明文化するかが、今後の信頼回復を左右します。AI安全性を強く掲げる企業であればなおさら、モデル安全だけではなく、配布と運用の安全性でも説明責任が問われます。今回のClaude Codeのソースコード流出は、その現実を突きつけた出来事となります。

    まとめ

    Claude Codeソースコード流出事件はAI本体が破られた事件ではありませんが、AI製品はモデルだけ守ればよい、という幻想は崩されました。AIコーディング支援、AIエージェント、開発者向けCLI、IDE統合、MCP、プラグイン基盤といった要素が一体化した時代において、情報漏洩リスクはモデル重みだけでなく、配布物、周辺コード、実行制御、設定、公開ストレージにもまたがります。Claude Code流出事件を単なる興味本位の話題で終わらせるのではなく、現代のソフトウェアサプライチェーンの課題とAIプロダクト運用の脆さを示す事例として読むべきでしょう。

    参考文献


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

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

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

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

  • 2026年4月10日(水)14:00~15:00
    ランサムウェア時代のIT-BCP入門~サイバー攻撃によるシステム停止に備える実践的な策定ステップ~
  • 2026年4月15日(水)14:00~15:00
    AI時代のサイバー脅威最前線 ― IPA『情報セキュリティ10大脅威2026』から学ぶ防御戦略 ―
  • 2026年4月22日(水)14:00~15:00
    Swift CSCF v2026変更点解説セミナー ― Control 2.4 (Back Office Data Flow Security)の必須化とCustomer client connectorへの要件適用拡大 ―
  • 最新情報はこちら

    編集責任:木下

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


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

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

    Axiosのサプライチェーン攻撃とは何だったのか ―npm改ざんの経緯、影響範囲、企業が今すぐ確認すべき対応を解説―

    Share
    「Axiosのサプライチェーン攻撃とは何だったのか」アイキャッチ画像

    2026年3月31日、JavaScriptの代表的なHTTPクライアントであるAxiosで、深刻なサプライチェーン攻撃が確認されました。影響を受けたのはニュースメディアのAxiosではなく、npmで広く利用されているOSSライブラリのaxiosです。今回の事案は、単なる脆弱性公表ではありません。正規のメンテナー権限が侵害され、信頼されていたパッケージ自体がマルウェア配布の経路になった点に本質があります。JavaScriptライブラリ、npm、依存関係、CI/CD、開発端末という、現代のソフトウェア開発に欠かせない基盤がまとめて狙われた事例として、今後も長く参照される可能性があります。

    何が起きたか ―Axiosのnpmパッケージに不正版が公開

    Google Cloud Blogで公開された「North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack」によると、2026年3月31日00:21 世界標準時(UTC)から03:20 UTCの間に、axiosのnpm公開版のうち1.14.1と0.30.4へ悪意ある依存関係が混入しました。問題の依存関係はplain-crypto-jsで、これは通常のAxios機能に必要なものではなく、postinstallフックを通じてインストール時に自動実行されるよう細工されていました。つまり、影響を受けた環境では、アプリケーションがAxiosを使ったかどうかではなく、その版をnpm installした時点で不正コード実行の可能性が生じる構造でした。

    AxiosのGitHub Issue #10604でも、axios@1.14.1とaxios@0.30.4が侵害されていたことが公に共有されています。公式issue自体は技術詳細が少ないものの、外部研究者からの指摘が速やかに可視化されたことで、npm配布物とGitHub上の正規ソースの間に乖離が生じていたことが早期に認識されました。

    本質は「脆弱性」でなく「信頼の乗っ取り」

    本事案を理解するうえで重要なのは、Axios本体のコード品質に起因する一般的な脆弱性とは性質が違う点です。StepSecurityの公式Blog「axios Compromised on npm – Malicious Versions Drop Remote Access Trojan」によると、攻撃者はAxiosメンテナーのnpmアカウントを侵害し、通常のGitHub Actions経由のTrusted Publisherではなく、盗まれた認証情報を使って悪性版を公開したとのことです。正規リリースではGitHub Actions由来の公開痕跡が見える一方、問題の1.14.1ではそのパターンが崩れており、さらにGitHub側に対応するコミットやタグも確認できませんでした。これは、開発者が「公式パッケージだから安全」と判断しやすい場所そのものが改ざんされたことを意味します。ソフトウェアサプライチェーン攻撃が危険視される理由はここにあります。アプリケーション開発者は通常、依存パッケージを全面的に目視監査しません。しかもAxiosは週あたり1億回規模で利用される人気ライブラリであり、上流の1パッケージが汚染されるだけで、その影響は大量の開発環境、ビルドサーバー、CIランナー、社内アプリケーションへ連鎖する可能性があります。Google Cloud Blog(前段参照)では今回の事案による影響は広範にわたる、と警告しており、単発のnpm事故では済まない可能性を示しています。

    悪性版Axiosはどのように動いたのか

    Google Cloud Blogによると、混入されたplain-crypto-jsは難読化されたドロッパーであり、Windows、macOS、Linuxを対象にWaveShaper.V2のバックドアを展開したとのことです。package.jsonのpostinstallによってバックグラウンドでsetup.jsが実行されるため、開発者の体感としては、ただ依存関係を導入しただけに見えます。Socket公式ブログ「Supply Chain Attack on Axios Pulls Malicious Dependency from npm」やStepSecurityブログ(前段参照)でも、plain-crypto-jsは本来のAxios機能では参照されておらず、マルウェア配布のためだけに差し込まれた依存関係だった、と整理しています。さらにStepSecuritは、当該ドロッパーがC2へ接続し、OSごとの第2段階ペイロードを取得した後、自己削除やpackage.jsonの正常化で痕跡隠蔽を試みると説明しています。ここが企業実務では特に重要です。単に「悪い版を消して入れ直せば終わり」ではなく、インストールを実行した開発端末やCI環境そのものを侵害前提で確認すべき、という判断につながるからです。

    影響を受けるのはどんな企業か

    影響範囲は、Axiosを直接使うWebアプリ開発チームに限りません。Socketは、^1.14.0や^0.30.0のようなキャレット範囲指定をしていたプロジェクトでは、次回のnpm install時に不正版を取得し得たと指摘しています。つまり、明示的に最新版へ上げた覚えがなくても、自動解決で悪性版を拾う余地がありました。この特徴はnpm運用の現実とよく一致しており、依存関係を日常的に更新する開発現場ほど巻き込まれる可能性が高まります。

    また、企業内で見落とされやすいのがCI/CDパイプラインです。StepSecurityは、問題の版が公開されていた時間帯にnpm installやnpm ciを実行したビルド環境を重点確認対象として挙げています。開発者PCだけでなく、CIランナー、検証環境、コンテナビルド基盤、さらにはその先の秘密情報管理まで連鎖確認が必要になります。サプライチェーン攻撃は「ライブラリの問題」だけに限らず、認証情報の流出、ビルド改ざん、社内への横展開まで発展する可能性があるのです。

    北朝鮮系脅威アクターとの関連は?

    Google Cloud Blogでは今回の活動は北朝鮮のハッカー集団「UNC1069」が関与している、と指摘しています。理由として、「WaveShaper.V2」のバックドアを使用している点や攻撃インフラと過去活動の重なりが示されています。

    企業は何をもって「影響あり」と判断すべきか

    まず確認すべきなのは、2026年3月31日の短い公開ウィンドウの間に、axios@1.14.1またはaxios@0.30.4、あるいはplain-crypto-js@4.2.1を取得した痕跡があるかどうかです。

    StepSecurityは、ローカルリポジトリやpackage-lock.json、node_modules内の痕跡確認方法を示しています。Cybozuの注意喚起でも、日本時間の2026年3月31日9:21〜12:15ごろに該当処理を行った環境は、問題のあるAxiosをインストールした可能性があるとしています。日本企業にとっては、この日本標準時(JST)での切り替えが実務上わかりやすい基準となります。ただし、痕跡確認で「見つからなかった」というだけでは完全に安心できません。今回のペイロードは痕跡隠蔽も伴うため、その時間帯にビルドや依存更新を実行した環境は、ログ、ネットワーク通信、認証情報利用履歴まで含めて点検したほうがよいです。特にCI環境にクラウド資格情報や署名鍵、デプロイトークンを置いている組織は優先度が高いでしょう。サプライチェーン攻撃では、初動対応の遅れが二次被害につながります。

    今回のAxios事案で推奨される初動対応

    今回の事案で重要なのは、単なるパッケージの差し替えではなく、侵害前提のインシデントレスポンスです。StepSecurityでは、axios@1.14.1または0.30.4をインストールしていれば、システム侵害を前提として扱うべきだとしています。これはドロッパー型マルウェアと開発環境侵害の組み合わせを考えると、合理的な判断といえます。少なくとも、端末隔離、トークンや認証情報のローテーション、CIシークレットの再発行、該当ジョブやコンテナの洗い替え、関連ログの保存は必要になるでしょう。

    また、依存関係の修正では、問題のある版を避けて既知の正常版へ戻す必要があります。StepSecurityブログの比較によると、axios@1.14.0および0.30.3には問題のplain-crypto-js依存が存在しません。したがって、少なくとも悪性版から即時ロールバックする対象としてこの二つは確認済みのクリーン版といえます。将来的な正式後継版の採用は、Axios側による公式情報や検証結果を見て判断するのが安全でしょう。

    なぜAxiosのサプライチェーン攻撃はここまで注目されたのか

    理由は主に3つ挙げられます。第一に、AxiosがJavaScript開発で極めて広く使われていることです。第二に、ソースコードレベルでは目立ちにくい依存関係の一点差し替えで成立していたことです。第三に、Windows、macOS、Linuxの全方位を狙うクロスプラットフォーム型だったことです。GoogleもElasticも、この事案を単発のnpm汚染ではなく、最近続いているオープンソース供給網攻撃の流れの中で捉えています。つまり、OSSの人気パッケージを踏み台にして開発者環境を取るという攻撃モデルが、今後さらに一般化する可能性があります。

    企業の情報システム部門やセキュリティ担当者にとって重要なのは、「脆弱性管理だけではこの種の攻撃を十分に捉えきれない」という点です。今回のようなAxiosのサプライチェーン攻撃では、CVEの有無より先に、配布経路、署名・公開フロー、依存解決、CI実行タイミングがリスクの中心になります。ソフトウェア部品表、依存関係監視、公開直後版のクールダウン、Trusted Publisherの徹底、CIシークレット分離といった運用論が、一気に現実味を帯びたといえます。

    Axiosのサプライチェーン攻撃から企業が学ぶべきこと

    本事案は、「有名ライブラリだから安全」「公式アカウントから出た版だから安全」という前提が崩れたことを示しています。開発の現場では、依存ライブラリの更新を迅速化するほど生産性は上がりますが、その一方で悪性版を取り込むリスクも高まります。そのため今後は、すべての更新を遅くするのではなく、公開直後の版に対する短い待機期間、異常依存の検知、ビルド時の外部通信監視、重要トークンの短命化といった、現実的な防御策を重ねることが必要になります。特に経営層は、本事案を「OSS(オープンソースソフトウェア)利用の危険性」と短絡的に考えるべきではありません。OSSは現代開発の基盤であり、排除は現実的ではありません。問われるのは、OSSを使う前提でどう監視し、どう公開フローを信頼し、どう侵害時に被害を限定するかということです。Axiosのサプライチェーン攻撃は、その問題を開発部門だけでなく、情シス、CSIRT、監査、経営まで広げた事件として位置づけるべきでしょう。

    まとめ

    Axiosのサプライチェーン攻撃は、2026年3月31日に発生したnpm改ざん事案であり、axios@1.14.1とaxios@0.30.4に悪性依存関係plain-crypto-js@4.2.1が混入していました。インストール時のpostinstallでクロスプラットフォームのRAT(Remote Access Trojan)配布が行われる構造で、影響判定の中心は「使ったかどうか」ではなく、その時間帯にその版を取得したかどうかです。もし該当版を導入していれば、パッケージの入れ替えだけで済ませず、開発端末やCI環境を侵害前提で調査し、認証情報のローテーションまで含めて対応する必要があります。今回の事件は、npm、JavaScript、依存関係管理の問題、そしてサプライチェーン攻撃対策を考えるうえで、2026年を代表するケースの一つになるでしょう。


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

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

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

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

  • 2026年4月10日(水)14:00~15:00
    ランサムウェア時代のIT-BCP入門~サイバー攻撃によるシステム停止に備える実践的な策定ステップ~
  • 2026年4月15日(水)14:00~15:00
    AI時代のサイバー脅威最前線 ― IPA『情報セキュリティ10大脅威2026』から学ぶ防御戦略 ―
  • 2026年4月22日(水)14:00~15:00
    Swift CSCF v2026変更点解説セミナー ― Control 2.4 (Back Office Data Flow Security)の必須化とCustomer client connectorへの要件適用拡大 ―
  • 最新情報はこちら

    編集責任:木下

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


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

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

    TLSバージョンの確認方法とは?ブラウザ・OpenSSL・ツールでのチェック手順と安全な設定ポイント

    Share
    「TLSバージョンの確認方法とは?ブラウザ・OpenSSL・ツールでのチェック手順と安全な設定ポイント」アイキャッチ画像

    サイバー攻撃の多くは、暗号化通信の不備や古いセキュリティ設定を狙って行われます。特に、TLS(Transport Layer Security)の設定が適切でない場合、通信の盗聴や改ざんといったリスクが高まります。そのため、企業のWebサイトやシステムでは、現在使用しているTLSバージョンを正しく把握し、安全な設定を維持することが重要です。本記事では、TLSバージョンの確認方法と、安全な設定・運用のポイントを実務視点で解説します。

    TLS設定の全体像やリスクについては、基礎解説の記事とあわせて確認すると理解が深まります。TLS設定の全体像やリスクを先に理解したい方は、「TLS設定の安全性と確認ポイント」 を先にお読みください。

    TLSとは?(基本の整理)

    TLSは、インターネット上の通信を暗号化するためのプロトコルです。HTTPS通信は、このTLSによって保護されており、通信内容の盗聴や改ざんを防ぐ役割を担っています。

    TLSのバージョン移行の背景

    TLSはこれまで複数のバージョンが提供されてきましたが、セキュリティ上の問題により、古いバージョンは段階的に非推奨となってきました。特にTLS1.0およびTLS1.1は、暗号技術の脆弱性や攻撃手法の進化により安全性が不十分とされ、現在では主要なブラウザやサービスにおいて無効化されています。その結果、現在のWeb環境ではTLS1.2以上の利用が標準となり、さらにセキュリティと性能を強化したTLS1.3への移行が進んでいます。

    TLSの仕組みやバージョンごとの違いについては、以下の記事で詳しく解説しています。
    TLS設定の安全性と確認ポイント:古い暗号設定が引き起こすリスクと改善手順

    TLSバージョンの確認方法

    TLSバージョンは、以下の方法で確認できます。

    ブラウザで確認(例:Chrome)

    1. Webサイトにアクセス
    2. F12で開発者ツールを起動
    3. [Security]タブを選択 →「Connection is secure」の項目を確認→ “TLS 1.3” などと表示されます

    OpenSSLコマンドで確認(Linux/Mac)

    “`bash
    openssl s_client -connect example.com:443 -tls1_3

    オンラインツールで確認

    • SSL Labs: https://www.ssllabs.com/ssltest/
    • CDN77: https://tools.cdn77.com/tls-test

    最新のTLSバージョン利用状況

    2025年時点における主要WebサイトのTLS対応状況を見ると、TLS 1.2は引き続き広く利用されており、TLS 1.3の採用も大きく進んでいます。一方で、TLS 1.0およびTLS 1.1は大幅に減少し、実運用ではほぼ利用されない状況となっています。

    【各プロトコルバージョンのサポート状況】

    出典:Qualys SSL Labs SSL Pulse (https://www.ssllabs.com/ssl-pulse/

    現在もTLS 1.2が広く利用されていますが、多くの環境でTLS 1.3にも対応しており、サーバとブラウザの双方が利用可能な場合には、より新しいバージョンが優先的に使用されます。

    また、最新のブラウザ環境では、通信の多くがTLS 1.3で行われるケースが増えており、特に主要サイトではTLS 1.3の利用が標準的になりつつあります。こうした傾向から、暗号化通信はTLS 1.3を中心とした環境へ移行が進んでいます。

    さらに、主要ブラウザにおいてTLS 1.0およびTLS 1.1が無効化されたことで、これらの古いバージョンは互換性維持の目的でもほとんど利用されなくなっています。セキュリティおよび互換性の観点からも、TLS 1.2以上への対応が必須となっています。

    古いTLS(TLS1.0 / 1.1)バージョンを使い続けるリスク

    TLS1.0や1.1は既に非推奨であり、脆弱性が存在します。攻撃者は、サーバを攻撃するにあたって必ずブラウザを経由するわけではないため、TLS 1.1以下の接続を許容すること自体が危険であり、攻撃者にとって狙いやすいターゲットとなる可能性があります。脆弱性を悪用された場合、通信を盗聴し復号することで重要情報の窃取が可能になるというリスクも考えられます。

    多くのサイバー攻撃は、古いTLSバージョンなどの脆弱性を悪用して侵入されます。
    脆弱性への具体的な対応方法については、以下の記事で詳しく解説しています。
    脆弱性対応の基本と実践ポイント

    古いTLSが引き起こす問題と影響

    古いTLSバージョンの危険性:BEAST/ダウングレード攻撃とは

    BEAST攻撃SSL 2.0、SSL 3.0およびTLS 1.0 プロトコルに影響を及ぼし、攻撃者はWebブラウザとWebサイトとの間のSSL暗号化、またはTLS暗号化されたセッションのコンテンツを復号することができる*4
    ダウングレード攻撃TLS 1.1以下のプロトコルでは、認証付き秘匿モード等の安全性の高いアルゴリズムがサポートされていないため、強度の低い暗号アルゴリズムを強制的に使用させることができる*2

    現在のセキュリティ対策の指標として一般的に用いられる各種国際的標準でも、TLS 1.1以下の継続使用は下記のとおり推奨されていないため、利用している場合には、早急に対策を検討することが求められます。

    NIST(National Institute of Standards and Technology、
    米国立標準技術研究所)
    2018年10月、ガイドライン案公開。2024年1月1日までにTLSを使用するすべての米国政府のサーバでTLS 1.3をサポートすることを提案
    PCI DSS(Payment Card Industry Data Security Standard)2018年6月30日以降、初期TLSを利用しているシステムはクレジットカード業界における監査基準に適合しない
    ※POS POI環境のように既知の脆弱性の悪用が困難であったり、SSL/TLSをセキュリティコントロールとしては使用していなかったりする等、例外的にTLS 1.1以下が許容される場合がありますが、情報セキュリティのベストプラクティスではTLS 1.1以下のプロトコルバージョンはすべて非推奨とされています。*3

    TLS1.2/1.3への移行手順と設定のポイント

    安全な通信のためには、TLS1.2以上の利用が推奨されます。具体的には、TLS 1.1以下は無効(利用不可)とし、TLS 1.3およびTLS 1.2を有効にし、バージョンが新しいものから順に接続の優先度を高く設定してください。

    2018年8月には、TLS 1.3が正式リリースされました。以降、TLS 1.3に対応するプラットフォーム等が次々に利用可能になっています。例としては、OpenSSL 1.1.1系(2018年9月)、OpenSSL 3.0系*4(2021年9月)、Java SE/JDK 11(2018年9月)、Java SE/JDK 8バージョン8u261以上*5(2020年7月)や、そのほかにもRed Hat Enterprise Linux 8(2019年5月)が挙げられます。

    TLS 1.3のサポートにより、パフォーマンスとセキュリティが向上します。 構成上または仕組み上、現時点ではTLS 1.3を実装することが困難な場合、上記よりさらに古いシステムが稼働している可能性が考えられます。それらのシステムは、経年に伴う脆弱性の蓄積による影響や、サポート終了により新たに発見された脆弱性への対応策がなくなること等も危惧されます。

    設定時のチェックポイント

    • TLS1.0 / 1.1の無効化
    • 安全な暗号スイートの使用
    • 証明書の適切な管理

    TLS設定を継続的に管理する重要性

    TLS設定は一度確認すれば終わりではありません。実際の運用環境では、サーバ構成や他システムとの兼ね合いにより、「安全そうに見えてもリスクが残っている」ケースも少なくありません。自社サイトのTLS設定について、

    • 定期的なチェック
    • 設定変更時の再確認
    • 最新のセキュリティ情報の把握

    といった継続的な運用が重要です。

    各種ガイドラインの紹介

    PCI DSSについては、 2022年3月31日、Payment Card Industry Security Standards Council(PCI SSC)により、v4.0が公開されました。

    本ガイドラインは、各種国際的標準(NIST SP800/PCI DSSv4.0/OWASP ASVS等)の準拠に向けた取り組みや、暗号設定における今後のセキュリティ対策を検討する上でも役に立ちます。ぜひ参照されることをおすすめします。

    PCI DSS v4.0で求められるセキュリティ対策のポイントについては以下の記事で詳しく解説しています。ぜひあわせてご覧ください。
    PCI DSS v4.0で変わるセキュリティ対策のポイント

    TLS設定確認を効率化する方法

    TLS設定の確認・管理を効率化するには、ツールや外部サービスの活用が有効です。

    • 現在の設定が本当に適切か判断できない
    • 古い設定や見落としがないか不安がある
    • 他のセキュリティリスクとあわせて確認したい

    と感じた場合は、第三者の視点で状況を整理することも有効です。

    BBSecでは

    TLS設定の確認だけでなく、システム全体のセキュリティを強化するには、専門的な診断の実施が有効です。脆弱性診断やセキュリティ対策についてご検討の方は、お気軽にご相談ください。

    ネットワーク脆弱性診断

    悪意ある第三者の視点で、ネットワークをインターネット経由またはオンサイトにて診断し、攻撃の入口となる可能性のある箇所を検出します。システムの導入・変更・アップグレード時、運用中のシステムの定期チェックにご活用いただけます。

    ネットワーク診断バナー広告

    デイリー自動脆弱性診断

    内部ネットワークおよびWEBサイトの脆弱性を自動診断し、その結果を専用のWEBページで報告します。新規設備投資が不要で、即時に結果を確認できるので、脅威が現実となる前に対策を施すことが可能になります。

    CPEバナー広告

    TLS設定の基本的な考え方やリスクについては、
    →「TLS設定の安全性と確認ポイント」もあわせてご覧ください。


    公開日:2022年4月6日
    更新日:2026年4月1日

    編集責任:木下

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


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

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

    武蔵小杉病院へのランサムウェア攻撃 ―第2報から読み解くランサムウェア侵入経路と影響範囲―

    Share
    「武蔵小杉病院へのランサムウェア攻撃 ―第2報から読み解くランサムウェア侵入経路と影響範囲―」アイキャッチ画像

    2026年2月、日本医科大学武蔵小杉病院は「院内の医療情報システムの一部がランサムウェア攻撃を受け、障害が発生した」こと、そしてそれに伴い患者の個人情報漏洩が確認されたことを公表しました*6。病院の発表は「第2報」という位置づけで、被害範囲、時系列、侵入経路、当面の診療体制、相談窓口までが具体的に示されています。まず強調したいのは、憶測で語られがちな“病院のサイバー攻撃”を、ここでは病院自身が明言した事実ベースで解説する点です。本記事では今回の公表内容(第2報)を中心に、医療機関サイバーセキュリティの観点で「何が起きたのか」「なぜ起きやすいのか」「利用者は何に気を付けるべきか」をわかりやすくまとめます。

    侵入経路は“医療機器保守用VPN装置”

    病院の第2報で明記された「攻撃を受けたシステム」は、ナースコールシステムのサーバー3台です。ナースコールは入院患者が看護師を呼ぶための仕組みとして広く知られていますが、その裏側では端末やサーバーが稼働し、運用上の都合から患者情報と結び付いているケースも珍しくありません。今回、病院は当該サーバーがランサムウェア攻撃を受けたことを認め、さらに調査の結果として「侵入経路は医療機器保守用VPN装置であった」ことが確認されたとしています。

    ここでいうVPN装置は、医療機器メーカーなどが遠隔で保守作業を行う目的で用いられることが多い仕組みです。便利な一方で、通常のIT統制の枠外に置かれやすいのが現実です。たとえば、病院の標準的なIT統制から外れた管理になっていたり、資産管理やパッチ適用、アクセス制御、多要素認証などの基本対策が後回しになっていたりします。厚生労働省も注意喚起の中で、VPN装置を含むゲートウェイ機器の脆弱性対策、管理インターフェースのアクセス制限、認証強化などを重要ポイントとして挙げています。今回の発表内容は、まさにその“急所”が突かれ得ることを示す事例として受け止めるべきでしょう。

    漏洩した個人情報

    病院は、漏洩が確認された個人情報の項目として、氏名、性別、住所、電話番号、生年月日、患者IDを挙げています。また、漏洩が確認された人数は「約1万人」で、これは2026年2月14日11時時点の確認値だとされています。一方で、患者が特に気にすると考えられる医療内容そのものについて、病院は「カルテ情報」の漏洩は現時点で確認されていないと明記しています。さらに、クレジットカード情報、マイナンバーカード情報についても、現時点では漏洩確認がないとしています。ここは不安を抱く利用者にとって重要なポイントです。ただし、ここでの注意点は「現時点では確認されていない」という表現が示す通り、調査が進む過程で情報が更新される可能性がゼロではないことです。病院も、仮に漏洩拡大が判明した場合はホームページで速やかに報告するとしています。

    いつ気づき、どう動いたのか

    第2報には、攻撃を認識した日時と経緯が日付単位で整理されています。最初の兆候は2026年2月9日午前1時50分頃、病棟のナースコール端末が動作不良となり障害を把握したことでした。その後、ナースコールシステムのベンダー調査により、サーバーがランサムウェア攻撃を受けたことが判明したとされています。病院は当該システムと関連ネットワークを遮断し、同日に文部科学省、厚生労働省、所轄警察へ報告したと公表しています。

    続く2月10日には、厚生労働省の初動対応チームの派遣要請を行い、外部接続ネットワークを遮断してサーバー保全を開始。2月11日には初動対応チームの調査により、当該サーバーが院外と不正通信を行い、患者の個人情報を窃取していたことを確認したとされています。さらに、電子カルテを含む他の医療情報システムへの影響調査、外部接続ネットワーク機器の脆弱性や設定の調査も開始した、と時系列で説明されています。2月12日に個人情報保護委員会へ報告し、2月13日には漏洩した患者へ郵送でのお詫び連絡を開始した、と続きます。

    この流れを見ると、ポイントは二つあります。ひとつは「障害として最初に見えた」こと、もうひとつは「通信ログ等の調査で情報窃取の事実確認に至った」ことです。ランサムウェアは“暗号化して身代金要求”のイメージが強い一方で、近年は暗号化だけでなく情報窃取を組み合わせ、二重三重の脅迫に発展するケースが問題視されてきました。今回の発表でも「不正通信」と「窃取」が明確に言及されており、病院がそこを重要事実として公表している点は見落とせません。

    病院業務は止まったのか

    医療機関へのサイバー攻撃で最も懸念されるのは、診療の停止や救急の受け入れ停止など、医療提供体制への影響です。今回、病院は2026年2月14日時点で、外来、入院、救急受け入れはいずれも通常通り実施していると説明しています。また「他の医療情報システムへの影響は現時点では確認されていない」とし、病院業務は通常通りと明記しています。

    ここで大事なのは、“通常通り”という言葉の解釈を膨らませすぎないことです。病院が示したのは、その時点で確認できている範囲の診療体制であり、現場では臨時対応や負荷増が起きている可能性はあります。ただ、少なくとも公表文の事実としては、全面停止や救急停止を示す記述はなく、「止めずに継続している」という説明が中心です。

    病院がとった封じ込めと復旧対応

    第2報の中で、病院は「当該システム及び外部との通信を一切遮断し、専門家や電子カルテベンダーと共に、他のシステムへの影響について詳細な現況調査を継続して実施しております。」とし、原因となったランサムウェアの特定を完了し、「ウイルス対策ソフト会社より提供された最新のパターンファイルを用いて、現在、院内全域でのウイルス駆除作業を実施しております。」と説明しています。

    サイバーインシデント対応として見ると、ここには典型的な優先順位が現れています。まず“広げない”ための遮断、次に“証拠を残す”ための保全、その上で“横展開の確認”として他システム影響調査、そして“回復”のための駆除作業です。特に医療機関では、電子カルテだけ守っても安全とは言い切れません。ナースコールのような周辺系、委託業者や医療機器ベンダーの保守経路、ネットワーク機器設定など、境界にある仕組みが狙われると、想定外の入口になります。私たちが特に注目すべきと考えるのは、医療機器保守用VPN装置が侵入経路として公表された点です。これは医療機関のセキュリティ対策が“例外管理”に弱いことを改めて突き付けています。

    詐欺・なりすましへの警戒

    今回漏洩が確認された情報には、氏名、住所、電話番号、生年月日が含まれます。これは、金融情報そのものではない一方で、なりすまし、勧誘、フィッシング、特殊詐欺の“材料”として悪用されやすい属性情報です。病院は、漏洩した患者に対して「直接連絡する」とし、実際に2月13日から郵送によるお詫び連絡を開始したと公表しています。したがって利用者側の現実的な対策は、まず「病院から届く郵送物や案内」を冷静に確認し、連絡先や手続きが公表内容と整合するかを見極めることです。そして電話やSMS、メールで“病院を名乗る連絡”が来た場合、いきなり個人情報を追加で伝えたり、リンクを開いて入力したりせず、病院が設置した問い合わせ窓口など、公式に案内された経路へ折り返し確認するのが安全です。病院は本件の相談・問い合わせ専用窓口(専用ダイヤルの複数回線やフリーダイヤル運用開始予定)を案内していますので、確認の際はそうした公式窓口を使うのが基本になります。

    よくある疑問:電子カルテは大丈夫なのか、身代金は払ったのか

    「電子カルテは大丈夫なのか」という疑問に対しては、病院の公表では、「他の医療情報システムへの影響は現時点では確認されていない」とされています。つまり、“影響なし”と断定しているというより、調査継続の前提で“少なくとも現時点の確認では影響が見つかっていない”という説明です。ここは言葉通りに受け止め、今後の更新を注視するのが適切です。

    「身代金を払ったのか」という点については、第2報の本文からは読み取れません。少なくとも病院は、侵入経路、漏洩項目、診療状況、当局報告、遮断・調査・駆除といった事実を中心に説明しており、金銭要求や支払いに関する記載は確認できません。ここで外部の憶測を混ぜると正確性が落ちるため、本記事では触れません。

    なぜ医療機関は狙われるのか:つながる医療機器

    医療機関のサイバー攻撃を考えるとき、電子カルテだけを守ればよいという発想は危険です。病院には、医療機器、保守用回線、委託業者のネットワーク接続、建物設備、ナースコールのような周辺システムまで、多様な“つながる仕組み”があります。しかも医療の現場は24時間止められず、更新・停止・入れ替えが難しい機器も少なくありません。結果として、VPN装置のような境界機器が古い設定のまま残りやすかったり、管理者が限定されて全体の統制が効きにくかったりします。

    厚生労働省の注意喚起でも、VPN装置を含むゲートウェイ機器の脆弱性対策を迅速に行うこと、管理インターフェースのアクセス制限を行うこと、多要素認証などで認証を強化すること、資産(IoT機器を含む)の把握を行うことが示されています。武蔵小杉病院の件で侵入経路が医療機器保守用VPN装置である、と公表されたことは、これらが“机上の理想”ではなく、現実の被害と直結する論点であることを、改めて裏付ける材料になっています。

    企業・組織側が学ぶべき教訓:VPNと保守経路の統制はセキュリティの“盲点”

    今回の公表内容から読み取れる最大の教訓は、保守のための例外的な経路を放置しないことです。医療機関に限らず、製造業、ビル管理、自治体、教育機関などでも、ベンダー保守用VPNは現場の利便性を理由に残りやすく、監査や更新の網から漏れがちです。だからこそ、ネットワーク図に載っていない接続点、ベンダーしか触れない装置、管理台帳にない機器といった“影の資産”を可視化し、アクセス制御、ログ監視、脆弱性対応、認証強化、契約と運用ルールの整備まで含めて統制する必要があります。また、今回病院が行ったように、初動で外部接続を遮断し、当局に報告し、初動対応チームや専門家と連携しながら調査と封じ込めを進めることは、医療機関のインシデントレスポンスとして重要です。平時から、遮断判断の基準、連絡系統、証拠保全の手順、ベンダー連携の契約条項、代替運用を準備しておかなければ、同じ判断を迅速に実行するのは難しくなります。

    まとめ

    日本医科大学武蔵小杉病院の公表によれば、今回のサイバー攻撃はナースコールシステムがランサムウェア攻撃を受けたことに端を発し、医療機器保守用VPN装置が侵入経路として確認され、患者の個人情報が窃取されたとされています。漏洩は約1万人、項目は氏名や住所、電話番号、生年月日、患者IDであり、カルテ情報やクレジットカード情報、マイナンバーカード情報の漏洩は現時点で確認されていない、というのが病院の説明です。

    “病院のサイバー攻撃”という言葉は刺激的ですが、重要なのは、どのシステムが攻撃され、どの経路が弱点になり、どんな情報が漏洩し、利用者と組織が何に備えるべきかを、事実に即して理解することです。今回の事例は、電子カルテ以外の周辺システムも含めた医療機関サイバーセキュリティの必要性、そしてVPN装置や保守経路を例外扱いしない統制の重要性を、強く示しています。今後も病院の続報で情報が更新される可能性があるため、一次情報の確認を前提に、過度な憶測ではなく、現実的な警戒と備えにつなげることが肝要です。

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

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

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

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

  • 2026年3月4日(水)14:00~15:00
    脱PPAP対策、添付ファイル運用、本当に最適ですか? ―添付するだけで自動分離。運用を変えない選択肢―
  • 2026年3月18日(水)14:00~15:00
    2026年、企業が直面するサイバー脅威 ― IPA 『情報セキュリティ10大脅威 2026』から考える対応戦略 ―
  • 2026年4月15日(水)14:00~15:00
    AI時代のサイバー脅威最前線 ― IPA『情報セキュリティ10大脅威2026』から学ぶ防御戦略 ―
  • 最新情報はこちら

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


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

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

    【速報版】情報セキュリティ10大脅威 2026 -脅威と対策を解説-

    Share
    【速報版】情報セキュリティ10大脅威 2026 -脅威と対策を解説-アイキャッチ画像

    2026年1月29日、独立行政法人情報処理推進機構(IPA)は「情報セキュリティ10大脅威 2026」(組織編)を公表しました。各脅威が自身や自組織にどう影響するかを確認することで、様々な脅威と対策を網羅的に把握できます。多岐にわたる脅威に対しての対策については基本的なセキュリティの考え方が重要です。本記事では、脅威の項目別に攻撃手口や対策例をまとめ、最後に組織がセキュリティ対策へ取り組むための考え方について解説します。

    「情報セキュリティ10大脅威 2025」の解説はこちら。ぜひあわせてご覧ください。
    【速報版】情報セキュリティ10大脅威 2025 -脅威と対策を解説-

    情報セキュリティ10大脅威 2026概要

    出典:独立行政法人情報処理推進機構(IPA)
    「情報セキュリティ10大脅威 2026」(https://www.ipa.go.jp/pressrelease/2025/press20260129.html)(2026年1月29日)組織向け脅威

    独立行政法人情報処理推進機構(IPA)は「情報セキュリティ10大脅威 2026」を発表しました。「組織」向けの脅威では、1位に「ランサム攻撃による被害」、2位「サプライチェーンや委託先を狙った攻撃」が前年と同じ順位を維持。3位には「AIの利用をめぐるサイバーリスク」が初選出にして上位にランクインし、AIの利活用におけるリスクが無視できないものであることを示しています。また、6位の「地政学的リスクに起因するサイバー攻撃」には「情報戦を含む」と追記され、偽情報などの影響工作も含む脅威と明示化されました。昨年では10位にランクインしていた「不注意による情報漏えい等」が圏外となりました。

    2025年度版との比較

    昨年との比較でまず注目したいのは、「AIの利用におけるサイバーリスク」が初選出にして3位という上位にランクインしたことです。生成AI(LLM:大規模言語モデル)の急速な普及に伴い、「AIを利用した際の情報漏えいや権利侵害」、「AIが生成した誤情報を鵜呑みにすることで生じる問題」、そして「AIの悪用におけるサイバー攻撃の容易化・高度化」と多岐にわたるリスクが現実的な脅威となっています。

    新規項目のランクインに伴い、「不注意による情報漏えい等」が圏外となりましたが、不注意による情報漏えいは引き続き発生しており、対策が必要な脅威です。その他の項目については大きな変化はなく、「ランサム攻撃による被害」と「サプライチェーンや委託先を狙った攻撃」は、例年通り不動の1位2位となっています。

    日本の大手企業も被害にあった「ランサム攻撃による被害」「サプライチェーンや委託先を狙った攻撃」

    2025年版に続き、「ランサムウェアによる被害」と「サプライチェーンの弱点を悪用した攻撃」が1位・2位を占めました。これは2023年以降4年連続となっており、情報処理推進機構(IPA)によると、2025年もランサムウェア被害が多発し、取引先を含むサプライチェーン全体へ深刻な影響が及んだ事実が、この順位の不動ぶりを表しているとのことです。

    ランサムウェア攻撃は、データを暗号化して復旧と引き換えに身代金を要求する手口に加え、窃取情報の公開をちらつかせる「二重脅迫」が主流です。2025年の象徴的な事例として、アサヒグループホールディングスへのランサムウェア攻撃がありました。これにより、受注・出荷システムに障害が発生し、一部商品の品薄など消費者にも影響が波及しました。また国内飲料事業では、昨年10月の暫定売上が前年同月比で約6割に落ち込むなど、事業面に大きな爪痕を残しています。*2

    アサヒグループホールディングスへのランサムウェア攻撃をはじめとした、国内のランサムウェア被害の事例については、以下の記事でも解説しています。ぜひあわせてご覧ください。
    【速報】アサヒグループホールディングス社長会見、犯行は「Qilin」―サイバー攻撃の全貌とセキュリティの盲点https://www.sqat.jp/kawaraban/40295/
    アサヒグループを襲ったランサムウェア攻撃https://www.sqat.jp/kawaraban/39292/
    ・アサヒグループも被害に ―製造業を揺るがすランサムウェア攻撃https://www.sqat.jp/kawaraban/39672/
    ・【2025年最新】日本国内で急増するランサムウェア被害-無印良品・アスクル・アサヒグループの企業の被害事例まとめ-https://www.sqat.jp/kawaraban/39635/

    ランサムウェア攻撃は有名企業に限らず、体制が手薄な中小企業も広く標的とします。ひとたびシステムが完全に暗号化されると、復旧には多大な時間とコストを要します。そのため、侵入を防ぐ観点では、外部公開されたVPN機器等の棚卸しによる不要な経路の閉鎖、必要な経路への多要素認証の徹底、そして機器の脆弱性管理を継続することが重要です。あわせて、侵入されても業務を止めないために、ネットワークから切り離したバックアップの確保や復元訓練、ログ監視、初動手順の整備を行い、平時から「短期間で業務を戻せる設計」を作っておくことが求められます。

    一方、サプライチェーン攻撃は、標的企業への直接侵入が難しい場合に、セキュリティ対策が手薄な取引先や委託先を足がかりに侵入する点が特徴です。多くの企業がクラウドサービスや外部ベンダーに依存する現在、攻撃者はその隙を狙っています。2025年の事例として、アスクル株式会社のシステムへのランサムウェア攻撃がありました。例外的に多要素認証を適用していなかった業務委託先の管理者アカウントが侵入経路になったとされています。*2 その結果、出荷業務の停止に追い込まれ、約52億円を特別損失に計上する事態へと発展しました。*3

    サプライチェーン攻撃は自社の努力だけでは防ぎきれず、委託先を含む全体での統制が必要です。契約時にセキュリティ要件を明確にし、例外運用を恒常化させない仕組み作りが不可欠です。加えて、ゼロトラストアーキテクチャを採用し、すべてのアクセスを検証する仕組みを構築することも有効な対策となります。

    急速な普及と共に顕在化している「AIの利用をめぐるサイバーリスク」

    「情報セキュリティ10大脅威 2026」では、新たに「AIの利用をめぐるサイバーリスク」が3位にランクインしました。ここでのリスクとは、AIへの理解不足に起因する情報漏えいや権利侵害、誤情報の鵜呑みによる判断ミス、さらにAI悪用によるサイバー攻撃の容易化・巧妙化など多岐にわたります。例えば、英国企業ArupではAI技術(ディープフェイク)で生成された偽のCFOや従業員とのビデオ会議により、2,500万ドルの詐欺被害に遭ったと発表されました。「映像や音声で会話ができるなら本人に間違いない」という心理的な隙を突いた攻撃手法です。*4また、「KawaiiGPT」のような攻撃用にカスタマイズされた悪性AIの登場により、経験の浅い攻撃者でも、従来は数時間〜数日かかっていた攻撃サイクルをわずか数分で実行できる環境が整備されつつあります。また、「KawaiiGPT」のような攻撃用にカスタマイズされた悪性AIの登場により、経験の浅い攻撃者でも、従来は数時間〜数日かかっていた攻撃サイクルをわずか数分で実行できる環境が整備されつつあります。*5

    攻撃を受けるリスクだけでなく、AIの「利用者側」のリスクも無視できません。米国企業Teslaは、発表イベントで使用したAI生成画像が既存映画の場面に酷似しているとして、制作会社から提訴されました。*6自社生成した画像であっても、意図せず既存作品に似てしまい法的リスクを招く一例です。また、生成AIが捏造した判例や引用を、弁護士が検証不足のまま提出して懲戒処分などに発展した事例も複数報じられています。*7これは法務だけの問題ではなく、AIによる「もっともらしい誤情報」が人の判断ミスを誘発するという重要な示唆を含んでいます。基本的なセキュリティ対策の徹底はもちろんですが、不十分な理解のままAIを利用するリスクを認識し、教育を通じてAIリテラシーを強化することも重要となっています。

    情報戦への拡大「地政学的リスクに起因するサイバー攻撃(情報戦を含む)」

    「地政学的リスクに起因するサイバー攻撃」とは、国際情勢の緊張や対立が、直接的にサイバー空間の脅威へと波及するリスクを指します。今回、項目名に「情報戦を含む」と明示されたように、国家が支援するサイバー攻撃は、システムの破壊や金銭の窃取に留まりません。偽情報の流布や情報操作を通じて、選挙への介入や社会の混乱を狙うケースが増加しています。英国では、現職議員が「離党を宣言する」かのようなAI生成の偽動画(ディープフェイク)が拡散され、本人が警察に通報する事態が報じられました。*8これは、AIによって「本物に見える偽情報」の作成コストが劇的に低下し、政治家を標的とした情報工作が、選挙制度や民主主義にとって深刻な脅威となりつつあることを示しています。

    このように、地政学的リスクに伴うサイバー攻撃において、情報戦や影響工作のリスクが今後も高まると予測されることが、今回あえて「情報戦を含む」と明記された背景にあると考えられます。

    その他の脅威

    ここからは、これまでに述べた4つ以外の脅威について説明します。

    4位「システムの脆弱性を悪用した攻撃」

    ソフトウェアやシステムの脆弱性が発見されると、攻撃者は修正プログラムが提供される前に攻撃を仕掛ける「ゼロデイ攻撃」を行うことがあります。また、修正プログラム公開後であっても、適用の遅れている企業や組織を狙い、既知の脆弱性を悪用するケースも後を絶ちません。2025年に報告されたNext.jsの脆弱性「React2Shell」の事例(※ページ下部に参考情報記載)では、公表からわずか二日後に実際の攻撃が確認され、一週間以内に観測された攻撃試行回数は約140万回にも及んだとされています。*9このように攻撃者は脆弱性公開から直ちに悪用を開始するため、最新情報を常に追跡し、迅速に対応することが求められます。

    対策: 最新のセキュリティパッチを迅速に適用することが不可欠です。また、どこにどのソフトウェアが使われているかを把握するため、SBOM(ソフトウェア部品表)の導入など、脆弱性管理体制の強化が有効です。

    5位「機密情報を狙った標的型攻撃」

    標的型攻撃とは、明確な意思と目的を持った攻撃者が、特定の企業・組織・業界を狙い撃ちにするサイバー攻撃です。不特定多数への無差別な攻撃とは異なり、機密情報の窃取やシステムの破壊・停止といったゴールを定め、執拗に実行される点が特徴です。攻撃は長期間継続することが多く、ターゲットのネットワーク内部に数年間にわたり潜伏して活動する事例も確認されています。

    対策: 従業員への標的型攻撃メール訓練、メールセキュリティの強化、多要素認証の実施などが基本的です。加えて、侵入を前提とした「ゼロトラストモデル」の導入やネットワーク監視、アプリケーション許可リストの活用により、侵入の防止だけでなく早期発見と対処を可能にする体制づくりが有効です。

    7位「内部不正による情報漏えい等」

    組織の従業員や元従業員など、内部関係者による機密情報の持ち出しや削除といった不正行為を指します。これには、組織への不満や金銭目的による「悪意ある犯行」だけでなく、ルールに違反して持ち出したデータの紛失・誤操作といった、第三者への漏えいにつながる「過失」も含まれます。発生すれば、社会的信用の失墜、損害賠償、顧客離れや取引停止に加え、技術情報の流出による競争力低下など、組織に甚大な損害をもたらす恐れがあります。

    対策: アクセス権限の最小化、ログ監視の強化、定期的な従業員教育、退職者のアカウント管理徹底、そして機密情報の持ち出しルールの策定などが有効です。これらを組み合わせ、不正行為の「抑止」と「早期発見」を図ることが重要です。

    内部不正による情報漏えいついては以下の記事でも解説しています。ぜひあわせてご覧ください。「内部不正による情報漏えい-組織全体で再確認を!-

    8位「リモートワーク等の環境や仕組みを狙った攻撃」

    新型コロナウイルス対策を契機にテレワークが急速に普及し、社外からVPN経由でシステムへアクセスしたり、オンライン会議を行ったりする機会が定着しました。その結果、セキュリティ対策が不十分な自宅ネットワークや私物PCの業務利用に加え、従来は出張時や緊急時のみの使用を想定していたVPN機器等が、恒常的に使われるようになりました。こうしたテレワーク環境に脆弱性が残っていると、社内システムへの不正アクセスやマルウェア感染、Web会議の盗聴といった深刻なリスクにつながります。トレンドマイクロによれば、過去2年間に行ったランサムウェア被害に対するインシデント対応支援の中でも、およそ7割がVPN経由の事例とのことであり、VPN機器の徹底した管理が求められます。*10

    対策: ゼロトラストセキュリティの導入、VPN装置等のネットワーク機器に対するセキュリティ強化とパッチ適用、多要素認証の徹底、そして従業員へのセキュリティ教育の実施などが有効です。

    9位「DDoS攻撃(分散型サービス妨害攻撃)」

    攻撃者が乗っ取った複数の機器(ボットネット)から、特定のサーバやネットワークに対して大量の通信を送り付け、サービスを停止に追い込む攻撃です。近年は、セキュリティ対策が手薄なIoT機器が悪用され、攻撃規模が巨大化しています。また、単なる愉快犯的な妨害だけでなく、攻撃停止と引き換えに金銭を要求する「ランサムDDoS」が増加傾向にあります。これにより、ECサイトの長時間のダウンによる金銭や顧客の離脱などの機会損失や、クラウドサービスの従量課金制を悪用し、数千万円規模の過大請求を発生させる(EDoS攻撃)等、事業継続に直結する深刻な被害が発生しています。

    対策:自社設備だけでの防御は困難なため、CDN(Contents Delivery Network)やWAF(Web Application Firewall)などの対策サービスを導入し、負荷分散と遮断を行うことが基本です。あわせて、攻撃の影響を受けない非常用回線の確保やシステムの冗長化、停止時の代替サーバや告知手段を事前に整備することが重要です。

    DoS攻撃/DDoS攻撃については以下の記事でも解説しています。ぜひあわせてご覧ください。「DoS攻撃のリスクと対策:アクセス急増の原因と見分け方、サービス停止を防ぐ初動対応

    10位「ビジネスメール詐欺」

    ビジネスメール詐欺(BEC:Business Email Compromise)は、業務連絡を装った巧妙な偽メールを組織・企業に送り付け、従業員を騙して資金を詐取するサイバー攻撃です。攻撃者は準備段階として、企業内の情報を狙ったり、ウイルスを使用して業務メールを盗み見たりすることで、本物そっくりの文面やタイミングを作り上げます。

    対策: 送信ドメイン認証(DMARC・SPF・DKIM)の導入やセキュリティソフトによるフィルタリング強化といった技術的対策に加え、不審な送金依頼に対する複数人確認ルールの徹底、従業員への訓練を行い、被害の防止と早期発見を図ることが有効です。

    ビジネスメール詐欺については以下の記事でも解説しています。ぜひあわせてご覧ください。 「ビジネスメール詐欺(BEC)の脅威と企業に求められる対策

    【参考情報】

    BBSecでは

    当社では様々なご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。当当サイトSQAT® jpのお問い合わせページよりお気軽にお問い合わせください。後日営業担当者よりご連絡させていただきます。

    SQAT® 脆弱性診断

    BBSecの脆弱性診断は、精度の高い手動診断と独自開発による自動診断を組み合わせ、悪意ある攻撃を受ける前にリスクを発見し、防御するための問題を特定します。Webアプリケーション、ネットワークはもちろんのこと、ソースコード診断やクラウドの設定に関する診断など、診断対象やご事情に応じて様々なメニューをご用意しております。

    SQAT脆弱性診断サービスバナー画像

    SQAT® ペネトレーションテスト

    「ペネトレーションテスト」では実際に攻撃者が侵入できるかどうかの確認を行うことが可能です。脆弱性診断で発見したリスクをもとに、実際に悪用可能かどうかを確認いたします。

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

  • 2026年4月15日(水)14:00~15:00
    AI時代のサイバー脅威最前線 ― IPA『情報セキュリティ10大脅威2026』から学ぶ防御戦略 ―
  • 最新情報はこちら

    編集責任:木下

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


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

    Security Serviceへのリンクバナー画像
    BBsecコーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像
    ウェビナーアーカイブ動画ページバナー画像

    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コーポレートサイトへのリンクバナー画像
    セキュリティ緊急対応のバナー画像