見落としがちなIT資産がセキュリティ事故を招く？企業で起こりやすい5つの管理課題

前回記事では、IT資産管理の基本と重要性を解説しました。管理されていない端末やクラウド環境、シャドーIT、サポート終了製品など、見落とされたIT資産が被害につながるケースも少なくありません。今回は、管理が行き届かない場合に実際どのような問題が起こりやすいのか、企業で起こりやすい5つの管理課題を具体的に見ていきます。

IT資産管理の基本について知りたい方は、まず「IT資産管理とは」をご覧ください。
「IT資産管理とは？企業のセキュリティ対策で最初に取り組むべき理由を解説」

セキュリティ事故は、必ずしも高度な攻撃だけで起こるわけではありません。実際には、管理されていない端末、放置されたクラウド環境、退職者のアカウント、サポート終了ソフトウェアなど、見落としがちなIT資産がきっかけになることがあります。IT資産管理が不十分な状態では、脆弱性情報が公開されても対象資産を特定できず、インシデント発生時にも影響範囲をすばやく把握できません。

なぜ管理漏れが起こるのか

IT資産の管理漏れは、担当者の怠慢だけで起こるものではありません。むしろ、事業スピードに管理体制が追いつかないことで発生します。新しいSaaSを部門単位で契約する、検証用にクラウド環境を作成する、テレワーク用に端末を追加する、業務委託先にアカウントを付与する。こうした日常的な業務の中で、台帳更新や承認プロセスが後回しになると、実態とのズレが広がっていきます。

企業で起こりやすい5つの管理課題

台帳が更新されない

IT資産管理で最も起こりやすい課題は、資産台帳が更新されないことです。導入時には正確だった台帳も、ソフトウェア更新やクラウド環境の追加が反映されなければ、すぐに実態とずれていきます。特にExcelやGoogleスプレッドシートで管理している場合、更新担当者が限られ、現場の変更が反映されないまま時間が経過しがちです。その結果、台帳上は存在するのに実際には廃棄済みの機器、逆に台帳にはないが稼働している資産が発生します。インシデント対応時にこの状態だと、影響範囲の特定に時間がかかり、初動対応の遅れにつながります。

シャドーITが増える

シャドーITとは、情報システム部門や管理部門が把握していないIT資産やサービスが、業務目的で利用されている状態を指します。英国のサイバーセキュリティ機関NCSCでは、「シャドーITは悪意によって生まれるとは限らず、従業員が業務を進めるために、承認済みのツールやプロセスでは対応できない課題を解決しようとして発生することが多い」と説明しています。たとえば、ファイル共有が不便だから個人用クラウドストレージを使う、社内承認に時間がかかるため部門でSaaSを契約する、開発検証のために個人名義に近い形でクラウド環境を作る、といった行動です。本人に悪意がなくても、会社のセキュリティポリシー、バックアップ、アクセス制御、監査ログ、退職時のアカウント削除の対象外になるため、情報漏洩や不正アクセスのリスクが高まります。シャドーIT対策で重要なのは、単に禁止することではありません。なぜ現場が非公式な手段を使わざるを得なかったのかを把握し、業務に必要なツールを安全に使える仕組みに変えることです。

クラウド資産が把握できない

クラウド環境では、サーバやストレージ、データベース、コンテナ、API、アカウント、権限設定などが短時間で作成・変更・削除されます。オンプレミス環境のように物理的なサーバーが目に見えるわけではないため、管理対象から漏れやすいのが特徴です。検証用に作ったクラウド環境が放置され、インターネットに公開されたままになる。開発者が一時的に広い権限を付与し、その後も戻されない。ログ設定やバックアップ設定が本番環境と異なる。こうした状態は、クラウド利用が進む企業ほど起こりやすくなります。米国サイバーセキュリティ・インフラストラクチャセキュリティ庁（CISA）の「Cybersecurity Performance Goals」でも、既知の資産だけでなく、未知の資産、シャドー資産、未管理資産を特定し、新たな脆弱性への検知・対応を速めることが目的として示されています。

EOL（End of Life）・EOS（End of Service）を見逃す

サポートが終了したOS、ネットワーク機器、VPN機器、業務アプリケーション、ミドルウェアを使い続けることも、IT資産管理上の大きな課題です。サポートが終了した製品は、脆弱性が発見されても修正プログラムが提供されない可能性があります。資産台帳にサポート期限や保守期限が記録されていなければ、更新計画を立てることもできません。

EOL・EOSについては前回記事でも触れていますので、あわせてご覧ください。

また、ソフトウェア資産の構成管理まで行いたい場合、EOL・EOS対策の延長としてSBOM（ソフトウェア部品表）も重要になります。経済産業省「ソフトウェア管理に向けたSBOMの導入に関する手引 Ver.2.0」では、資産管理台帳だけでは、下位コンポーネントとして利用されるOSSなどに脆弱性が見つかった場合に、間接的な影響を検知できない場合があると説明されています。

SBOMについては、「SBOMとは？ソフトウェア部品表の基本と企業が導入すべき理由」でも解説しています。あわせてご覧ください。

部門ごとに管理している

IT資産管理が部門ごとに分断されていることも、企業でよく見られる課題です。情報システム部門はPCとネットワーク機器を管理し、開発部門はクラウド環境を管理し、総務部門はリース契約を管理し、各事業部がSaaS契約を管理している。このような状態では、全社としてどのIT資産が存在するのかを把握できません。部門ごとの管理は、現場のスピードを保つうえでは便利です。しかし、セキュリティ事故が起きたときには、誰が責任者なのか、どの情報が保存されているのか、どの範囲に影響があるのかが分からなくなります。特に、SaaSやクラウドサービスでは、管理者権限を持つ担当者が異動・退職した後に、契約やアカウントだけが残り続けるケースもあります。

管理課題を解決するポイント

IT資産管理の課題を解決するには、台帳を作るだけでは不十分です。重要なのは、資産が増える、変わる、使われなくなるタイミングで、台帳や管理システムが自然に更新される運用を作ることです。まず、IT資産管理の対象範囲を明確にします。PCやサーバだけでなく、クラウド環境、SaaS、アカウント、ネットワーク機器、ソフトウェア、ライセンスまで含めるかを決めます。次に、資産ごとに管理責任者を定めます。所有者が曖昧な資産は、脆弱性対応や費用管理、廃棄判断が遅れやすくなります。そのうえで、購買、入社、異動、退職、クラウド作成、SaaS契約、機器廃棄といった業務フローにIT資産管理を組み込みます。ツールを導入する場合も、単体で完結させるのではなく、ID管理、EDR、MDM、脆弱性管理、クラウド管理と連携させることで、実態に近い情報を保ちやすくなります。

課題を解決する具体的な運用方法については「IT資産管理を効率化する方法とは？担当者が押さえたい運用のポイント」をご覧ください。

まとめ：見えていないIT資産は、守れない

IT資産管理の課題は、すぐに大きな障害として表面化するとは限りません。しかし、管理漏れ、シャドーIT、クラウド資産の放置、サポートが終了した製品・機器の見逃し、部門ごとの分断が積み重なると、セキュリティ事故の温床になります。

次回は、こうした課題を解決するための具体的な運用方法について解説します。

【参考情報】

NCSC「Shadow IT guidance」（https://www.ncsc.gov.uk/guidance/shadow-it）

編集責任：木下

IT資産管理を実践するポイントを詳しく学びたい方へ

弊社では、7月22日（水）14時から、IT資産管理をテーマにしたウェビナーを開催します。IT資産の可視化や管理の進め方、見落としがちなリスクへの対策などを分かりやすく解説しますので、ぜひご参加ください。

※外部サイトにリンクします。

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

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

2026年4月7日2026年5月7日

脆弱性管理とは？企業が行うべき脆弱性管理の基本と実践手順【2026年版】

企業のIT環境は、もはや社内サーバーやネットワーク機器だけで完結しません。業務システムはクラウドへ移行し、開発現場ではOSSの利用が当たり前になり、SaaSやコンテナ、API連携を含めた複雑な構成が一般化しています。こうした環境では、ひとつの脆弱性が単独の問題にとどまらず、情報漏えい、業務停止、サプライチェーン全体への影響へとつながることがあります。だからこそ今、多くの企業にとって重要になっているのが「脆弱性管理」です。

脆弱性管理とは、脆弱性を見つけることそのものではありません。自社にどの資産があり、どこに弱点があり、それがどの程度危険で、いつまでに何を直すべきかを継続的に判断し、実際に改善し続ける運用を指します。本記事では、脆弱性管理の基本から、企業が実務で押さえるべき流れ、ツールの考え方、クラウドやOSS時代に欠かせないSBOMの活用まで、2026年時点の実務に沿って整理します。

脆弱性管理とは

脆弱性管理とは、システムやソフトウェア、クラウド環境、ネットワーク機器などに存在するセキュリティ上の弱点を継続的に把握し、評価し、修正し、再確認する一連の運用です。単発の診断や一度きりの点検ではなく、変化し続けるIT環境に合わせて回し続けることに意味があります。CISAも、脆弱性管理を「脆弱性や悪用可能な状態の発生頻度と影響を減らす取り組み」と位置づけています。

脆弱性管理では、日々公開される脆弱性情報を継続的に確認することが重要です。多くの脆弱性は CVE（Common Vulnerabilities and Exposures） という識別番号で管理されています。CVEの仕組みについては、以下の記事で詳しく解説しています。
「CVEとは？脆弱性情報の共通識別番号を解説」

CVEは、公開されたサイバーセキュリティ上の脆弱性を識別し、共通の参照先として扱うための仕組みです。一方、NVDはそのCVE情報に対してCVSSなどの評価情報や関連データを付与し、脆弱性管理の自動化や優先順位付けに役立つデータベースとして機能しています。つまり実務では、「CVEで対象を識別し、NVDやベンダー情報で内容と深刻度を確認する」という流れが基本になります。

現在の企業システムは、オンプレミス環境だけでなく、AWS・Azure・Google Cloud などのクラウド環境やSaaSサービスを組み合わせて構築されるケースが増えています。そのため、脆弱性管理はサーバーやネットワークだけでなく、クラウド環境やソフトウェアコンポーネントも含めて実施する必要があります。クラウドでは、基盤の一部は事業者が管理していても、設定、アクセス権、ゲストOS、コンテナイメージ、アプリケーションなどは利用企業側の責任範囲に残るためです。AWS、Microsoft、Google Cloudはいずれも共有責任モデルを明示しており、利用者側の継続的な管理を前提にしています。

なぜ企業に脆弱性管理が必要なのか

企業に脆弱性管理が必要な最大の理由は、脆弱性が「見つかっただけの情報」ではなく、「実際に悪用される入口」になっているからです。公開された脆弱性のすべてが直ちに攻撃に使われるわけではありませんが、CISAは実際に悪用が確認された脆弱性を Known Exploited Vulnerabilities（KEV） Catalog として公開し、組織に優先対応を促しています。つまり現代の脆弱性管理では、公開情報を眺めるだけでなく、「いま悪用されているか」「自社に影響するか」を見極めることが重要です。

脆弱性を放置するリスクも明確です。攻撃者は、修正が遅れたVPN機器、公開サーバー、業務アプリケーション、ミドルウェア、コンテナ環境などを足がかりに侵入し、そこから権限昇格や横展開を進めます。問題は、重大な脆弱性があっても、自社資産を把握できていなければ「影響を受けているのに気づけない」ことです。脆弱性管理は、修正作業の前段として、自社に何が存在しているかを見える化する意味でも不可欠です。

さらに、近年はOSS利用の拡大によって、ソフトウェアサプライチェーン全体のリスク管理が重要になっています。NTIAはSBOMを、ソフトウェアを構成する各種コンポーネントとそのサプライチェーン上の関係を記録する正式な記録と説明しています。OSSライブラリや依存パッケージに脆弱性が含まれていた場合、アプリケーション本体に問題がなくても、企業システム全体に影響が及ぶ可能性があります。これが、いわゆるソフトウェアサプライチェーンリスクです。

クラウド利用の拡大も、脆弱性管理の必要性をさらに高めています。クラウド環境では、サーバーを一度構築して終わりではなく、構成変更、イメージ更新、コンテナ再配備、アクセス制御変更などが高頻度で発生します。そのため、脆弱性管理を継続的に実施しなければ、未更新のソフトウェアや脆弱なイメージ、設定不備がそのまま攻撃対象になる可能性があります。共有責任モデルのもとでは、クラウド事業者がすべてを守ってくれるわけではありません。自社が責任を持つ範囲を理解し、そこを継続的に点検する必要があります。

脆弱性管理の基本プロセス

脆弱性管理の基本プロセスは、一般に以下のような流れです。

脆弱性の発見
脆弱性評価
修正
検証

ただし実務では、前提としてソフトウェア資産の把握が欠かせません。なぜなら、何を保有しているか分からない状態では、脆弱性情報を受け取っても影響判断ができないからです。NVDのような脆弱性データベースは、脆弱性管理の自動化や評価に使える標準化データを提供していますが、それを生かすには自社資産との突合が必要です。

脆弱性の発見は、公開情報の確認だけでなく、スキャンツール、構成管理情報、ベンダーアドバイザリ、クラウドのセキュリティ機能など、複数の情報源を組み合わせて行います。次に必要になるのが評価です。ここではCVSSのような一般的な深刻度だけでなく、インターネット公開の有無、業務影響、悪用実績、代替策の有無、修正難易度などを踏まえて、自社にとっての優先度を決める必要があります。NVDも、CVSSは深刻度の定性的な指標であり、リスクそのものではないと明示しています。

その後、実際に修正を行います。修正方法は、パッチ適用、設定変更、バージョンアップ、アクセス制御の見直し、機能停止、ネットワーク遮断などさまざまです。最後に、修正後の検証を実施し、本当に脆弱性が解消されたか、別の不具合を生んでいないかを確認します。この「修正して終わりにしない」ことが、脆弱性管理を単なる作業ではなく運用として成立させるポイントです。脆弱性管理では、まず自社のIT資産を正確に把握することが重要です。対象にはサーバーやネットワークだけでなく、クラウド環境、利用しているOSSライブラリなども含まれます。

IT資産管理と脆弱性管理の関係については、以下の記事で詳しく解説しています。
「脆弱性管理とIT資産管理とは？サイバー攻撃から組織を守る取り組み」

近年では SBOM（Software Bill of Materials） を利用してソフトウェア構成を可視化する企業も増えています。SBOMは、ソフトウェアに何の部品が含まれているかを一覧化する考え方で、影響範囲の特定や依存関係の把握に有効です。
「SBOMとは？ソフトウェア部品表の基本と企業が導入すべき理由」

脆弱性管理のフロー（実務）

実務に落とし込むと、脆弱性管理の流れは以下のような順番で整理することができます。

脆弱性情報の収集
クラウド・OSSへの影響確認
優先度判断
修正
再確認

まず行うべきは、CVE、ベンダーアドバイザリ、クラウドベンダー通知、各種セキュリティ情報の収集です。ここで漏れがあると、そもそも対応のスタート地点に立てません。CISAは、実際に悪用が確認された脆弱性についてKEV Catalogの確認と優先的な是正を強く推奨しています。

次に必要なのが、収集した情報が自社環境に関係するかどうかの確認です。オンプレミス機器だけなら比較的見通しが立ちますが、現在はクラウド上のワークロード、コンテナ、OSSライブラリ、CI/CDで取り込んだ部品まで視野に入れなければ、実態を取り逃がします。とくにOSS脆弱性は、アプリケーション本体よりも深い依存関係に潜んでいる場合があり、SBOMやSCAの仕組みがないと把握が難しくなります。

優先度判断では、CVSSの高さだけで対応順を決めないことが重要です。CVSSは比較の基準になりますが、公開サーバーにあるのか、認証が必要なのか、すでに悪用実績があるのか、業務停止時の影響はどれほどかによって、実際の対応順は変わります。NVDもCVSSをリスクそのものではないと説明しており、KEVのような実悪用情報と組み合わせて判断するのが現実的です。

修正段階では、パッチ適用だけに視野を限定しないことが大切です。クラウド環境では、OSやミドルウェアの更新に加え、コンテナイメージの差し替え、設定変更、公開範囲の見直し、権限調整なども重要な対策になります。修正後は再スキャンや設定確認を行い、実際に解消されたことを確認します。ここで検証が不十分だと、「対応したつもり」で終わってしまい、後になって再発見されることがあります。

脆弱性管理では、脆弱性を発見するだけでなく、発見された脆弱性に対して迅速に対応することが重要です。適切な脆弱性対応を行わなければ、攻撃者に悪用され、情報漏えいやシステム停止などの重大なインシデントにつながる可能性があります。脆弱性対応の基本的な流れや実務での対応方法については、以下の記事で詳しく解説しています。
「脆弱性対応とは？CVE対応とパッチ管理の実務フロー」

近年ではクラウド環境やOSSライブラリに含まれる脆弱性の影響調査も重要になっています。SBOMを利用すると、影響範囲を迅速に把握できます。

脆弱性管理ツールの種類

脆弱性管理を実務で回すには、ツールの力を借りることが現実的です。ただし、ひとつの製品で全領域を完全にカバーできるとは限りません。一般的な脆弱性スキャナーは、ネットワーク機器、サーバー、OS、ミドルウェア、Webアプリケーションの既知脆弱性を見つけるのに有効ですが、OSSライブラリの依存関係やソフトウェア部品表までは十分に扱えないことがあります。そこで、管理ツール、クラウドセキュリティツール、SBOM管理ツール、SCAツールなどを役割ごとに組み合わせる設計が必要になります。

たとえば、CSPMやCNAPPのようなクラウド向けツールは、クラウド設定やワークロードの状態を継続的に可視化するのに向いています。一方、SCAはアプリケーションが依存しているOSSコンポーネントを洗い出し、既知脆弱性との突合を支援します。SBOM管理ツールは、その構成情報を継続管理し、影響調査を効率化する役割を持ちます。2026年の脆弱性管理では、ネットワークやサーバーだけを見ていても不十分で、クラウドとソフトウェアサプライチェーンまで含めた多層的な可視化が必要です。

OSSの脆弱性を管理するために、SCA（Software Composition Analysis）ツールやSBOM管理ツールを導入する企業も増えています。これは、ソフトウェアの構成部品とその依存関係を可視化しなければ、OSS由来の脆弱性が自社に影響するかどうかを迅速に判断しにくいためです。NTIAも、SBOMをソフトウェア構成要素の透明性向上に役立つ仕組みとして整理しています。

SCA（Software Composition Analysis）ツールとは
ソフトウェアに含まれるオープンソースや外部ライブラリの構成要素を解析し、既知の脆弱性やライセンスリスクを可視化するセキュリティツールです。依存関係を自動的に検出し、CVEなどの脆弱性データベースと照合することで、潜在的なリスクを早期に特定できます。また、ライセンス違反の有無も確認でき、コンプライアンス対応にも有効です。開発プロセスに組み込むことで、セキュアで安全なソフトウェア開発を支援します。

脆弱性スキャンについてはこちらの記事でも詳しく解説しています。
「脆弱性スキャンとは？脆弱性診断ツールの選び方と導入ポイント」

企業の脆弱性管理の課題

多くの企業が脆弱性管理に苦労する理由は、脆弱性そのものより、管理対象の広がりにあります。

IT資産の把握

まず大きいのが、IT資産の把握が難しいことです。クラウド移行、テレワーク、SaaS利用、部門独自導入のツール、コンテナ活用が進むと、情報システム部門が把握していない資産が生まれやすくなります。この状態では、脆弱性情報を受け取っても、自社への影響有無を正確に判断できません。

OSS依存関係の管理

現代のソフトウェアは、直接導入しているライブラリだけでなく、その下位の依存関係にも数多くの部品を抱えています。表面的には安全に見えても、深い階層に脆弱なコンポーネントが含まれていることは珍しくありません。

SBOMの未整備

SBOMが未整備だと、こうした影響範囲調査に時間がかかり、対応の遅れにつながります。

クラウド環境の可視化不足

クラウドでは、責任分界が従来のオンプレミスとは異なり、サービス形態によって利用者側の責任範囲が変わります。そのため、「クラウド事業者が面倒を見ているはず」と誤解してしまうと、更新漏れや設定不備を放置しやすくなります。共有責任モデルを前提に、自社の管理範囲を明確にしなければ、脆弱性管理は形骸化します。

OSS利用時に重要な脆弱性管理（SBOMの活用）

OSSの活用は、開発効率や品質向上の面で大きなメリットがありますが、その一方で脆弱性管理を複雑にします。理由は明快で、企業が自分で一から書いていないコードであっても、最終的に自社サービスや製品の一部として責任を負うからです。OSS由来の脆弱性は、アプリケーション本体ではなく依存パッケージに潜んでいることも多く、目視や台帳だけで追いきるのは現実的ではありません。

ここで重要になるのがSBOMです。NTIAはSBOMを、ソフトウェアを構成する各種コンポーネントとサプライチェーン上の関係を記録する正式な記録と定義しています。これを整備しておけば、新たな脆弱性が公表された際に、「自社のどのシステムに、その部品が含まれているか」を調べやすくなります。結果として、影響調査の初動が速くなり、不要な全件調査や属人的な確認作業を減らせます。

SBOMは、単に監査対応のために作る資料ではありません。脆弱性管理の実務で使えてこそ意味があります。たとえば、SCAツールで依存関係を検出し、その情報をSBOMとして管理し、脆弱性公表時に突合するという流れが定着すれば、OSS脆弱性への対応速度と精度を高めやすくなります。今後の企業システムでは、OSS利用時の脆弱性管理をSBOM抜きで考えることは難しくなっていくでしょう。

脆弱性管理を効率化する方法

脆弱性管理を効率化する方法はいくつかあります。

資産管理の自動化

資産台帳を手作業で維持する運用では、クラウドやコンテナ、SaaSの増減に追いつけません。CMDB、クラウド資産可視化、ID管理、EDRやMDMの情報などを組み合わせて、現時点の資産情報を継続的に更新できる状態を目指す必要があります。資産情報が整えば、脆弱性情報との突合精度も上がります。

OSS脆弱性監視

OSS脆弱性監視の仕組みを作ることも重要です。開発時点だけでなく、運用中のアプリケーションについても、依存ライブラリの脆弱性を継続監視しなければなりません。脆弱性管理をインフラ部門だけの仕事にせず、開発部門やDevOps運用の中に組み込むことが、今の実務では不可欠です。

SBOMによるソフトウェア構成管理

SBOMによるソフトウェア構成管理を取り入れることで、影響調査の速度と精度をさらに高められます。SBOMが整っていれば、新たなCVEが公表された際にも、対象ソフトウェアの所在確認を短時間で進めやすくなります。加えて、KEVのような実悪用情報を監視し、CVSSだけでなく悪用実績も含めて優先順位を決める運用にすれば、限られた人員でも効果的に対応しやすくなります。脆弱性管理を効率化するとは、単にツールを増やすことではなく、「見つける」「判断する」「直す」を早く回せる仕組みへ変えることです。

まとめ

脆弱性管理とは、脆弱性を発見する作業ではなく、自社のIT資産、クラウド環境、OSSコンポーネントを継続的に把握し、影響を判断し、優先順位をつけて修正し、再確認する運用そのものです。2026年の企業環境では、オンプレミスだけを見ていては不十分で、クラウド、SaaS、コンテナ、OSSまで含めた視点が欠かせません。とくに、実際に悪用される脆弱性への対応と、SBOMを活用したソフトウェア構成の可視化は、これからの脆弱性管理の重要な柱になります。

まず取り組むべきなのは、完璧な仕組みを一気に作ることではなく、自社の資産を洗い出し、脆弱性情報を収集し、優先度を判断し、修正後に確認するという基本サイクルを止めずに回すことです。そのうえで、クラウド可視化、SCA、SBOM管理などを段階的に取り入れていけば、脆弱性管理は現場で機能する実践的な仕組みに育っていきます。

【関連ウェビナーのご案内】
本記事では、脆弱性スキャンとは何か、脆弱性診断との違い、ツール比較のポイント、導入時の考え方までを整理しました。次回、5月20日（水）14時からの開催のウェビナーでは、AssetViewとFutureVulsのメーカーが登壇し、各領域の役割をどのように整理し、どのように連携させれば実効性ある脆弱性管理が実現できるのか、解説します。脆弱性管理の考え方について深くを理解されたい方は、ぜひご参加ください。

その他のウェビナー開催情報はこちら

BBSecでは

BBSecでは以下のようなご支援が可能です。お客様のご状況に合わせて最適なご提案をいたします。

自ステムの状態を知る

SQAT^®脆弱性診断サービス

サイバー攻撃に対する備えとして、BBSecが提供する、SQAT脆弱性診断サービスでは、攻撃者の侵入を許す脆弱性の存在が見逃されていないかどうかを定期的に確認することができます。自組織の状態を知り、適切な脆弱性対策をすることが重要です。

アタックサーフェス調査サービス

インターネット上で「攻撃者にとって対象組織はどう見えているか」調査・報告するサービスです。攻撃者と同じ観点に立ち、企業ドメイン情報をはじめとする、公開情報（OSINT）を利用して攻撃可能なポイントの有無を、弊社セキュリティエンジニアが調査いたします。

編集責任：木下

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

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。

2026年2月17日2026年3月30日

特別寄稿／AI時代のセキュリティ戦略：トライコーダ上野宣氏が語る、攻撃と防御の最前線【後編】

生成AIの進化により、サイバー攻撃と防御の双方でAI活用が加速する現代。前編では、AIがもたらす脅威の変化と、企業が直面する新たなリスク構造について、上野宣氏に解説いただきました。

後編では、こうした環境変化を踏まえ、企業はどのようにセキュリティ戦略を再構築すべきか、その具体的な方向性と実践のポイントについて掘り下げます。

前編「AIが変える攻撃の現状と、防御側AI活用のリアル」はこちら

AI時代に増えるリスクと、経営が取るべきアクション

企業が直面するAIセキュリティリスク

AIを活用する企業は、攻撃の標的になるだけでなく、自社が導入したAIがリスクの起点になる可能性も抱えます。ここで重要なのは、「AIを守る」という視点です。 AIは、データアクセスを統合し、業務フローに深く入り込みます。言い換えると、AIは便利なツールであると同時に、新たなリスクになり得ます。

以下では、AI活用が進む現場で起きやすいリスクを、実務の観点で整理します。

生成AI利用による情報漏えい・シャドーAI

現場が便利さを優先して、個人アカウントの生成AIに機密情報を入力してしまう、いわゆるシャドーAIは、シャドーITと同じ構図で広がります。入力データの扱い（学習に使われるのか、保存されるのか）、ログに残るのか、社外に送信されるのか。利用ルールと技術的な制御がないと、情報資産の漏えいに繋がる可能性があります。

対策は利用を禁止することではありません。ほとんどの従業員は悪意を持ってシャドーAIをするわけではなく、ビジネスに活用しようとしているだけです。現場の生産性要求は止められないからこそ、次のような使えるガードレールが必要です。

会社が認めるAI利用チャネル（法人契約、社内AI、承認済みツール）を用意する
機密分類に応じて「入力禁止」「要マスキング」「要承認」などを定義する
DLP、プロキシ、CASB等で、持ち出し・入力を技術的に抑止する（可能な範囲で）
利用ログを残し、例外管理を行う

プロンプトインジェクション／RAG汚染：AIアプリ特有の攻撃面

社内ナレッジ検索（RAG）やAIチャットボットを業務に組み込むと、従来のWeb脆弱性とは別の攻撃面が生まれます。

プロンプトインジェクション：悪意ある指示でAIの挙動を変え、機密を引き出す
RAG汚染：参照ドキュメントに誘導文を仕込み、誤誘導・情報漏えいを誘発
権限モデルの破綻：AIが見えてはいけない情報を横断的に回答してしまう
ツール連携の悪用：AIに「メール送信」「DB更新」「ワークフロー実行」などを許すと、誤操作や悪用の影響範囲が一気に広がる

こうしたリスクは、アプリの仕様・権限・データ設計の問題として現れるため、情シス・開発・セキュリティが一体で設計し直す必要があります。

学習データ汚染・モデル改ざん・信頼できない出力

モデルそのもの、あるいは学習・評価・運用のパイプラインが攻撃されると、判断の信頼性が崩れます。たとえば、学習データやナレッジに悪意ある情報が混ざる、モデルの設定が変えられる、評価（テスト）が形骸化する。こうした問題は、結果として「AIが間違った結論を自信満々に出す」形で表面化します。業務に組み込むほど、誤りは事故になります。

重要業務ほど根拠（参照元）を提示できる設計が必要
出力の正しさを検証できない領域では人の確認を前提にする
仕様変更・データ更新・モデル更新は変更管理（レビュー、承認、ロールバック）に乗せる

モデル盗難・データ推定・API悪用

外部APIや自社モデルを提供する側になると、今度は「モデルを盗まれる」「APIを乱用される」「出力から学習データが推定される」といった論点が生まれます。ここでは、認証・認可、レート制限、監査ログ、鍵管理、テナント分離など、従来のAPIセキュリティの要諦がそのまま効いてきます。

ガバナンス・法令・説明責任

AIは出力が意思決定に影響するため、誤りがビジネス事故に直結します。個人情報・機密情報・著作権・差別・説明責任など、論点は多岐にわたります。

AIの利用に関する法規制も急速に整備されつつあり、2024年8月にはEUでArtificial Intelligence Act（欧州AI規制法）が施行されました。違反時の罰則は最大で全世界年間売上高の7%または3,500ユーロと非常に厳しいものです。

海外取引がある企業であるほど、規制動向を踏まえたガバナンスが必要になります。重要なのは、法令対応を法務任せにせず、セキュリティと一体で運用設計に落とすことです。

経営層・CISOが取るべきアクション：AIセキュリティを“経営課題”にする

AI時代のセキュリティ戦略は、現場の頑張りだけでは成立しません。経営が意思決定すべきポイントは、概ね次の3つに分けられます。

方針（何を守り、どこまで許容するか）

AIの利用目的と禁止事項を明文化（機密分類と紐付ける）
人が最終責任を持つ領域を定義（例：与信、採用、重要判断、法的判断）
委託・SaaS・外部APIの利用条件（データの持ち出し、学習利用、ログ保管、保存期間）
例外申請の道を用意し、現場がこっそり使う状況を減らす

体制（誰が意思決定し、運用を回すか）

AIガバナンス（責任者・審査プロセス・例外管理）の設置
CISO/CSIRT/SOCとAI開発・運用の接続（棚卸し・脅威モデリング・運用手順）
インシデント対応計画の更新（AI由来の誤回答、漏えい、改ざん、なりすましを含める）
監査・品質・法務・広報も巻き込み、事故時の説明責任を担保する

実装（どう測り、どう改善するか）

AIアプリのセキュリティ評価（権限設計、ログ、監査、耐プロンプト攻撃、データ境界）
継続的なテストと監視（レッドチーミング、監視指標、評価データ更新）
教育の刷新（AI時代のフィッシングやディープフェイクを含む訓練）
サードパーティ評価（ベンダーのデータ取り扱い、透明性、監査可能性）

ここで、経営層・CISOが最初の一手として取り組みやすいのが、「AI利用の棚卸し」です。「誰が、どのAIを、何の業務で、どんなデータを扱っているか」を把握できない限り、リスク評価も投資判断もできません。

棚卸しの結果をもとに、次のような優先順位付けを行います。

高優先：機密データ×外部AI×自動実行（ツール連携）
事故時の影響が大きく、設計変更が必要になりやすい領域
中優先：社内AI×業務支援（要約・検索）
ルールと権限、ログ、監査で事故を起こしにくい設計にする
低優先：公開情報×個人利用（学習目的）
教育・ガイドライン中心でコントロールする

「AI導入＝生産性向上」の議論は進みやすい一方で、「AI導入＝新しいリスクの導入」という議論は後回しになりがちです。だからこそ、経営とCISOが同じテーブルで、“AIで守る”と“AIを守る”を同時に設計することが、競争力に直結します。

CISO/経営が迷わないための90日ロードマップ

AIセキュリティはやることが多く見えますが、最初から完璧を目指すと止まります。ここでは、取り掛かりやすく、成果が見えやすい90日プランを例示します。

0〜30日：現状把握とルール整備（止血）
- AI利用の棚卸し（部署・用途・データ種類・外部/社内）
- 重要データの分類と、AI入力可否ルール（暫定版でもよい）
- 決裁・送金・機密共有の“なりすまし耐性”点検（電話確認、二要素、手順の固定化）

31〜60日：AIアプリの設計レビューと運用の接続（再発防止）
- RAG/チャットボット等の権限設計レビュー（最小権限、データ境界、回答制御）
- 監査ログ設計（入力・参照・出力・実行の記録）
- SOC/CSIRTがAI起因の事故を扱えるよう、手順と訓練シナリオを更新

61〜90日：継続改善の仕組み化
- 定期評価（レッドチーミング/診断/演習）の計画化
- KPIの設定（例：棚卸しカバー率、AI入力ルール遵守率、初動時間、復旧時間）
- ベンダー・委託先に対する要求事項（データ取扱い、監査、透明性）のテンプレ化

AIは導入のスピードが速い分、暫定のガードレールを早く敷き、走りながら改善する発想が現実的です。

技術責任者向け AIアプリを“事故らせない”ための設計ポイント

CTO/開発責任者の立場では、「AIを入れるかどうか」より「AIをどう組み込むか」が勝負になります。特に事故を起こしやすい論点は、次の5つです。

権限とデータ境界：AIの回答が横断参照にならないよう、検索・参照段階でアクセス制御する
根拠提示：可能な限り参照元（文書ID、URL、更新日時）を出し、検証可能性を担保する
入力と出力の制御：機密らしき文字列のマスキング、出力フィルタ、禁止操作の明確化
ツール連携の安全化：実行系は二重確認・最小権限・レート制限・停止スイッチを前提にする
監査ログと再現性：入力・参照・出力・実行を記録し、事故時に再現できるようにする

便利さは機能追加で得られますが、信頼性は設計でしか得られません。AIを業務に組み込むほど、セキュリティは後付けでは間に合わなくなります。

次の5年で起きること、起きないこと

今後数年で見えているのは、次の潮流です。

攻撃の自動化はさらに進む：偵察から侵入、横展開まで“部分最適”が積み上がる
防御は「検知」から「耐性設計」へ：侵入前提で、権限・ネットワーク・データの分離を徹底する
AIセキュリティが専門領域として独立：従来のAppSec/CloudSecに、AI特有の評価観点が加わる
規制・顧客要求が増える：説明責任、監査、データ管理が調達条件になる
人材の取り合いが起きる：AI×セキュリティ×事業の三領域を理解する人材が不足する

AI関連のセキュリティは、単一の製品カテゴリに収束しにくい領域です。LLMの挙動評価、プロンプト攻撃耐性、データ境界、監査ログ、運用プロセスなど論点が横断的だからです。そのため今後は、ツール導入に加えて、第三者による評価（診断・レビュー・レッドチーミング）と、運用を回す支援（監視・手順整備）がセットで求められる場面が増えていくでしょう。

一方で、変わらないものもあります。資産管理、脆弱性管理、特権管理、バックアップ、監視、訓練などのいわゆる基本は、AI時代でも依然として高い効果を示します。AIがさまざまな能力を拡張してくれる機能を提供するため、基本が弱い組織ほど被害も増幅されます。

まとめ：これからのセキュリティに携わる人へ

攻撃も防御もAI時代に突入し、企業は「AIで守る」だけでなく「AIを守る」視点を持つことが不可欠になりました。重要なのは、AIを恐れることでも、AIに依存することでもありません。現場の運用と、経営の意思決定をつなぎ、継続的に改善できる仕組みを作ることです。

そして、これからセキュリティ業界に携わりたい人、すでに現場で経験を積みステップアップしたい人に伝えたいのは、AIが広がるほど「基礎」が価値を増すという事実です。攻撃者がAIで効率化するほど、守る側には、設計・運用・検証の地味な力が求められます。AIは学習すれば追いつけますが、現場の勘所である何を優先し、どこに投資し、どう回すかは、積み上げでしか身につきません。

最後に、AI時代のセキュリティを一言で表すなら、「スピードの時代」です。攻撃のスピードが上がる以上、防御も“検知してから考える”では遅れます。平時からの設計（境界・権限・ログ）と、迷わず動ける手順（初動・連絡・隔離・復旧）が、被害の差になります。AIはそれを加速してくれる道具にも、穴を広げる要因にもなります。だからこそ、今このタイミングで戦略を更新する価値があります。

付録：企業が「今すぐ」着手できるチェックリスト

AI利用の棚卸し（ガバナンスの入口）

生成AIの利用実態（シャドーAI）を把握できているか
どの部署が、どのAI（外部/社内）を、どの業務に使っているか一覧化できているか
取り扱うデータ（機密/個人情報/顧客情報/ソースコード等）を分類できているか
外部AIに投入するデータのマスキング・匿名化・要約など、代替手段を用意しているか

AIアプリ（RAG/チャットボット等）の設計・運用

権限（誰が何にアクセスできるか）をAIの回答レベルまで落とし込めているか
参照データの取り込み経路は管理され、改ざん検知やレビューがあるか
監査ログ（誰が何を聞き、何を参照し、何を出力したか）を残せているか
ツール連携（実行系）を許す場合、二重確認・最小権限・停止スイッチがあるか

AI時代の“人”への対策

フィッシング訓練はAI時代（自然文・音声・偽装）に合わせて更新したか
なりすまし対策（決裁・送金・機密共有の手順）を見直したか
インシデント対応訓練で「深夜の役員なりすまし」「AIの誤回答による事故」などを扱っているか

ブロードバンドセキュリティからのご案内

AI活用が進むほど、攻撃面は「システム」だけでなく「データ」「運用」「人」に広がります。まずは現状の棚卸しと、優先順位付けが重要です。ブロードバンドセキュリティ（BBSec）では、脆弱性診断（Web/アプリ/クラウド）に加え、運用設計・監視・セキュリティ運用支援まで、状況に合わせてワンストップでご支援可能です。必要に応じて、AI導入・AIアプリ運用に伴うリスクの洗い出しや、運用プロセスの整備もご相談いただけます。

―END―
【前編】「AIが変える攻撃の現状と、防御側AI活用のリアル」はこちら

執筆：上野宣氏
株式会社トライコーダ代表取締役
奈良先端科学技術大学院大学で山口英教授のもと情報セキュリティを専攻、2006年にサイバーセキュリティ専門会社の株式会社トライコーダを設立。2019年より株式会社Flatt Security、2022年よりグローバルセキュリティエキスパート株式会社、2025年より株式会社ブロードバンドセキュリティの社外取締役を務める。あわせて、OWASP Japan代表、一般社団法人セキュリティ・キャンプ協議会理事、NICT CYDER推進委員などを歴任し、教育・人材育成分野にも尽力。情報経営イノベーション専門職大学（iU）客員教員。

編集責任：木下・彦坂

スペシャル記事 TOPに戻る
バックナンバー TOPに戻る

年二回発行されるセキュリティトレンドの詳細レポート。BBSecで行われた診断の統計データも掲載。

サービスに関する疑問や質問はこちらからお気軽にお問合せください。

2026年1月29日2026年3月2日

なぜ取引先経由で情報漏えいが起きるのか ―国内で相次ぐサプライチェーン攻撃の実態―

近年、「自社に不正アクセスはなかったのに情報が漏えいした」という状況が増えています。その多くは、取引先や委託先、外部サービスを経由したサプライチェーン攻撃が原因です。本記事では、なぜこうした“取引先経由”の情報漏えいが起きやすいのか、国内で実際に起きている事例や背景をもとに整理します。攻撃の構造を理解することで、見えにくいリスクに気づく視点を持つことができます。

こうしたリスクを前提に、委託先や外注先のセキュリティをどこまで確認すべきか悩む企業も少なくありません。実務の判断ポイントについては、以下の記事で整理しています。
「委託先・外注先のセキュリティはどこまで確認すべきか」

自社が原因でなくても、情報漏えいは起きてしまう時代

近年、「自社システムに不正アクセスはなかった」と説明される情報漏えい事故が国内で相次いでいます。調査を進めると原因は自社ではなく、取引先や外部サービスを経由した不正アクセスだった、というケースが少なくありません。こうした攻撃はサプライチェーン攻撃と呼ばれ、いま日本企業にとって最も現実的なセキュリティリスクの一つになっています。特にSaaSや外部委託、API連携が当たり前になった現在、このリスクは業種や企業規模を問わず存在します。

サプライチェーン攻撃とは何か

サプライチェーン攻撃とは、標的となる企業そのものではなく、取引先・委託先・連携している外部サービスを踏み台に侵入する攻撃手法です。サプライチェーン攻撃の全体像や基本的な考え方については、以下の記事で整理しています。あわせてぜひご覧ください。
「サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―」

なぜ今、国内でサプライチェーン攻撃が増えているのか

背景にあるのは、企業活動のデジタル化と外部依存の加速です。業務効率化のためにSaaSを導入し、外部ツールとAPIで連携し、専門業務を外注することは、今や珍しいことではありません。一方で、こうした外部接点が増えるほど、攻撃者にとっての「侵入口」も増えていきます。特に、委託先や小規模ベンダーでは十分なセキュリティ対策が取られていないケースもあり、結果としてそこが狙われやすくなります。さらに最近では、認証情報の使い回しや権限設定のミスを自動的に探し出す攻撃手法も増えており、従来型の対策だけでは気づかないうちに侵入されるリスクが高まっています。

国内で実際に起きているサプライチェーン攻撃の特徴

国内で報告されているサプライチェーン攻撃の多くには共通点があります。それは、自社システムが直接破られたわけではなく、正規の連携機能や委託先のアクセス権限が悪用されている点です。そのため、ログを見ても不正アクセスだと気づきにくく、発覚までに時間がかかることがあります。結果として、数万件から数十万件規模の個人情報や顧客データが流出して初めて問題が表面化する、という事態につながります。サプライチェーン攻撃が怖いのは、まさにこの「想定外の経路」から被害が発生する点にあります。

サプライチェーン攻撃の国内事例や攻撃手口については、以下の記事でも解説しています。こちらもあわせてぜひご覧ください。
「事例から学ぶサプライチェーン攻撃 -サプライチェーン攻撃の脅威と対策2-」

サプライチェーン攻撃が企業にもたらす影響

この種の攻撃によって発生するのは、単なるシステムトラブルではありません。個人情報漏えいによる顧客からの信頼低下、取引先との関係悪化、場合によっては契約違反や損害賠償の問題に発展することもあります。近年では、「原因が委託先にあった」と説明しても、情報管理責任そのものは発注元企業にあると判断されるケースが増えています。サプライチェーン攻撃は、企業の信用そのものを揺るがすリスクだと言えるでしょう。

企業が今すぐ考えるべきサプライチェーン対策

まず重要なのは、自社がどのような外部サービスや委託先とつながっているのかを正確に把握することです。意外と、過去に導入したまま使われていないSaaSや、誰が管理しているのか分からない連携設定が残っていることも少なくありません。そのうえで、外部サービスや委託先に付与している権限が本当に必要最小限になっているかを見直す必要があります。「業務上便利だから」という理由で広い権限を与えたままにしていると、それがそのまま攻撃経路になってしまいます。また、技術的な対策だけでなく、委託契約や運用ルールの見直しも欠かせません。インシデント発生時の報告義務や再委託の条件、セキュリティ対策状況の確認方法などを明確にしておくことで、リスクを大きく下げることができます。

まとめ：サプライチェーン全体を見る視点が不可欠に

サプライチェーン攻撃は、もはや一部の大企業だけの問題ではありません。外部サービスを利用し、業務を委託し、クラウド連携を行っている企業であれば、規模に関係なく直面する可能性があります。重要なのは、自社のシステムだけを見るのではなく、自社を取り巻くサプライチェーン全体をどう管理するかという視点です。そこに目を向けない限り、同様の事故は今後も繰り返されるでしょう。

また、これらの事故は経営判断とも直結します。
「サプライチェーン攻撃と経営責任 ―委託先が原因でも問われる企業の判断とは ―」

こうした実態を踏まえると、サプライチェーン攻撃は個別対策だけでは防ぎきれません。委託先や外部サービスを含めた全体像を把握し、どこにリスクが集中しているのかを整理する視点が不可欠です。
「サプライチェーン攻撃とは ―委託先・外注先リスクから情報漏えいを防ぐ全体像―」

BBSecでは

サプライチェーン攻撃への対策では、「何となく不安だが、どこから手を付ければいいか分からない」という声を多く聞きます。外部接点が増えた現代では、勘や経験だけでリスクを把握するのは難しくなっています。ブロードバンドセキュリティ（BBSec）では、外部委託先や連携サービスを含めたセキュリティリスクの可視化や、運用・体制面まで踏み込んだ支援を行っています。サプライチェーン全体を前提とした評価や改善を進めることで、「自社は大丈夫」という思い込みによるリスクを減らすことが可能です。もし、自社のサプライチェーンリスクに少しでも不安を感じているのであれば、一度立ち止まって全体を整理するところから始めてみてはいかがでしょうか。

【参考情報】

独立行政法人情報処理推進機構（IPA）「サプライチェーンリスクマネジメント」（https://www.ipa.go.jp/security/reports/economics/scrm/index.html）
CISA（米国サイバーセキュリティ・社会基盤安全保障庁）,Hardware Bill of Materials Framework (HBOM) for Supply Chain Risk Management (SCRM) （https://www.cisa.gov/news-events/news/cisa-releases-hardware-bill-materials-framework-hbom-supply-chain-risk-management-scrm）
NIST（米国国立標準技術研究所）,Cybersecurity Framework（https://www.nist.gov/cyberframework）

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

2026年1月26日2026年1月28日

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

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年版の中で、特にメモリ領域の安全性に関連する項目としては以下が挙げられます。

CWE-787：範囲外の書き込み
CWE-416：解放したメモリの使用
CWE-125：範囲外の読み取り
CWE-476：NULLポインター逆参照
CWE-121：スタックベースバッファオーバーフロー
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に戻る

2026年1月23日2026年1月26日

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

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

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

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

CWE-79
CWE-352
CWE-862
CWE-22
CWE-434
CWE-863
CWE-20
CWE-284
CWE-200
CWE-306
CWE-918
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では

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

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

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

2025年9月30日2025年9月30日

AIとセキュリティ最前線 -AI搭載マルウェアとは？脅威とセキュリティ対策-

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

AIの進化により業務効率化を促進された一方で、ChatGPTを悪用したフィッシングメールやAI画像による偽装、AIを搭載したマルウェア・ランサムウェアの出現、さらにプロンプトインジェクションによる情報漏洩など、脅威が多様化しています。本記事では「AIとセキュリティ」をテーマに、AIの脆弱性と悪用事例を整理し、マルウェア検知や組織が取るべき防御策を解説します。AI活用に取り組む企業にとって必読の内容です。

AIとセキュリティの関係性

AI技術の進歩は、業務効率や創造性の向上に大きく寄与する一方で、サイバーセキュリティの面では新たな脅威を生み出しています。近年では、AIを悪用したフィッシングメールや偽画像の拡散、AIを組み込んだマルウェアやランサムウェアの登場、さらにプロンプトインジェクションによるチャットボットの不正操作や情報漏洩など、AIに関連した多様な攻撃手法が報告され、「AIとセキュリティ」は組織にとって喫緊の課題となっています。こうした脅威はいずれも、組織の情報資産や業務全体に影響を及ぼすリスクの一部として理解することが重要です。

一方、防御の側面でもAIは進化しており、マルウェア検知やログ監視の高度化、EDRによる未知の脅威の早期発見など、攻撃と防御の双方でAIセキュリティは進化しています。組織には、脅威を正しく理解すると共に、防御面におけるAI活用を積極的に進める姿勢が求められます。

SQAT.jpでは過去にも「ChatGPTとセキュリティ」をテーマにした記事を公開しています。こちらもあわせてぜひご覧ください。
「ChatGPTとセキュリティ-サイバーセキュリティの観点からみた生成AIの活用と課題-」

フィッシングメールの高度化

従来までのフィッシングメールは、誤字脱字や不自然な日本語が多く、注意深い利用者であれば比較的容易に見抜くことができました。しかし、生成AIの普及により状況は一変しています。生成AIにより日本語の生成精度が飛躍的に高まり、違和感のない文章を伴ったフィッシングメールが大量に作成されるようになったからです。加えて、AIの支援により攻撃者は高度なソーシャルエンジニアリング手法を容易に組み込めるようになっています。例えば、受信者の立場や業務状況に即した文脈を織り込み、心理的に開封やクリックを誘導しやすいメールを簡単に作成できるのです。これにより、従来の「日本語が怪しい」「文脈が不自然」といった従来型のチェックでは見抜けないケースが増えています。

世の多くの組織にとってそうであるように、サイバー攻撃者にとっても生成AIはコスト削減と効率化の強力な武器となっています。組織にとっては、こうしたフィッシングの高度化が新たなリスクとして突き付けられており、今後は人の注意力に依存した防御では限界があることを認識する必要があります。

AI内蔵型マルウェア「LameHug」

LameHugは、2025年7月にウクライナのCERT‑UAによって発見された、APT29の関与が疑われるAI（大規模言語モデル：LLM）を実行時に活用するマルウェアです。従来型マルウェアがあらかじめ定義されたコマンドや固定の挙動を持つのに対し、LameHugは感染端末の環境に応じてリアルタイムにコマンドを生成します。スピアフィッシングメールを起点に感染が始まり、攻撃メールには偽装されたアーカイブが添付されています。LameHugは被害者のファイル構造やネットワーク構成に応じて、LLMが最適なWindowsコマンド（systeminfo、tasklist、netstat、ipconfigなど）を組み合わせて指令を出すため、従来型マルウェアより柔軟な挙動が可能です。さらに、署名ベースや静的検知に頼る従来のセキュリティツールを回避しやすい点も特徴です。動的にコマンドを生成するため、固定パターンでは検知が困難です。また、データ窃取も迅速に行われ、持続的なバックドアより「一度に情報を奪う」設計となっています。

このように、LameHugは従来型マルウェアと比べ、環境適応性・リアルタイム性・検知回避能力が大きく進化しており、サイバーセキュリティの脅威像を再定義する存在と言えます。

AI搭載ランサムウェア「PromptLock」

2025年8月、ESETの研究チームは世界初のAI搭載ランサムウェア「PromptLock」を発見したと発表し、セキュリティ業界に大きな注目を集めました。後にこれはニューヨーク大学（NYU）の研究者による実験的な取り組みであることが判明しましたが、AIを活用したランサムウェアのコンセプトが現実に成立し得ることを示した意義は非常に大きいといえます。

PromptLockは、従来型ランサムウェアと異なり、感染後の挙動や身代金要求文をAIが自動生成できる点が特徴です。これにより、固定的なパターンに依存した従来の検知方法では捕捉が難しくなるだけでなく、対象組織の環境や状況に応じたカスタマイズ攻撃も可能となります。また、複数の端末やネットワーク構成に合わせた戦略的な攻撃展開も現実的に行えるため、AIを用いたランサムウェアの概念が現実の攻撃として成立し得ることが明確に示されました。

プロンプトインジェクション攻撃

近年、AIブラウザやチャットボットを対象とした「プロンプトインジェクション攻撃」が、新たな深刻な脆弱性として指摘されています。生成AIの普及とブラウザや業務システムとの連携拡大に伴い、攻撃の実現可能性は高まっています。この攻撃は、ユーザが入力する指示文に悪意あるプロンプトを仕込み、AIを騙して本来想定されていない動作をさせるものです。具体的には、外部の攻撃者が生成AIを組み込んだブラウザに不正な指示を与え、社内機密や顧客データを外部に送信させたり、悪意あるコードを実行させたりするリスクが確認されています。AIが入力テキストを過剰に信用する設計に起因するこの脆弱性は、単なる技術的課題にとどまらず、組織の情報漏洩や業務継続への影響、コンプライアンス違反など、幅広いリスクに直結します。AIを導入する際には、セキュリティ検証やアクセス制御を徹底し、AIであることを安全の前提と考えない姿勢が重要です。

AIのセキュリティリスク

AIの利活用が広がる中で、組織が直面するセキュリティリスクは多岐にわたります。代表的なものとして、学習データの改竄・汚染（データポイズニング）、情報漏洩、シャドーAIの3つが挙げられます。

データの改竄・汚染（データポイズニング）

AIは学習データに依存して判断を行うため、攻撃者が学習データに不正なデータを混入させると、AIは誤った判断を下す危険があります。例えば、不正な金融取引データを「正常」と学習させれば、不正検知システムは攻撃を見逃してしまいます。製造や物流などの業務プロセスでも同様に、AIが学習したセンサーデータや工程情報に不正を混ぜ込まれると、品質管理や異常検知の精度が低下し、損害や事故につながる可能性があります。データポイズニングは、従来のサイバー攻撃のようにネットワークや端末に直接侵入するものではなく、AIの判断プロセスそのものを標的にする攻撃である点が特徴で、組織のAI活用戦略全体に影響を及ぼす深刻なリスクです。

情報漏洩

生成AIはときに業務データや個人情報を入力したうえで利用されます。しかし、AIが取り扱うデータが外部に流出すると、個人のプライバシー侵害や顧客情報の漏洩、さらには競合優位性の喪失といった深刻な問題を引き起こすことを意味します。特に外部クラウド型AIサービスを利用する場合、データがどのように保存され、処理されるのかを正確に把握しておく必要があります。また、AIが生成したアウトプットに機密情報が含まれる場合、意図せず社外に配信される可能性もあるため、データ取り扱いルールやアクセス権限の厳格化が不可欠です。AIによる業務効率化の恩恵を享受する一方で、情報漏洩のリスクを軽視することはできません。

シャドーAI

まず、次の情報をご覧ください。

44%の従業員が会社のポリシーに反してAIを職場で使用
38%の従業員が承認なしに機密データをAIプラットフォームと共有

【参考情報】

このように、多くの組織では、従業員が個人アカウントで生成AIを業務に利用する「シャドーAI」の実態が明らかになってきています。このことは、管理部門の把握を超えてAIが利用されるため、セキュリティ上の盲点となる可能性があります。例えば、従業員が個人アカウントで顧客データをAIに入力して分析した場合、管理者はその行為を追跡できず、万一情報漏洩が発生しても原因究明が困難です。また、AIの利用ログが社内ポリシーで管理されていないと、不正利用や誤った意思決定の温床になる可能性があります。組織は、シャドーAIの使用状況を可視化し、利用ガイドラインや教育プログラムを整備することが求められます。

これらのリスクは、AIの利便性と表裏一体です。経営層や情報システムの担当者は、AIがもたらす業務効率化の恩恵とリスクの両面を正しく理解し、自社の業務環境に即した具体的な対策を講じることが不可欠です。

組織が実施すべきセキュリティ対策

組織はAIを活用する環境において、従来のセキュリティ対策だけでは不十分です。まず、AIモデルやAPIを利用する際には、アクセス制御や権限管理を徹底する必要があります。利用者ごとに適切な権限を設定し、外部からの不正アクセスや情報の持ち出しを防ぐことが重要です。また、マルウェア検知やログ監視を強化することも不可欠です。これにより、AI環境を安全に運用しつつ、組織の情報資産を守る基盤を整備できます。

SQAT.jpでは過去もフィッシング対策に関する記事を公開しています。あわせてぜひご参照ください。
「ソーシャルエンジニアリング最前線【第4回】企業が実践すべきフィッシング対策とは？」
「フィッシングとは？巧妙化する手口とその対策」

セキュリティ人材の育成

AIを含む高度化するサイバー攻撃に対応するには、技術だけでなく人材の育成も不可欠です。組織は情報セキュリティ教育を通じて、従業員にAIの利活用に伴うリスクや最新の脅威動向を理解させる必要があります。例えば、フィッシングメールの高度化やプロンプトインジェクションの可能性、シャドーAIではどのようなリスクがあるのかなどを具体的に学ぶことで、日常業務におけるリスク意識を高められます。また、社内での演習やシミュレーションを通じて、攻撃を想定した実践的な対応力を養うことも重要です。こうした取り組みにより、単なるツールの管理者ではなく、攻撃に対して能動的に判断・対応できる人材を育て、組織全体のセキュリティ体制を強化することが可能です。詳しくは下記のお問い合わせボタンからお問い合わせページに飛んでいただき、お気軽にお問い合わせください。

AIの進化は、組織に大きな競争優位をもたらす一方で、新たなサイバー脅威を次々と生み出しています。今後の組織に求められるのは、防御と利活用のバランスを取りながらAI時代にふさわしいセキュリティ戦略を構築し、競争力を維持していくことでしょう。

BBSecでは

インシデント初動対応準備支援

拡大するサイバーセキュリティの脅威に対応するために今すぐにでも準備すべきことを明確にします。

https://www.bbsec.co.jp/service/evaluation_consulting/incident_initial_response.html
※外部サイトにリンクします。

G-MDR^TM

サイバー攻撃への防御を強化しつつ、専門技術者の確保や最新技術への投資負担を軽減します

https://www.bbsec.co.jp/service/mss/gmdr.html
※外部サイトにリンクします。

エンドポイントセキュリティ

組織の端末を24/365体制で監視。インシデント発生時には端末隔離等の初動対応を実施します。

https://www.bbsec.co.jp/service/mss/edr-mss.html
※外部サイトにリンクします。

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

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

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

2025年10月1日（水）13:00～14:00
「2025年10月Windows10サポート終了へ今知るべきサポート切れのソフトウェアへのセキュリティ対策ガイド」

2025年10月8日（水）14:00～15:00
ウェビナー参加者限定特典付き！
「ソースコード診断で実現する安全な開発とは？脆弱性対策とDevSecOps実践」

2025年10月22日（水）14:00～15:00
「ランサムウェア対策セミナー2025 ～被害を防ぐための実践的アプローチ～」

2025年10月29日（水）13:00～14:00
【好評アンコール配信】「フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜」

最新情報はこちら

2024年10月15日2025年8月12日

APIとは何か（2）～APIの脅威とリスク～

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

APIセキュリティは、現代のビジネスにおいて不可欠な課題です。シリーズ第2回の今回は、APIを悪用した攻撃手法や、OWASP（Open Web Application Security Project）よりリリースされている「OWASP API Security Top 10」で取り上げられるリスクの詳細を解説します。インジェクション攻撃やDDoS攻撃、APIキーの悪用、アクセス制御に関する脆弱性など、主要な脅威を紹介しながら、APIが悪用された場合の影響について解説します。

前回記事（シリーズ第1回）「APIとは何か～基本概念とセキュリティの重要性～」はこちら。

APIとは～前回からの振り返り

日頃からインターネットなどのネットワークを使用することが多い今日、現代における多くの企業はAPIに大きく依存しており、今やAPIは不可欠なものとなっています。Akamai社のレポート「The API Security Disconnect」によると、調査対象となった企業の約8割以上が2023年に行った調査において、「過去12か月以内にAPIセキュリティをより重視した」と回答しています。しかし、2022年～2024年で調査した回答者のうち、半数以上が、APIのセキュリティインシデントの影響により顧客の信頼を失い、さらにそこからほぼ半数は生産性の低下や従業員の信頼の低下にもつながったといいます。

また、SNS事業者が提供するAndroid版アプリに存在した脆弱性が悪用された結果、膨大な量のアカウント情報が漏洩した事例*1も報告されています。これは攻撃者が大量の偽アカウントを使用し、様々な場所から大量のリクエストを送信し、個人情報（ユーザ名・電話番号）を照合するというものでした。

APIが悪用されるとどうなるか

APIが悪用された場合、多岐にわたる深刻な影響が生じます。特に、認証や認可の不備は深刻なセキュリティホールとなり得ます。攻撃者はこれらの脆弱性を悪用して不正アクセスを行い、機密データや個人情報を盗み出す恐れがあります。また、認可が適切に設定されていないと、本来は外部からアクセスできないはずのデータにまで侵入され、第三者からデータの改ざんや不正操作が可能となってしまいます。さらに、APIを標的にしたDDoS攻撃によりサービスがダウンし、正規ユーザが利用できなくなることで、企業の信用失墜や業務の中断といったダメージを引き起こします。これらの影響は、経済的損失だけでなく、法的問題やブランドイメージの毀損など、長期的な悪影響をもたらすため、APIのセキュリティ強化が不可欠です。

APIを悪用した攻撃の事例はいくつか報告されていますが、いずれの攻撃も、「OWASP API Security Top 10」で挙げられている問題と関連性があります。

OWASP API Security Top 10

APIセキュリティについて、Webアプリケーションセキュリティに関する国際的コミュニティであるOWASPが、2023年6月に「OWASP API Security Top 10 2023」をリリースしています。APIセキュリティにおける10大リスクをピックアップして解説したものです。

https://owasp.org/API-Security/editions/2023/en/0x11-t10/ より当社作成

「OWASP API Security Top 10」上位のリスク

特に上位5つの項目については、以下のような重大なリスクにつながるため、リリース前に十分な対策が施されていることを確認すべきです。

不正アクセス
なりすまし
情報漏洩
サービス運用妨害（DoS）

主なセキュリティ脅威

インジェクション攻撃

インジェクション攻撃は、悪意のあるコードをAPIに挿入し、不正な操作を行う攻撃です。APIの入力データを検証せずに処理している場合、攻撃者にデータベースへのアクセスを許すリスクが生じます。特にSQLインジェクションやコマンドインジェクション攻撃が多く、攻撃を受けてしまった場合、データベースの情報漏洩やシステムの制御不備などの被害があります。

認証およびセッション管理の不備の脆弱性を悪用

APIの認証とセッション管理の不備を悪用することで、攻撃者は不正アクセスやなりすましを行います。パスワード強度が不十分な場合やトークンの管理が適切に行われていない場合、セッションハイジャックや不正に重要な情報を閲覧されることによってデータの漏洩が発生するリスクがあります。適切な認証管理およびセッション管理を行うことが重要です。

DDoS攻撃

DDoS攻撃は、複数のPCからアクセスされることによる膨大な量のリクエストをAPIに一斉に送り込むことで、システムのリソースを枯渇させ、サービスの提供を妨害する攻撃です。APIの特性上、処理を高速に行うために外部からのリクエストを許容する必要がありますが、その柔軟性が悪用されます。攻撃者はボットネットを利用し、大量のトラフィックを発生させてサーバのリソースを消費させます。これにより、顧客はサービスが利用できず、自組織においても業務に多大な影響を及ぼします。APIを保護するためには、トラフィックの監視やレート制限、WAF（Webアプリケーションファイアウォール）などのセキュリティ対策が重要です。

APIキーの悪用

APIキーは、APIへのアクセスを制御するために利用されますが、攻撃者に奪われると不正利用のリスクが生じます。盗まれたAPIキーは無制限のアクセスやサービスの悪用に使われる恐れがあります。安全な管理や無制限にアクセスができないように適切なアクセス制御を実施すること等が重要です。

アクセス制御の不備による影響

APIのアクセス制御の不備の脆弱性を悪用することで、攻撃者は許可されていないデータや機能にアクセスできます。適切な権限設定がされていない場合、データの漏洩や不正な操作の実行のリスクがあります。権限の設定など適切なアクセス制御が求められます。

思わぬデータの公開や改ざん

APIの設計や実装の不備により、データが意図せず公開・改ざんされるリスクがあります。適切な認証・認可がないと、攻撃者が内部の機密情報にアクセスすることが可能になります。例えば、本来ならシステム管理者のみがアクセスできる設定画面または顧客情報やシステムに関する情報などの重要情報が格納されている場所に攻撃者がアクセスできてしまった場合、システムの設定を変更されたり重要情報が奪取されたりする恐れがあります。また、過剰に情報を提供するAPIレスポンスや暗号化されていないデータ転送も、情報漏洩や改ざんの危険性を高めます。データ保護には、適切なアクセス制御と暗号化の実装が不可欠です。

アカウント乗っ取り

不正アクセスによってユーザアカウントが乗っ取られ、APIを悪用される可能性があります。一度アカウントが乗っ取られると、攻撃者は個人情報の閲覧や不正操作、さらには他のシステムへの攻撃拡大を図る可能性があります。多要素認証（MFA）の導入やAPIキーの適切な管理、ログイン試行の監視など、セキュリティ対策の強化が必要です。

まとめ

現代の企業にとってAPIによるアプリケーション連携は不可欠ですが、その悪用によるセキュリティリスクも増加しています。APIを悪用した攻撃の事例は、「OWASP API Security Top 10」に関連しています。主なセキュリティ脅威には、インジェクション攻撃、認証やセッション管理の不備、DDoS攻撃、APIキーの悪用、アクセス制御の脆弱性、不適切なデータ公開や改ざん、アカウント乗っ取りなどがあります。これらは重大なリスクを孕んでいるため不正アクセス、なりすまし、機密データの盗難を含む情報漏洩、データ改ざん、サービスのダウンによるサービス低下や業務への影響、ひいては企業の信用失墜といった深刻な結果を招きます。こうした被害を防ぐため、APIの設計段階から適切なセキュリティ対策を行い、監視やアクセス制御の強化が不可欠です。

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

2022年9月1日2025年5月12日

攻撃者が狙う重要情報の宝庫！
―スマホアプリのセキュリティ―

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

私たちが日常的に利用するスマホアプリのサービスは、開発者によって多様な機能が連携され、提供されています。しかしスマートフォンは、サイバー攻撃のターゲットになってしまう魅力的な重要情報の宝庫となっており、攻撃者に狙われることも多いです。本記事では、なぜスマホアプリが狙われるのか？スマホアプリのもつ脆弱性情報のご紹介をしつつ、セキュリティ対策にむけた考え方を解説していきます。

なぜスマホアプリは攻撃者に狙われるのか

一人一台以上のスマートフォンを所持・活用しているのが当たり前とされる現代において、私たちは日常的に様々なスマホアプリを利用しています。それらのスマホアプリがサービスとして提供されている裏では、スマートフォンが備えている多様な機能とスマホアプリとが開発者によって連携され、それによりスマホアプリのサービス提供が実現しています。利用者がアプリ上でのみ操作を行っているつもりでも、実際はアプリとスマートフォンの持つ機能が連携することで、便利なサービスを利用できているのです。

しかし便利な一方で、スマホアプリはサイバー攻撃のターゲットとされることも多くあります。なぜならスマホアプリは以下の3つの特徴を持っているためです。

重要情報の宝庫

スマホアプリではWebアプリよりも多くの重要情報が扱われます。例えば連絡先情報、メールや通信のログ、GPS（位置情報）、決済情報、さらには利用者が何を好むかといった趣味嗜好など個人に関する情報が多様に含まれています。これらの情報が集まっているスマホアプリは、攻撃者にとっては魅力的な重要情報の宝庫といえます。

もし攻撃者に狙われた場合、これらの重要情報が漏洩してしまう可能性があります。

ユーザ側での端末管理

Webアプリではサービス提供者が管理しているサーバ側で情報を保持していましたが、スマホアプリでは各ユーザ端末側に情報が保持されているものが多くあります。Webアプリの場合はサービス提供者側がセキュリティソリューションを活用したりすることでセキュリティ対策を行っていましたが、スマホアプリのように各ユーザ端末側で情報が保持されている場合、セキュリティ対策の実施はユーザ個人に依存するため、セキュリティ対策が十分に行われていないこともあります。特にスマートフォンに関するセキュリティ対策情報は、パソコンのセキュリティ対策に比べてユーザにあまり認知されていないため、ユーザのセキュリティ意識がパソコンよりも薄い状況にあります。

もしスマートフォンのセキュリティ対策が十分にされていなかった場合、脆弱な状態や設定のまま放置され、そのままアプリ連携や端末間での共有がなされることで、ユーザが意図しない手段や経由により不正アクセスが行われる可能性があります。

常時外部と接続状態

Webアプリはブラウザからアクセスしますが、スマホアプリではアプリごとに独自開発された機能によってアクセスします。また、スマートフォンは常時電源がオンになっており、インターネットにも常時接続されている状態です。

そのため、例えばあるスマホアプリで非暗号化通信での情報のやり取りなどが行われて重要情報が外部から見えるような状態であった場合に、常時接続状態であるスマートフォンは攻撃者に狙われる隙が生まれやすくなってしまいます。これにより不正利用・操作や、通信内容の盗聴・情報改竄が行われる可能性があります。

攻撃者にとって重要情報の宝庫であるのにも関わらず、セキュリティ対策がユーザ側に依存し、また常時インターネットに接続状態となっているため、攻撃の隙も生まれやすい。これがスマホアプリが攻撃者に狙われやすい理由です。またBYOD（Bring Your Own Device）を導入している企業も増えてきたため、個人のスマートフォンが攻撃されることで、企業への攻撃の踏み台にされる可能性もあります。

スマホアプリにおける情報漏洩の事例

実際に近年起きたスマホアプリにおける情報漏洩は下記のようなものがあります。

スマホアプリにおける脆弱性の届出状況

IPAおよびJPCERT/CCが発表している「ソフトウェア等の脆弱性関連情報に関する届出状況[2022年第2四半期（4月～6月）]」によると、2022年の第2四半期（4月～6月）までで届出が出されている脆弱性を製品種類に分けて集計すると、スマホアプリの脆弱性はソフトウェア製品全体の8％となっており、ウェブアプリケーションソフトとルータに次いで多く検出されている結果となりました。スマホアプリ開発段階で脆弱性を見落とされて、そのままリリースされてしまった場合、スマホアプリを利用するすべての人々に影響が及ぶ可能性があり、情報漏洩事故につながってしまう恐れがあります。

スマホアプリのセキュリティの対策にむけて

誰もがスマートフォンを利用しているからこそ、実際に被害に遭う可能性を誰しもが持っています。また、攻撃の影響は多くの人々に及ぶことが想定されます。ユーザ目線では被害を受けないための、またスマホアプリを提供する側目線では被害を防ぐためのセキュリティ対策を心掛けることが重要でしょう。

今回はスマホアプリを提供する上で重要な考え方や手段を大きく3つご紹介します。

脆弱性情報の収集

脆弱性情報を取りまとめている機関*2等から定期的に脆弱性情報を収集し、セキュリティの最新情報や対策方法を取り入れることで、普段からセキュリティに対する意識を高める必要があります。

セキュアコーディングを意識した開発

セキュアコーディングとは開発段階で攻撃に耐え得る堅牢なプログラムを書くことを指します。セキュアコーディングのガイドライン「Androidアプリのセキュア設計・セキュアコーディングガイド」を活用することで、スマホアプリ開発段階から脆弱性の有無を知り、より早い対策を実施することができます。また、より早い段階で対策ができれば、リリース後の手戻りやコストの発生も防ぐことができます。このようなシフトレフトを実践することも重要な考え方の一つです。

セキュアなアプリケーション開発の考え方について、SQAT.jpでは以下の記事でご紹介しています。
こちらもあわせてご覧ください。
「Webアプリケーション開発プロセスをセキュアに ―DevSecOps実現のポイント―」

信頼できる第三者機関の脆弱性診断サービスを実施

企業として実施できるセキュリティ対策として、信頼できる第三者機関による脆弱性診断が挙げられます。第三者の専門家からの診断を受けることで、現状の問題点や対応の優先順位などリスクを可視化することができるため、早急に効率よく対策を実施するのに役立ちます。

APIのセキュリティ対策

スマホアプリと切っても切れないものとして、API（Application Programming Interface）が存在します。スマホアプリはAPIを経由してサーバとやり取りをしているケースが多く、セキュリティ対策を行ううえでAPIを無視することはできません。

APIにおいてもWebアプリと同様に様々なセキュリティリスクが存在しますので、スマホアプリ、Webアプリと同様に最適なセキュリティ対策をとることが大切です。

APIのセキュリティに関する10大リスク

APIにおけるセキュリティ対策を講じるうえで役立つ情報として、Webアプリケーションセキュリティに関する国際的コミュニティOWASP（Open Web Application Security Project）が公開している「OWASP API Security Top 10」があります。

SQAT.jpでは以下の記事でご紹介しています。あわせてご覧ください。
「APIのセキュリティ脅威とは」

スマホアプリ脆弱性診断とは

「スマホアプリのセキュリティ対策」に既述した脆弱性診断サービスですが、そういったサービスの活用がなぜ必要なのでしょうか。その理由は図の通りです。

スマホアプリ診断で検出される脆弱性項目例

例えば弊社のスマホアプリ診断において検出数の多い脆弱性項目としては、下記のようなものがあります。このような脆弱性はなかなか開発段階で自社の目線からすべて網羅するのは難しく、脆弱性診断サービスを使うことで効率よく発見することが可能です。

重要情報の漏洩

＜例＞
・スマートフォン内部の記憶媒体領域（ストレージ等）に認証情報が保存されている
・スマホアプリからサーバ側に通信を行う際に、URLパラメータ等が暗号化されていないままの状態であるために認証情報が露呈している

重要情報がスマホアプリ側だけではなく、ユーザのスマートフォン内部など他の領域で確認できる状態であるために、攻撃者に情報が漏洩してしまう可能性があります。

不正な行動・操作が可能

＜例＞
・信頼境界へのアクセスが厳密に制御されていない状態である
・外部アクセスの制御不備などにより、スマホアプリの権限外のユーザによるアクセス制御が可能である

スマホアプリではAPIや他のアプリとの連携、スマートフォン内部の記憶領域など、外部との通信が頻繁に行われます。その中で、信頼できない外部からのアクセスを制御するといった対策が厳密に行われていないために、攻撃者から不正な操作の実行や、データ改竄および不正利用される可能性があります。

難読化処理の未対応

＜例＞プログラムコードが難読化されていないため、リバースエンジニアリングによるソースコード解析が可能な状態である

攻撃者により、スマホアプリの機能およびロジック分析が行われた場合、弱点をついた攻撃手法の分析や技術情報の解析につながる可能性があります。

誰もがスマートフォンを利用している今、攻撃の被害が多くの人々に影響を及ぼす可能性があるからこそ、スマホアプリにおいて次の攻撃につながる情報が漏洩したり、スマホアプリの改竄が行われたりする可能性を摘んでおくことが、スマホアプリを提供するうえで重要となります。

スマホアプリ脆弱性診断に＋α

開発者視点でのスマホアプリの品質管理、セキュアコーディング、セキュリティ設定のチェックにはソースコード診断サービスもあわせて実施することを推奨しています。スマホアプリに潜在する脆弱性をソースコードレベルで診断することで、さらなるセキュリティ向上にお役立ちできます。

スマホアプリの進化にあわせた対策を

スマホアプリは様々なかたちで利用され、日々利便性が向上されています。それに伴い開発・提供者側はより高度な機能を活用し、扱う分野や範囲も広がってきています。すでに述べてきたように、機能の利便性の反面、Webアプリと比べてスマホアプリは独自のリスクを抱えています。そのため、基本的なセキュリティ対策はもちろん、より強固なセキュリティ対策を行うことが、サイバー攻撃を防ぐカギとなります。

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

2020年8月25日2025年5月13日

APIのセキュリティ脅威とは

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

APIとは、ソフトウェアが相互に機能やデータを利用しあうための仕組みで、機能や開発効率を向上させるなどのメリットがあります。しかしAPIにもセキュリティ上のリスクがあり、セキュリティ対策を怠ったことによる被害も報告されています。今回は、APIの安全な利活用について解説します。

「API」とは

「API」とは「Application Programming Interface」の略で、複数のソフトウェアが相互に機能を利用しあうために設けられたインターフェースを意味します。コンピュータプログラムやWebサービスなどをつないで連携させ、さまざまな機能やデータを共有可能にすることで、従来にない価値を生み出せるという点が大きなメリットといわれています。例えば、あるアプリが、特定の機能を持つAPIを利用することで、それまでなかったサービスをユーザに提供できるようになります。

APIのなかでも広く利用されているのがWebに公開されている「Web API」で、多数のWebサービスやプラットフォーマーが各社のWeb APIを公開しています。身近な例としては、位置情報ゲームで地図情報サービスが提供するAPIを利用するケースなどがあります。

APIの積極的な活用は、IoTや企業のDX（デジタルトランスフォーメーション）の実践に不可欠と言っても大げさではありません。さまざまなアプリやWebサービスがAPIを通じて相互接続することで、利用者の利便性の向上、経済の活性化など、単独では実現できなかった価値を生み出せるようになります。こうした仕組みのことを「APIエコノミー」と呼ぶこともあります。

あなたの身近にあるAPIの活用例

Webサービスなどを利用しているときに「Facebookでログイン」「Googleでログイン」などのボタンを見たことはありませんか？ Facebook、Google、Twitterなどで設定したアカウントを使って、別のECサイトなどにログインする「ソーシャルログイン」は、各サービスが公開するAPIを使って実現されています。また、企業などのWebサイトで地図情報がGoogle Mapから呼び出されて掲載されている、あの仕組みもAPIによるものです。

API活用のメリット

APIを活用すれば、個別の機能を各サービスで一から開発する必要がなくなるため、開発効率が上がり、コストを抑えることができます。機能を提供する側も、機能を使ってもらうことで自社のブランド力の向上、広告収入といった経済的利益を得られます。また、前出の「ソーシャルログイン」などでは、独自のログイン用プログラムを各企業がそれぞれ開発する場合に比べ、一定のセキュリティ水準を確保できるという効果も期待できます。

Web APIはWebアプリケーションでどう使われるか

ここで、「Web API」はいわゆる「Webアプリケーション」でどう使われるのか、少し補足しておきましょう。

WebアプリケーションがAPIを用いて地図情報だけを外部の地図サーバから取得しているケースについて考えてみます。Webサーバはブラウザからのリクエストを受け、WebアプリケーションからAPIを経由して地図情報を地図サーバにリクエストします。地図サーバはAPIを介して地図情報をWebアプリケーションへ送り返します。それを受けたWebサーバが、地図情報を含めたページ全体をユーザに返します。ユーザから見たときにはAPIを使っているかどうかはわかりませんが、このように、APIは、特定の機能のため、特定の情報のやり取りのために利用されているのです。

APIのセキュリティの重要性

Webサービスを利用するユーザ側から見れば、そこでAPIが使われているかどうかは何ら重要なことではありません。しかしサービス提供側から考えた場合、APIにもWebアプリケーション同様、脆弱性をはじめとするさまざまなセキュリティリスクが存在することを忘れてはなりません。また、近年のスマートフォンの普及により、スマートフォンのアプリケーションがAPIを直接利用するケースも増えており、今までサーバ側での利用が主流だったAPIがユーザの手元から直接利用される時代になっている点にも注意が必要です。

適切なセキュリティ対策を怠った場合のリスクは、むしろWebアプリケーションよりも深刻かもしれません。さまざまなソフトウェアと連携するというAPIの特質から、被害が自社のコントロールの及ぶ範囲を超えて広がる可能性が想定されるためです。

APIが原因で起こったサイバー攻撃被害

2018年、米大手SNSが開発者向けに公開していたAPIのバグが悪用され、ログインを行う際のカギとなるデータが盗まれる事件が発生しました。2019年には、大手配車マッチングアプリで、APIが降車時の支払い方法の検証をしないことで、無賃乗車ができてしまうバグが報告されています。

米大手SNSの事件は、多数のAPIが組み合わされることによって、バグの検出やセキュリティ上の問題の発見が遅れたり困難になったりするという問題をあらわにしたものでした。また、配車マッチングアプリのバグは、APIの入力値を検証することの重要性を改めて気づかせるものでした。

その利便性から急速に普及が進んでいるAPIですが、「事故やサイバー攻撃被害の発生によって初めて、リスクの存在を認識する」という昨今の状況を踏まえると、セキュリティに関してはまだまだ未成熟な領域であるといえるでしょう。

「OWASP API Security Top 10」などのリソースを活用して対策を立てる

こうしたサイバー攻撃被害や事故を受け、今、APIのセキュリティは最重要事項の1つとして取り組まれるようになっています。その大きな成果の1つとして、「API Security Top 10」をご紹介しましょう。これは、Webアプリケーションセキュリティに関する国際的コミュニティOWASP（Open Web Application Security Project ）がAPIセキュリティに関する10大リスクを選定・解説したもので、2019年末に公開されました。API固有のセキュリティリスクを把握し、対策を講じるために役立ちます。

OWASPによるAPIセキュリティ10大リスク

1.	オブジェクトレベルでの許可の不備（Broken Object Level Authorization）
2.	認証の不備（Broken User Authentication）
3.	データの過度な露出（Excessive Data Exposure）
4.	リソースの制限、頻度の制限の不足（Lack of Resources & Rate Limiting）
5.	機能レベルの認可の不備（Broken Function Level Authorization）
6.	一括での割り当て（Mass Assignment）
7.	不適切なセキュリティ設定（Security Misconfiguration）
8.	インジェクション（Injection）
9.	不適切なアセット管理（Improper Assets Management）
10.	不充分なロギングとモニタリング（Insufficient Logging & Monitoring）

（翻訳：SQAT.jp 編集部）

上記のような資料は、自組織のAPIセキュリティを点検する際のガイドラインとしてぜひ活用したいものです。さらに、APIを含むWebアプリケーションに対する脆弱性診断サービスを利用して、第三者視点から、自組織のシステムで使用されているAPIのセキュリティを定期的に評価することもお勧めします。

まとめ

・APIとはアプリやWebサービスなどが相互に機能やデータを利用しあうための仕組みです。
・API活用には、開発のスピードアップやコスト削減などのメリットがあります。
・近年はスマートフォンからAPIを直接利用できるケースも増えており、利用の機会が増えています。
・APIにもセキュリティ上のリスクがありますが、様々なサービスとつながるために利用するという性質から、ひとたび事故や攻撃が起こった場合、より広い範囲に影響が及ぶ可能性があります。
・APIのセキュリティ対策を怠ったことによるサイバー攻撃被害や事故が報告されています。
・OWASP「API Security Top 10 2019」などを参考にAPIのセキュリティ強化に取り組みましょう。

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

なぜ管理漏れが起こるのか

企業で起こりやすい5つの管理課題

台帳が更新されない

シャドーITが増える

クラウド資産が把握できない

EOL（End of Life）・EOS（End of Service）を見逃す

部門ごとに管理している

管理課題を解決するポイント

まとめ：見えていないIT資産は、守れない

IT資産管理を実践するポイントを詳しく学びたい方へ

脆弱性管理とは

なぜ企業に脆弱性管理が必要なのか

脆弱性管理の基本プロセス

脆弱性管理のフロー（実務）

脆弱性管理ツールの種類

企業の脆弱性管理の課題

IT資産の把握

OSS依存関係の管理

SBOMの未整備

クラウド環境の可視化不足

OSS利用時に重要な脆弱性管理（SBOMの活用）

脆弱性管理を効率化する方法

資産管理の自動化

OSS脆弱性監視

SBOMによるソフトウェア構成管理

まとめ

SQAT®脆弱性診断サービス

アタックサーフェス調査サービス

AI時代に増えるリスクと、経営が取るべきアクション

企業が直面するAIセキュリティリスク

生成AI利用による情報漏えい・シャドーAI

プロンプトインジェクション／RAG汚染：AIアプリ特有の攻撃面

学習データ汚染・モデル改ざん・信頼できない出力

モデル盗難・データ推定・API悪用

ガバナンス・法令・説明責任

経営層・CISOが取るべきアクション：AIセキュリティを“経営課題”にする

方針（何を守り、どこまで許容するか）

体制（誰が意思決定し、運用を回すか）

実装（どう測り、どう改善するか）

CISO/経営が迷わないための90日ロードマップ

技術責任者向け AIアプリを“事故らせない”ための設計ポイント

次の5年で起きること、起きないこと

まとめ：これからのセキュリティに携わる人へ

付録：企業が「今すぐ」着手できるチェックリスト

AI利用の棚卸し（ガバナンスの入口）

AIアプリ（RAG/チャットボット等）の設計・運用

AI時代の“人”への対策

ブロードバンドセキュリティからのご案内

自社が原因でなくても、情報漏えいは起きてしまう時代

サプライチェーン攻撃とは何か

なぜ今、国内でサプライチェーン攻撃が増えているのか

国内で実際に起きているサプライチェーン攻撃の特徴

サプライチェーン攻撃が企業にもたらす影響

企業が今すぐ考えるべきサプライチェーン対策

まとめ：サプライチェーン全体を見る視点が不可欠に

はじめに：前編の振り返り（Web/API 12項目）

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

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

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

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

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

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

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

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

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

ソースコード診断（SAST）

プラットフォーム診断／OSS観点（依存関係・構成）

まとめ

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

BBSecでは

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

CWE Top 25とは

CWE Top 25 2025年版

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

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

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

CWE-79：クロスサイトスクリプティング（XSS）

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

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

CWE-352：クロスサイトリクエストフォージェリ（CSRF）

SQAT^®脆弱性診断サービス

G-MDR^TM