脆弱性の意味を正しく理解する―種類・悪用リスク・企業が取るべき対策

Share

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

脆弱性の意味を正しく理解する―種類・悪用リスク・企業が取るべき対策アイキャッチ画像

「脆弱性(ぜいじゃくせい)」という言葉を見かけても、正確な読み方や意味を知らない方も多いかもしれません。特にITやセキュリティの分野ではよく使われる専門用語ですが、近年では一般的なニュースや記事でも登場するようになってきました。本記事では、脆弱性の正しい意味、よくある誤解、攻撃との関わり、企業が取るべき対策までを体系的に整理し、分かりやすく解説します。

脆弱性とは何か?

「脆弱性(ぜいじゃくせい)」とは、システム・ソフトウェア・ネットワークなどに潜む“攻撃されやすい弱点”を指す言葉です。サイバー攻撃の多くは、この脆弱性を足がかりにして侵入や情報漏えいを引き起こします。しかし、「脆弱性 意味」「脆弱性とは何か?」と問われると、具体的に説明できない人も少なくありません。

脆弱性の読み方と語源

「脆弱性」は「ぜいじゃくせい」と読みます。

「脆」(ぜい):もろい、こわれやすいという意味
「弱」(じゃく):よわい、力が足りないという意味
「性」(せい):性質や特徴を示します

つまり、「壊れやすく弱い性質」という意味で、セキュリティ分野では“攻撃に利用される欠陥や弱点”を指す言葉として使われます。

脆弱性とは?意味をさらに深く解説

脆弱性とは、不正アクセスやコンピュータウイルスなどの攻撃により、その機能や性能を損なう原因となり得るセキュリティ上の問題箇所のことです。英語では 「vulnerability」(「攻撃を受けやすいこと」の意) と呼ばれます。

IT分野では、システムやソフトウェアに存在するセキュリティ上の弱点を意味します。たとえば、プログラムの不備や設定ミスなどにより、外部から不正アクセスを許してしまうような状態が「脆弱性」です。

脆弱性の多くは、「プログラムの設計ミスやコーディングミスなどによるバグ」になります。バグが存在せず正しく動作するプログラムやWebアプリケーションであっても、設計者が想定しないやり方で機能が悪用され、 結果としてサイバー攻撃が成立する場合には、その「悪用されうる機能設計」が脆弱性とみなされます。

脆弱性が攻撃の入口になる理由

攻撃者はまず「侵入できる弱点がないか」を探します。この弱点こそが脆弱性です。例えば、

  • 公開された脆弱性のパッチを適用していない
  • 古いプログラムを長期間放置している
  • 不要なサービスやポートを開けたまま

といった状態は、攻撃者に「ここから入れる」と示しているようなものです。実際、多くのサイバー攻撃は “脆弱性の悪用” から始まっています。

脆弱性が多く報告されるソフトウェアに共通する特徴

脆弱性が数多く報告されているのは、一体どんなソフトウェアでしょう。ひとつ共通することは「ユーザが多い」ということです。たとえば、皆さんがこのサイトをご覧になっているWebブラウザ、そのWebブラウザが動作するMicrosoft WindowsなどのOS、ビジネスでよく使われるPDFファイルを扱うAdobe Acrobat、WebサーバソフトのApache、データベースアプリケーションのMySQLなどです。いずれも、全世界に膨大な数のユーザを持つソフトウェアであり、規模のインパクトという点から、攻撃者にとって極めて魅力的、いわば人気があるのです。かつ、このようなソフトウェアでは、開発元において、脆弱性を早期に発見し、修正プログラムの公開、所定機関への報告を迅速に行う必要性が高いことから、報告件数が当然ながら多くなる傾向がみられます。

ここまでの説明でお気づきかもしれませんが、「脆弱性が多く報告されている」ことは必ずしも「品質が悪い」ことを意味するのではありません。脆弱性が存在してもそのことが報告・公表されていなければ、「脆弱性がある」とは認知されないわけです。

脆弱性を放置するとどうなる?企業への影響

脆弱性をそのままにしておくと、次のような重大なリスクがあります。

  • 重要情報(顧客情報・社員情報・機密情報等)の漏えい
  • サイバー攻撃(ランサムウェア攻撃等)を受けるリスク
  • サービス停止や業務停止リスク

特に近年は、脆弱性を狙った攻撃が高度化し、攻撃者が自動的に弱点を探索するツールも普及しています。「気づいたら侵入されていた」というケースも少なくありません。

脆弱性を突かれた場合のリスク

悪意のある第三者によって脆弱性を突かれてしまった場合、問題箇所の悪用、コンピュータ内部データ(情報)の盗取・改竄・削除、また他のコンピュータへの同様の悪事が可能になります。その結果、不正アクセスや自動的に動作させるウイルスやボットに感染する恐れもあります。また、システムやサービス全体という視点からは、設定に関して何らかの誤りがある場合など、設定ミスが脆弱性とみなされます。たとえば、ポートの開放に関する設定、権限管理、AWSをはじめとするクラウドサービスの設定ミスがセキュリティ事故を招いた例は枚挙に暇がありません。

脆弱性を悪用したセキュリティ事故は日々発生しています。SQAT.jpでは以下の記事でも取り上げていますので、ぜひあわせてご参考ください。

● 「定期的な脆弱性診断でシステムを守ろう!-放置された脆弱性のリスクと対処方法-
● 「備えあれば憂いなし!サイバー保険の利活用

企業が実施すべき脆弱性対策

脆弱性対策の基本的な考え方としては、システムの欠陥をつぶし、脆弱性を無くすこと(「攻撃の的」を無くすこと)が最も重要です。企業での実践方法としては以下の項目があげられます。

修正パッチの適用


衣服等の破れを補修する「継ぎ当て」や傷口に貼る「絆創膏」のことを英語で「パッチ(patch)」と言いますが、脆弱性を修正するプログラムも「パッチ」と呼ばれます。修正プログラムを適用することは「パッチをあてる」と言われたりします。パッチをあてることにより、システムに影響が及ぶ場合があります。適用にあたっては事前に調査を行い、必要に応じて十分な検証を実施してください。なお、自組織で開発したシステムに関しては、必ずテスト環境を用意し、パッチ適用による整合性チェックを行いましょう。

ソフトウェアやOSの定期的なアップデート

アップデートされた最新バージョンでは既知の脆弱性や不具合が修正されていますので、後回しにせずに更新を行うようにしてください。

セキュアプログラミングで脆弱性を作りこまない体制に

自組織で開発したソフトウェアやWebアプリケーション等の場合は、サービスが稼働する前の上流工程(開発段階)から、そもそも脆弱性を作り込まない体制を構築することが大切です。

また、テレワーク環境では、以上の項目に加え、クライアントサイドでのパッチ適用が適切に行われているかをチェックする体制を構築することも重要です。また、シャドーITの状況把握も厳格に実施する必要があります。

「IT部門が知らないサービスを勝手に利用され、結果として脆弱性の有無について未検証のクライアントソフトやブラウザプラグインが使われていた」という事態は防がねばなりません。

脆弱性情報はWebサイトでチェックできる

脆弱性は、さまざまなソフトウェアやプラットフォームで日々発見されています。そうした情報は、多くの場合、ソフトウェアやプラットフォーム提供元のWebサイトに掲載されます。
少なくとも、自組織で利用している主要なプラットフォームに関しては、緊急性が高い脆弱性が出現していないかどうかを、提供元のWebサイトで定期的にチェックするとよいでしょう。

JVNを利用した脆弱性情報の正確な情報収集と活用法

一般社団法人JPCERTコーディネーションセンターとIPA(独立行政法人情報処理推進機構)では、公表された脆弱性情報を収集して公開するサービス「JVN(Japan Vulnerability Notes)」を共同運営しています。日本で利用されている大半のソフトウェアの脆弱性の情報は、このサイトでチェックできます。

脆弱性情報ソースと活用

インシデントやゼロデイの発生情報については、セキュリティ専門のニュースサイト、セキュリティエバンジェリストのSNSなどからも情報をキャッチできます。

情報の裏取りとして、セキュリティベンダからの発表やtechブログ等を参照することもと重要となります。攻撃の影響範囲や危険度を確認するには、Exploitの有無を技術者のPoC検証ブログやNVD等で確認することも有効です。

ツールを使って脆弱性を見つける

脆弱性を発見するためのソフトウェアは「チェックツール」「スキャンツール」「スキャナ」などと呼ばれます。以下に、代表的なものをご紹介しましょう。有償、無償のさまざまなツールが提供されていますので、機能や特徴を知り、ニーズに合致するものを試してみてはいかがでしょうか。

  有償ツール 無償ツール
Webアプリケーション向けAppScan、Burp Suite、WebInspect など OWASP ZAP など
サーバ、ネットワーク向け Nessus(一部無償)、nmap など Nirvana改弐、Vuls など

「脆弱性診断」サービスで自組織のソフトウェアの脆弱性を見つける

上記でご紹介したツールを使えば、脆弱性のチェックを自組織で行うことが可能です。しかし、前述の通り、「脆弱性が存在するのに報告されていない」ために情報がツールに実装されていないソフトウェアも数多くあります。また、一般に広く利用されているソフトウェアであれば次々に脆弱性が発見、公開されますが、自組織で開発したWebアプリケーションの場合は、外部に頼れる脆弱性ソースはありません。さらに、実施にあたっては相応の技術的知識が求められます。そこで検討したいのが脆弱性診断サービスの利用です。脆弱性の有無を確認するには、脆弱性診断が最も有効な手段です。

脆弱性診断サービスでは、システムを構成する多様なソフトウェアやWebアプリケーション、API、スマホアプリケーション、ネットワークなどに関し、広範な知識を持つ担当者が、セキュリティ上のベストプラクティス、システム独自の要件などを総合的に分析し、対象システムの脆弱性を評価します。組織からの依頼に応じて、「自組織で気付けていない脆弱性がないかどうか」を調べる目的のほか、「脆弱性に対して施した対策が充分に機能しているか」を検証する目的で実施することもできます。

対策が正常に機能しているかの検証を含めた確認には専門家の目線をいれることをおすすめしています。予防的にコントロールをするといった観点も含め、よりシステムを堅牢かしていくために脆弱性診断をご検討ください。

脆弱性との共存(?)を図るケースもある

最後に、診断で発見された脆弱性にパッチをあてることができないときの対処法をご紹介しましょう。

まず、「パッチを適用することで、現在稼働している重要なアプリケーションに不具合が起こることが事前検証の結果判明した」場合です。このようなケースでは、システムの安定稼働を優先し、あえてパッチをあてずに、その脆弱性への攻撃をブロックするセキュリティ機器を導入することで攻撃を防ぎます。セキュリティ機器によって「仮想的なパッチをあてる」という対策になるため、「バーチャルパッチ」とも呼ばれます。

また、脆弱性が発見されたのがミッションクリティカルなシステムではなく、ほとんど使われていない業務アプリであった場合は、脆弱性を修正するのではなく、そのアプリ自体の使用を停止することを検討できるでしょう。これは、運用によってリスクを回避する方法といえます。

なお、前項でご紹介した脆弱性診断サービスの利用は、脆弱性に対して以上のような回避策をとる場合にも、メリットがあるといえます。発見された脆弱性について、深刻度、悪用される危険性、システム全体への影響度といった、専門サービスならではのより詳細な分析結果にもとづいて、対処の意思決定を行えるためです。

まとめ:脆弱性を理解することが攻撃対策の第一歩

「脆弱性とは何か?」を正しく理解することは、サイバー攻撃に備えるうえで最も基本かつ重要なステップです。脆弱性は放置すれば攻撃者にとって“格好の入口”となり、情報漏えいやサービス停止など重大な被害を招きかねません。自社システムの安全性を確保するためにも、日頃から更新・診断・運用の見直しを行い、脆弱性を適切に管理することが求められます。

関連情報

● 脆弱性診断の必要性とは?ツールなど調査手法と進め方

Webアプリケーション脆弱性診断バナー

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

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

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

AIコーディング入門
第2回:プロンプト以外で効率化!開発体験の改善手法

Share

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

AIコーディング2アイキャッチ(AIコーディングの効率化の手法と課題)

生成AIを使ったコーディングでは、プロンプトエンジニアリングが効率化の王道として知られています。しかし実際には、RAG(検索拡張生成)やファインチューニングといった手法を組み合わせることで、さらに精度や体験を向上させることが可能です。本記事では、これらの技術の概要とAIコーディングにおける活用例、そして共通して立ちはだかる品質・性能・セキュリティの課題とその解決の方向性を解説します。

※本稿は2025年7月上旬に執筆しているものです。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

プロンプトエンジニアリング以外の効率化手法

プロンプトエンジニアリングは、手軽に(安価に)試せる生成AIの体験の改善や効率化の手法として位置づけられています。そして、プロンプトエンジニアリング以外でも生成AIの効率化や体験の改善、特定の目的のための調整などができる手法としてファインチューニングRAG(Retrieval-Augmented Generation)があります。以下の図はそれぞれの手法を簡単にまとめたものです。

図 1 プロンプトエンジニアリング、RAG、ファインチューニングの概要

AIを使ったコーディング(以下AIコーディング)でもこの3つの手法は生成コードの改善や生成プロセスの効率化のために用いられます。また、企業や組織でのコーディングに際しては、個人レベルでの作業でのプロンプトエンジニアリング、内部レポジトリやAPIドキュメントとの結合による効率化を行うRAG、コーディング規約やスタイルなどの品質管理などを目的としたファインチューニングというように、目的別に同時並行で使うことができます。

AIコーディング全般に共通する課題

AIコーディング自体は一般的といえる領域に入りつつあります注 1) が、一方でAIコーディング全般に共通する課題として、大きく分けて以下の3つの課題が挙げられます注 2)

ロジックの不整合

  • 小さなコードであれば問題にならないことも多いですが、大きなコードになればなるほど、コード内のロジックで不整合が発生することが増えます
  • プロンプトで与えられているビジネス上の目的を正しく解釈できない場合、期待されない出力をする可能性もあります

メモリなどのボトルネックに対する配慮の欠如

実行環境に関する配慮がないため、メモリを予想以上に使用するコードや、処理パフォーマンスに配慮しない出力が出てくることが往々にしてあります

セキュリティへの配慮の欠如

  • セキュリティに対して前出のような配慮事項を指示しない限りは配慮が欠如していることが多くあります
  • 仮に配慮事項の指示を行っても不正確・セキュアでない出力が出される確率も一定程度残存します

品質とセキュリティを守るプロセス設計

AIコーディングが進化してもなお、人の手にゆだねられているものがあります。それは「何のためにコーディングするのか」「コードを使ってどんな業務をして、その結果として何を得るのか」といったビジネス上の目的を設定することと、コードが正確に動作することやセキュリティ上問題がないことを確認するプロセスを設けることです。コードの品質やセキュリティに関するプロセスは通常、ソースコード診断でセキュリティの確認を行うことが一般的です。

最近ではDevSecOpsの一環として、コード開発中にSAST(Static Application Security Testing)ツールをCI/CDパイプラインに統合するケースも増えてきています。また、完成品に対するテストとしてDAST(Dynamic Application Security Testing)を実行することも必要でしょう。これはWebサイトであればWebアプリケーション診断が該当します。


―第3回「AIエージェント時代のコーディング:MCPとA2Aとは」へ続く―

注:
1)2024年5月に実施されたプログラマー・エンジニアを中心としたコミュニティであるStackOverflowによる調査では開発にAIを利用すると回答したプロフェッショナルの開発者は63.2%でした。
2)CSET “Cybersecurity Risks of AI Generated Code” (Jessica Ji, Jenny Jun, Maggie Wu, Rebecca Gelles, November 2024)

【参考情報】

【連載一覧】

―第1回「Vibeコーディングとプロンプトエンジニアリングの基礎」―
―第2回「プロンプト以外で効率化!開発体験の改善手法」―
―第3回「AIエージェント時代のコーディング:MCPとA2Aとは」 ―
―第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装」―
第5回「AIとセキュリティ:Non‑Human Identity とAIエージェントの課題
第6回「AIエージェントのセキュリティ対策と今後の展望


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

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

  • 2025年9月3日(水)13:00~14:00
    止まらないサイバー被害、その“対応の遅れ”はなぜ起こる?~サイバー防衛の未来を拓く次世代XDR:大規模組織のセキュリティ運用を最適化する戦略的アプローチ~
  • 2025年9月10日(水)14:00~15:00
    フィッシング攻撃の最新脅威と被害事例〜企業を守る多層防御策〜
  • 2025年9月17日(水)14:00~15:00
    サイバーリスクから企業を守る ─脆弱性診断サービスの比較ポイントとサイバー保険の活用法─
  • 最新情報はこちら


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

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

    AIコーディング入門
    第1回:Vibeコーディングとプロンプトエンジニアリングの基礎

    Share

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

    AIコーディング入門(1)アイキャッチ画像(AIと人のイメージ)

    AIの進化によって、ソフトウェア開発の現場では「コードを書く」という行為そのものが変わり始めています。本シリーズ「AIコーディング入門」では、生成AIを活用した新しい開発スタイルを多角的に解説します。第1回では、注目のキーワードである「Vibeコーディング」と「プロンプトエンジニアリング」について、その意味や実際の活用方法、そして潜む課題についてご紹介します。

    ※本稿は2025年7月上旬に執筆しているものです。ご覧いただく時期によっては古い情報となっている場合もありますので、ご承知おきください。

    Vibeコーディングとは何か?

    「Vibeコーディング」という言葉をご存じでしょうか。この言葉はOpenAI社の創設メンバーの一人であるアンドレイ・カーパシー(Andrej Karpathy)が2025年2月にXに投稿したポスト注 1)で使った言葉で、以降、生成AIを利用したコーディングの中でも雰囲気、ノリ、感覚注 2)を軸にしたコーディングを表す言葉で、2025年上半期のAIコーディング関連の流行語といっても過言ではないでしょう。

    言葉の由来と流行の背景

    Vibeコーディングが指すコーディングはコードそのものを書くことよりも、大まかな目標や感覚に基づいてAIをアシスタントとして活用しながらコードを作っていく行為を指しています。この言葉は流行語ならではの賛否両論を巻き起こしていますが、そもそも言い出した本人も「雰囲気(vibe)」で使った言葉でしょうから、確固たる定義があるわけでもないのが実情で、真面目に語るほどでもないのかもしれません。実際に生成AIを使用してちょっとしたコーディングをすると、(特に最近のモデルを使う場合は)人間が目標や要件を定義してしまえば、ある程度の規模のコードまでは自動的に生成してくれるようになってきています。一度でもコーディングに使ったことがある人であれば、Vibeコーディングが指すものは何となくわかる、そんな流行語なのでしょう。

    Vibeコーディングの最大の問題

    一方でVibeコーディングの最大の問題として挙げられるのが、プログラミングの概念が理解できない人でもコードを生成できるという点です。SNSなどをみると、Vibeコーディング、要するに生成AIによる自然言語のプロンプトによってコードの生成数が上がっても品質が低いため、かえって確認に手間取るという指摘をよく見かけます。また、手動でプログラミングを進める機会・経験が減ることでコードのテストやデバッグといったプロセスを知るエンジニアが逓減ていげんしていき、結果として誰もコードの品質の確保できる人がいないのではないかという指摘も多くみられます。また、そもそも生成AIの生成するコード自体の信頼性は低いという指摘もあります。

    セキュリティ指示の有無がコード生成に与える影響

    2025年に公開された論文とその後の研究結果を公開しているWebサイト注 3)では、セキュリティに関する指示をプロンプト内で与えない場合と一般的なセキュリティに関する指示を与えた場合、そして非現実的かつ厳格なセキュリティに関する指示を与えた場合とで生成AIのコードの正確性やセキュアさについての各モデルの比較がされています。一般的な指示はベストプラクティスに従うことと脆弱性を作らないことだけを指示するもので、さらに厳格な指示では一般的な指示に加えて特に指定した脆弱性注 4)に対してコードが安全であることを確認することを指示するものとなっています。指示が全くない場合に比べて、一般的な指示だけでも不正確またはセキュアでないコードの割合を抑制する傾向にあること、厳格な指示であれば正確かつセキュアなコードの割合を押し上げる効果があることが全体としてみて取れます。注 5)少なくとも、という話にはなりますが、AIでコードを生成する際にはセキュリティに対して配慮した内容をプロンプトに少し含めるかどうかだけでも多少の差が出るというのは意識する価値がありそうです。ただしプロンプトを配慮しても完璧は目指せない点にも注意が必要です。

    プロンプトエンジニアリング

    Vibeコーディングという言葉が世に放たれた頃、ちょうど生成AI各社がプロンプトエンジニアリングガイドを公開しました。下表は生成AIサービス各社が提供するプロンプトエンジニアリングガイドの一覧です。いずれも利用者が生成AIに対して適切かつ効率的なプロンプトを入力することで、生成AIが利用者の意図を理解し、期待される回答を出力するためのガイドになっています。

    表 1 主要なプロンプトエンジニアリングガイド一覧

    会社名生成AIサービスプロンプトエンジニアリングガイド
    AnthropicClaudehttps://docs.anthropic.com/ja/docs/build-with-claude/prompt-engineering/overview
    GoogleGemini, Vertexhttps://cloud.google.com/discover/what-is-prompt-engineering?hl=ja
    OpenAIChatGPT, Sorahttps://help.openai.com/en/articles/6654000-best-practices-for-prompt-engineering-with-the-openai-api

    曖昧な指示が生むAIの誤解

    AIコーディングにおける課題の一つは、利用者が生成AIにプロンプトとして与えるコンテキストに一貫性がない、生成AIが処理するには非常に曖昧である、という点にあります。この課題の回避方法の一つとして提示されているものがプロンプトエンジニアリングガイドとなります。一番コストがかからず、人の手で微調整ができる手法として、まずは確認されることをおすすめします。あわせて前項で述べたように、非常に基本的な指示からでもセキュリティに関する指示を含めることもおすすめします。


    ―第2回「プロンプト以外で効率化!開発体験の改善手法」へ続く―

    注:
    1)https://x.com/karpathy/status/1886192184808149383
    2)日本語でも若年層を中心に使われている「バイブス」という言葉と同じような意味合いになります
    3)なおLLMのコーディングベンチマークフレームワークも提供しています。https://github.com/logic-star-ai/baxbench
    4)次のCWE(Common Weakness Enemuration、共通脆弱性タイプ)をプロンプト内で指定しています: CWE-20(不適切な入力確認)、CWE-22(パストラバーサル)、CWE-78(OSインジェクション)、CWE-79(クロスサイトスクリプティング)、CWE-89(SQLインジェクション)、CWE-94(コードインジェクション)、CWE-117(ログ出力の不適切な無効化)、CWE-284(不適切なアクセス制御)、CWE-400(無制限のリソースの枯渇)、CWE-434(危険なタイプのファイルの無制限アップロード)、CWE-522(認証情報の不十分な保護)、CWE-703(例外的な状況に対する不適切なチェックまたは処理)、CWE-863(不正な認証)
    5)ただし推論モデルに関しては指示の出し方によって正確・セキュアなコードの出力が得られる確率がセキュリティに関する指示がない場合に比べて悪化する場合もあります。これは推論モデル自体の問題であると考えられます。なお、推論モデルの問題については次の2論文で問題点がそれぞれ指摘されています。https://arxiv.org/pdf/2307.02477
    https://machinelearning.apple.com/research/illusion-of-thinking

    【連載一覧】

    第1回「Vibeコーディングとプロンプトエンジニアリングの基礎」
    第2回「プロンプト以外で効率化!開発体験の改善手法
    第3回「AIエージェント時代のコーディング:MCPとA2Aとは
    第4回「MCPの脆弱性とA2A脅威分析から学ぶセキュリティ実装
    第5回「AIとセキュリティ:Non‑Human Identity とAIエージェントの課題
    第6回「AIエージェントのセキュリティ対策と今後の展望


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

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

  • 2025年8月5日(火)14:00~15:00
    企業サイトオーナー向け ユーザーからのレピュテーションを高めるWebサイトの在り方-Webサイトを取り巻くリスク・規制・要請とユーザビリティ向上-
  • 2025年8月20日(水)13:00~13:30
    EC加盟店・PSP必見!クレジットカード・セキュリティガイドライン6.0版対応ウェビナー
  • 2025年8月27日(水)13:00~14:00
    【最短7営業日で診断&報告】サイバー保険付帯脆弱性診断「SQAT® with Swift Delivery」のご紹介
  • 最新情報はこちら


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

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

    【第1回】「OWASP Top 10とは?アプリケーションセキュリティの基本を押さえよう」

    Share

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

    近年、Webアプリケーションを狙ったサイバー攻撃が急増しており、企業にとってWebアプリケーションのセキュリティ強化は欠かせない課題となっています。その中で、世界中のセキュリティ専門家が指標として活用しているのが「OWASP Top 10」です。

    今回は、Webアプリケーションの代表的な脆弱性をまとめた「OWASP Top 10」を通じて、基本的なセキュリティ知識を深め、企業での対策に活かすことを目的とし、背景から各脆弱性カテゴリの説明、実例、対策方法までを全3回のシリーズに分けて解説します。

    OWASPとは

    OWASP(Open Worldwide Application Security Project)は、ソフトウェアのセキュリティ向上を目的とした国際的な非営利団体です。開発者やセキュリティ専門家によって構成されており、セキュリティに関するツールやドキュメントなどを無償で提供しています。OWASPは中立かつオープンな立場から情報を発信しており、多くの企業や政府機関がそのガイドラインを信頼し、採用しています。

    OWASP Top 10とは

    OWASP Top 10は、Webアプリケーションにおける代表的なセキュリティリスクをランキング形式でまとめたもので、最も重要な10の脆弱性カテゴリを示しています。このリストはおよそ3年ごとに更新されており、業界の最新動向や実際の脅威傾向を反映しています。このTop 10は、アプリケーション開発やセキュリティ教育、脆弱性診断の指針として世界中で活用されており、情報システム部門にとってはセキュリティの共通言語ともいえる存在です。

    OWASP Top 10:2021概要

    OWASP Top 10:2021で挙げられているリスクとその概要について、SQAT.jpでは以下の記事でも取り上げています。あわせてぜひご覧ください。
    OWASP Top 10―世界が注目するWebアプリケーションの重大リスクを知る―

    以下は、2021年に発表された最新版のOWASP Top 10のリストです。

    項目番号リスク名概要
    A01Broken Access Control
    (アクセス制御の不備)
    アクセス制御の不備により、本来アクセスできない情報や機能へアクセスされるリスク
    A02Cryptographic Failures
    (暗号化の不備)
    暗号化の不備による機密情報の漏洩や改ざん
    A03Injection
    (インジェクション)
    SQLインジェクションなど、外部から不正なコードを注入されるリスク
    A04Insecure Design
    (セキュアでない設計)
    セキュリティを考慮しない設計により生じる構造的リスク
    A05Security Misconfiguration
    (セキュリティ設定のミス)
    設定ミスや不要な機能の有効化に起因する脆弱性
    A06Vulnerable and Outdated Components(脆弱かつ古いコンポーネントの使用)脆弱性を含む古いライブラリやフレームワークの使用
    A07Identification and Authentication Failures(識別と認証の不備)認証処理の不備により、なりすましや権限昇格が発生する
    A08Software and Data Integrity Failures(ソフトウェアとデータの整合性の不備)ソフトウェア更新やCI/CDの不備により改ざんを許すリスク
    A09Security Logging and Monitoring Failures(セキュリティログとモニタリングの不備)侵害の検知・追跡ができないログ監視体制の欠如
    A10Server-Side Request Forgery (SSRF)(サーバサイドリクエストフォージェリ)サーバが内部リソースにアクセスしてしまうリスク
    出典:OWASP Top 10:2021より弊社和訳

    各リスク項目の代表的な脅威事例

    項目番号実例企業・事例概要
    A01Facebook (2019)他人の公開プロフィールがIDの推測とAPI操作により取得可能だった*8
    A02Turkish Citizenship Leak(2016)暗号化されていなかったデータベースから約5,000万人の個人情報が流出*9
    A03Heartland Payment Systems (2008)SQLインジェクションにより1億件以上のクレジットカード情報が漏洩*10
    A04パスワードリセットの仕様不備(複数事例)多くの中小サイトで、トークンなしにメールアドレス入力のみでリセット可能な設計が確認されている
    A05Kubernetes Dashboard誤設定事件(Tesla 2018)管理用インターフェースが公開状態になっており、社内クラウドで仮想通貨マイニングに悪用された*11
    A06Equifax (2017)古いApache Strutsの脆弱性(CVE-2017-5638)を放置していたことで1.4億件以上の個人情報が漏洩*12
    A07GitHub (2012)認証処理の不備により、セッションを乗っ取られる脆弱性が悪用され、一時的にユーザが他人のリポジトリにアクセス可能に
    A08SolarWinds サプライチェーン攻撃(2020)正規のソフトウェアアップデートにマルウェアが仕込まれ、多数の政府機関や企業を含めた組織に影響を与えた
    A09Capital One (2019)AWS環境の不適切なログ監視により、Web Application Firewallの設定ミスから約1億600万人分の情報が流出*13
    A10Capital One (同上)SSRF攻撃によりAWSメタデータサービスへリクエストが可能となり、内部資格情報を窃取された*14

    企業はOWASP Top 10をどう活用すべきか

    OWASP Top 10は、単なる「参考資料」ではなく、企業が自社のセキュリティ対策を体系的に見直すための実践的な指針として活用できます。以下に、企業の情報システム部門担当者等が実際に取り入れるべき活用方法を紹介します。

    開発プロセスへの組み込み(セキュア開発)

    アプリケーション開発において、設計段階からOWASP Top 10を参考にすることで、設計段階から脆弱性を防ぐ「セキュア・バイ・デザイン(Secure by Design)」の思想を組み込むことが可能です。とくにA04「Insecure Design」などはアプリケーション開発の初期段階での対策が鍵となります。

    脆弱性診断の評価基準として

    外部のセキュリティ診断会社や自社診断の基準としてOWASP Top 10を採用することで、リスクの見落としを防ぎつつ、業界標準の診断を実現できます。

    セキュリティ教育・啓発資料として

    企業の社員のセキュリティリテラシーを高めるため、開発者・インフラ管理者・経営層を含めたセキュリティ教育プログラムにOWASP Top 10を取り入れることも有効です。定期的な研修やハンズオン形式での演習と組み合わせることで、具体的な攻撃手法や防御策を理解しやすいため、セキュリティ意識の向上につながります。

    OWASP Top 10はセキュリティ対策の出発点

    OWASP Top 10は、Webアプリケーションの開発やセキュリティ対策に取り組む企業にとって、最も基本かつ重要な指標です。サイバー攻撃の多くは、実はこうした「基本的な脆弱性」から発生しており、OWASP Top 10で挙げられているリスクを理解することがリスク低減の第一歩になります。特に情報システム部門や開発チームは、OWASP Top 10を設計・開発・テスト・運用の各フェーズに取り入れ、継続的なセキュリティ対策を行う必要があります。また、社員へのセキュリティ教育や脆弱性診断サービスの評価基準としても有効活用することで、より実効性の高いセキュリティ体制を構築できるでしょう。

    第2回では、API特有の脅威にフォーカスした「OWASP API Security Top 10」をご紹介します。APIを活用している企業にとって、見逃せない内容となっていますので、ぜひあわせてご覧ください。


    ―第2回「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」へ続く―

    【連載一覧】

    ―第2回「OWASP API Security Top 10とは?APIの脅威と対策を知ろう」―
    ―第3回「Non-Human Identities Top 10とは?自動化時代に求められる新しいセキュリティ視点」―

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


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

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

    “攻撃者の格好の標的”から外す!中小企業のサイバーセキュリティ-中小企業が狙われるサプライチェーン攻撃とサイバーセキュリティ強化術-

    Share

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

    中小企業はサイバー攻撃者の格好の標的とされることも多く、特にサプライチェーン攻撃で狙われるリスクが高まっています。そこで、自組織におけるリスクの可視化やセキュリティ対策の定期的な見直しをすることが重要です。本記事では中小企業のサイバーセキュリティの現状やそれによって起こり得る影響、サプライチェーン攻撃の事例を踏まえ、効果的なセキュリティ対策と見直しのポイントを解説します。

    ペネトレーションテストの有効性やシナリオ解説をまとめたホワイトペーパーを公開中!以下のリンクから無料でダウンロードいただけます。
    記事はこちら

    中小企業のサイバーセキュリティの現状

    昨今、中小企業のサイバーセキュリティ対策に注目が集まっています。中でも、大手企業が取引先に求める安全性が、サプライチェーン全体へと波及し、サプライチェーン攻撃が大きな問題となっています。その要因には、日本の企業の約9割が中小企業であり*2、大企業の関連会社、取引先企業を含め多くを中小企業が占めているという点が挙げられます。

    認識と実態のギャップ

    日本商工会議所の調査では、「十分に対策している」「ある程度対策している」と回答した企業は86%と高い水準で、回答した企業のほとんどが「自社は対策している」と考えているようです。しかし、実際に行われているセキュリティ対策の内訳をみると、「ウイルス対策ソフト」(90.1%)、「ソフトウェアの定期的なアップデート」(72.6%)が中心で、「社内教育」、「セキュリティ診断」、「訓練」などといった専門的な対策については、いずれも30%以下にとどまっています。本来であれば十分な対策をしていると言えるのは、専門的な対策まで実施して言えるものです。この認識と実態のギャップが、サプライチェーン全体の脆弱性を生み、取引先への被害連鎖を招くリスクを高めています。

    認識と実態のギャップ
    出典:日本商工会議所「サイバー安全保障分野での対応能力の向上に向けた有識者会議」ヒアリング資料(資料3)

    ここまで中小企業のサイバーセキュリティの現状と対策の実施状況についてご紹介しました。では、サイバー攻撃の標的となった場合、中小企業に与える影響とはどのようなことがあるのでしょうか。

    サイバー攻撃が中小企業に与える影響

    中小企業のサイバーセキュリティ対策が不十分だと、自社だけでなくサプライチェーン全体に深刻な影響が及びます。IPA(独立行政法人情報処理推進機構)「2024年度中小企業等実態調査結果」(速報版/2025年2月公開)によれば、調査対象の中小企業の約70%が「自社のサイバーインシデントが取引先事業に影響を与えた」と回答しています。自社だけでなくサプライチェーン全体を見据えた取り組みをしないと、連鎖的に被害が拡大し、取引先企業の業務停止や企業の信用失墜、最悪の場合は損害賠償請求にまで発展するケースも少なくありません。

    サプライチェーンで狙われる中小企業

    セキュリティ対策が手薄な関連企業や取引先企業を経由して、標的とする企業へ不正侵入をする「サプライチェーン攻撃」が急増しています。IPA「情報セキュリティ10大脅威 2025(組織編)」でも「サプライチェーンや委託先を狙った攻撃」が2位にランクインしています。

    サプライチェーン上には攻撃者にとって魅了的な、機密情報、知的財産、顧客データなどが流れ、中小企業が格好の標的になりがちです。中小企業が狙われる要因として、攻撃者の最終的なターゲットとなりうる大手企業とつながりがあることや、予算や人材不足などの制約によってセキュリティ対策が不十分になりがちなことなどが挙げられます。

    サプライチェーン管理で陥りがちな落とし穴

    サプライチェーンでは、以下のような課題が連鎖的な脆弱性を生み出します。

    • リモートワーク環境下などで委託先のセキュリティ状況が可視化できず、実態が把握できない
    • セキュリティ基準や管理体制が統一されず、企業間で対策レベルに大きな格差が発生
    • 人材や予算が限られる中小企業では、セキュリティ対策が後回しになりがち

    こうした課題が積み重なると、委託先の一つの企業で発生したインシデントが再委託先まであっという間に波及し、大企業を含むサプライチェーン全体が火だるまとなり得ます。そのため、中小企業のサイバーセキュリティ対策には、関係先を含めた統一ルールと継続的な情報共有が不可欠です。

    サプライチェーン攻撃の事例

    2023年11月27日、メッセージアプリ提供会社が、自社サーバへの不正アクセスでメッセージアプリに関するユーザ情報・取引先情報、従業者情報等が漏洩したことを公表しました。

    発端は、同社と関係会社が共用する委託先業者の従業員PCがマルウェアに感染し、共通認証基盤を経由してメインシステムに侵入されたことです。共通の認証基盤で管理されているシステムへネットワーク接続を許可していたことから、同社のシステムに不正アクセスされました。(下図参照)

    この事例から関係会社との認証基盤の共有や、ネットワークアクセス管理、委託先業者の安全管理など、セキュリティ対策、見直しを行うべきポイントが浮き彫りになり、中小企業でも委託先の安全管理の甘さが同様の被害を招く可能性が示されました。委託先業者の安全管理は委託先業者の責任とせずに、自社のセキュリティの一角と認識して対応することが重要です。

    中小企業のサイバーセキュリティ対策

    中小企業のサイバーセキュリティ強化には、自社だけでなくサプライチェーン全体での取り組みが不可欠です。

    サプライチェーン全体への取り組み

    サプライチェーン全体では、次の3点を定期的に確認しましょう。

    • サプライチェーン上の各企業におけるセキュリティ状況の把握(アンケート調査等の実施)
    • サプライチェーン上にセキュリティ水準の異なる企業があるか確認
    • サプライチェーン上の企業間における重要情報の定義と取り扱い方法の取り決め実施

    ポイントは、常に自社/自組織が当事者であるという姿勢です。以下のような基本的な対応がとられているか、今一度ご確認いただくことをおすすめします。

    自社・自組織での基本的な取り組み

    • 自社/自組織のセキュリティ状況の把握と対策
    • 取引先/委託先のセキュリティ対策状況の監査
    • 使用しているソフトウェアに関する脆弱性情報のキャッチアップ 等

    また、以下のガイドラインもあわせて参照することを推奨します。
    経済産業省 商務情報政策局 サイバーセキュリティ課
    ソフトウェア管理に向けたSBOM(Software Bill of Materials)の導入に関する手引Ver.1.0
    OSS の利活⽤及びそのセキュリティ確保に向けた 管理⼿法に関する事例集

    「SBOM (Software Bill of Materials)」について、SQAT.jpでは以下の記事でご紹介しています。こちらもあわせてご覧ください。
    脆弱性管理とIT資産管理-サイバー攻撃から組織を守る取り組み-

    まとめ:今すぐ自組織のセキュリティ対策の見直しを!

    中小企業のサイバーセキュリティ強化は、自社だけでなく取引先や委託先を含むサプライチェーン全体での取り組みが欠かせません。まずは以下のステップを実践して被害のリスクを最小化しましょう。

    1. 現状把握:年1回以上の脆弱性診断やペネトレーションテストで、自社システムのリスクを可視化
    2. サプライチェーン調査:アンケートや監査で取引先のセキュリティ水準を確認・格差を是正
    3. 自社・自組織のルールの策定:重要情報の定義と取り扱い方法を取引先と合意・文書化
    4. 外部の専門家活用:ガイドラインを参照し、第三者レビューで対策の網羅性を担保
    5. 継続的な見直し:四半期ごとに状況を更新し、セキュリティ運用を見直す

    サプライチェーン関連記事はSQAT.jpで公開中!こちらからご覧ください。
    サプライチェーンとは-サプライチェーン攻撃の脅威と対策1-
    事例から学ぶサプライチェーン攻撃-サプライチェーン攻撃の脅威と対策2-
    サプライチェーン攻撃への対策 -サプライチェーン攻撃の脅威と対策3-

    過去のウェビナー再配信に関するお問い合わせはこちら

    セキュリティ対策は専門家に相談を

    サイバー攻撃手法は日々更新されており、どんなにセキュリティ対策を実施していても自組織のみではインシデントの発生を防ぎきれないのが実情です。自システムのリスク状況の把握には、脆弱性診断の実施がおすすめです。また、サイバー攻撃への備えとして、セキュリティ対策の有効性の確認には信頼できる第三者機関の活用をおすすめします。

    脆弱性診断

    脆弱性診断のより詳しい診断手法や実践ポイントをまとめたホワイトペーパーを公開中!以下のリンクから無料でダウンロードいただけます。
    記事はこちら

    脆弱性とは…
    ・外部からアクセスできる箇所に攻撃の起点として悪用され得る脆弱性や設定の不備が存在しないかどうかを確認することも重要。その際に有効なのが「脆弱性診断」
    ・攻撃者はシステムの脆弱性を突いて侵入を試みるため、診断によって脆弱な領域を洗い出し、優先度に応じた対策を講じる。診断は、定期的に実施するだけでなく、システム更改時にも必ず実施することが推奨される。
    【参考記事】
    拡大・高度化する標的型攻撃に有効な対策とは―2020年夏版
    「侵入」「侵入後」の対策の確認方法

    Webアプリケーション脆弱性診断バナー

    ペネトレーションテスト

    ペネトレーションテストの有効性やシナリオ解説をまとめたホワイトペーパーを公開中!以下のリンクから無料でダウンロードいただけます。
    記事はこちら

    ペネトレーションテストとは…
    ・ペネトレーションテストとは、脆弱性診断の結果、見つかった脆弱性を悪用して、システム・ネットワークへの不正侵入や攻撃が本当に成功するのかを検証することができるテスト手法のひとつ
    ・重要インフラ15分野では、内部監査と並んで情報セキュリティ確保のための取り組みとして例示されている。

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

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

  • 2025年6月18日(水)14:00~15:00
    侵入が防げない時代に選ぶべき脆弱性診断サービスとは?~実績・サポート・診断基準で比較する、最適な脆弱性診断の選び方~
  • 2025年6月25日(水)13:00~14:00
    リモートワークの落とし穴を塞ぐ!セキュリティ情報の効率的な収集法&対策のポイント
  • 2025年7月16日(水)14:00~15:00
    進化するランサムウェア攻撃-国内最新事例から学ぶ!被害を防ぐ実践ポイント10項目を解説-
  • 最新情報はこちら


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

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


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

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

    Share

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

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。


    はじめに

    米国サイバーセキュリティ・インフラストラクチャセキュリティ庁(CISA)から公開されている「KEVカタログ(Known Exploited Vulnerabilities)」は、実際に攻撃に悪用された脆弱性の権威あるリストとして、組織のセキュリティ対策の優先順位付けに不可欠なツールとなっています。本レポートでは、KEVカタログに掲載された全データのうち2025年1月1日~3月31日に登録・公開された脆弱性の統計データと分析結果を紹介し、2025年4月以降に注意すべきポイントや、組織における実践的な脆弱性管理策について考察します。

    KEVカタログ(Known Exploited Vulnerabilities)とは何か

    KEVカタログ(Known Exploited Vulnerabilities)とは、米国政府機関CISA(Cybersecurity and Infrastructure Security Agency)が公開する、既に悪用が確認された脆弱性(CVE)を一元管理する公式リストです。企業や組織のセキュリティ担当者は、実際に攻撃者に狙われた脆弱性情報を優先的に把握できるため、限られたリソースでも迅速かつ効率的にパッチ適用や検知ルール整備といった対策を講じることが可能になります。カタログに登録される条件は、エクスプロイトコードやマルウェアによる実害が報告されたものに限られ、一般的な脆弱性情報よりも高い優先度で対応を進められる点が大きな特徴です。四半期ごとに更新される最新のデータを活用することで、組織はリアルタイムに変化する脅威状況に即応し、リスク低減を図ることができます。

    概要 (2025年1月~3月に登録・公開されたKEVカタログ掲載CVE)

    2025年第一四半期(1月1日~3月31日)にCISAの既知悪用脆弱性カタログ(Known Exploited Vulnerabilities, KEV)に新規追加されたCVEエントリは73件に上りました*32

    CVE-2024-20439 CVE-2025-2783 CVE-2019-9875 CVE-2019-9874
    CVE-2025-30154 CVE-2017-12637 CVE-2024-48248 CVE-2025-1316
    CVE-2025-30066 CVE-2025-24472 CVE-2025-21590 CVE-2025-24201
    CVE-2025-24993 CVE-2025-24991 CVE-2025-24985 CVE-2025-24984
    CVE-2025-24983 CVE-2025-26633 CVE-2024-13161 CVE-2024-13160
    CVE-2024-13159 CVE-2024-57968 CVE-2025-25181 CVE-2025-22226
    CVE-2025-22225 CVE-2025-22224 CVE-2024-50302 CVE-2024-4885
    CVE-2018-8639 CVE-2022-43769 CVE-2022-43939 CVE-2023-20118
    CVE-2023-34192 CVE-2024-49035 CVE-2024-20953 CVE-2017-3066
    CVE-2025-24989 CVE-2025-0111 CVE-2025-23209 CVE-2025-0108
    CVE-2024-53704 CVE-2024-57727 CVE-2025-24200 CVE-2024-41710
    CVE-2024-40891 CVE-2024-40890 CVE-2025-21418 CVE-2025-21391
    CVE-2025-0994 CVE-2020-15069 CVE-2020-29574 CVE-2024-21413
    CVE-2022-23748 CVE-2025-0411 CVE-2024-53104 CVE-2018-19410
    CVE-2018-9276 CVE-2024-29059 CVE-2024-45195 CVE-2025-24085
    CVE-2025-23006 CVE-2020-11023 CVE-2024-50603 CVE-2025-21335
    CVE-2025-21334 CVE-2025-21333 CVE-2024-55591 CVE-2023-48365
    CVE-2024-12686 CVE-2025-0282 CVE-2020-2883 CVE-2024-55550
    CVE-2024-41713

    この期間中に追加された脆弱性には、政府機関や企業に広く使われるソフトウェアやデバイスの深刻な欠陥が多数含まれています。CISAは「これらの脆弱性は悪意あるサイバー攻撃者による頻出の攻撃経路であり、連邦政府エンタープライズに重大なリスクをもたらす」と警鐘を鳴らしており*33、各組織に対し迅速な修正を促しています。KEVカタログへの追加は、実際に攻撃で悪用された証拠に基づいて行われるため、当該期間中に登録された脆弱性は現在進行形で脅威となっているものばかりです。

    2025年Q1の登録件数トレンド

    Q1単体で73件というKEV追加件数は、昨年までのペースと比べても非常に多い数字です。実際、2023年および2024年通年の追加件数は各約180件程度で推移していました*34。単純計算で1四半期あたり45件前後のペースだったものが、2025年Q1は73件と約1.6倍に跳ね上がった形です。もしこのペースが年間を通じて維持されるとすれば、年間200件超はおろか300件近くに達する可能性もあり、前年までの安定推移を大きく上回る勢いです。

    この増加傾向の背景としては、考えられる要因がいくつかあります。一つは攻撃側の活発化です。実際、別の調査では「2025年Q1に新たに公表された“悪用された脆弱性”は159件にのぼる」とする報告もあり*35、脅威アクターが引き続き多数の新旧脆弱性を素早く攻撃に利用している状況が伺えます。もう一つは検知と公表の強化です。CISAやセキュリティ各社が脆弱性悪用の検知能力を高め、迅速に公表・警告する体制が整ってきたことで、KEVへの追加報告が増えている可能性もあります。いずれにせよ、今年は昨年以上に「既知の悪用脆弱性」が頻出している兆候であり、組織としてはこのペースに備えた体制強化が求められます。

    なお、KEVの新規追加は年間を通じて均一ではなく、特定の時期に集中する場合もあります。2025年は年始こそ緩やかな増加でしたが、2月後半から3月にかけて急増した週もありました(例: 3月前半の1週間で7件追加されたとの分析もあります)。このように脆弱性の悪用動向は季節や攻撃キャンペーンの状況によって変動するため、常に最新情報をウォッチする姿勢が重要です。

    ベンダー別登録状況

    2025年Q1に新規追加されたKEV脆弱性をベンダー別に見ると、Microsoft製品の脆弱性が最も多く含まれていました。これは毎年の傾向でもあり、Windowsをはじめとする同社製品が広範に使われ攻撃対象になりやすいことを反映しています*36。実際、1月にはMicrosoft WindowsのHyper-Vに関する未修正のカーネル脆弱性(Heap OverflowおよびUse-After-Free)が3件まとめて悪用確認されKEVに追加されました*37。また3月にはAppleのWebKitブラウザエンジンに起因するiPhone/iPad向けのゼロデイ脆弱性や、Juniper Networksのネットワーク機器OSの脆弱性が追加されており*38、Appleやネットワーク機器ベンダー(JuniperやCiscoなど)も上位に顔を出しています。

    特に注目すべきはIvanti(旧Pulse Secure等を含む)とMitelの台頭です。Ivantiについては、VPNアプライアンス「Connect Secure」やエンドポイント管理製品「Endpoint Manager」など複数の製品で脆弱性が相次ぎ悪用されました。例えば1月にはIvanti Connect Secure(旧Pulse Connect Secure)の深刻なバッファオーバーフロー欠陥(CVE-2025-0282)が国家規模の攻撃で使われた可能性が浮上し、KEV入りしています*39。さらに3月にはIvanti Endpoint Manager(EPM)に存在するパストラバーサル脆弱性3件が追加されました*40。Ivantiは2024年通年でも11件とMicrosoftに次ぐ数の脆弱性がKEV入りしており*41、2025年も引き続き注意が必要なベンダーと言えます。

    Mitel(通信機器メーカー)も昨年までKEV追加はごくわずかでしたが、2025年Q1には複数の脆弱性が一気に表面化しました。1月にはMitelの企業向けコラボレーション製品「MiCollab」の脆弱性が2件(認証不要のパストラバーサル[CVE-2024-41713]と管理者認証が必要なパストラバーサル[CVE-2024-55550])追加され*42、3月にはMitel製IP電話(SIP Phone)の管理インターフェースにおけるコマンドインジェクション脆弱性[CVE-2024-41710]も加わりました*43。Mitelのような中規模ベンダー製品でも攻撃対象になる事例が増えており、「自社には関係ない」と見落とさないよう注意が必要です。

    その他、VMware(仮想化ソフト)やFortinet(ファイアウォール)、Oracle(ミドルウェア)といったベンダーの脆弱性も複数登場しました。例えばFortinetのファイアウォールOSにおける認証バイパス欠陥*44や、Oracle WebLogic Serverの過去の未修正RCE(2020年にパッチは提供済みだが未適用サーバーが狙われた)*45がKEV入りしています。このように、上位はMicrosoftやAppleといった大手ですが、それ以外にも多彩なベンダーに攻撃が及んでいる点がQ1の特徴です。自組織で利用しているソフトウェアのベンダーがリストに含まれていれば要警戒ですし、たとえ主要ベンダー以外でも油断できません。

    自動化可能性 (Automatable) の分析

    興味深いことに、2025年Q1のKEV脆弱性の多くは「Automatable(攻撃自動化の容易性)= No」と評価されていました。これは「この脆弱性の悪用には何らかの手動操作や特別な条件が必要で、スクリプトによる大規模自動攻撃には向かない」という意味です*46。実際、Q1に追加された事例を見ると、攻撃者が悪用するにはユーザーの操作や物理アクセス、事前に認証情報を得ていること等が必要なケースが多く含まれていました。
    例えばAppleのiOS/iPadOSにおけるゼロデイ脆弱性(CVE-2025-24200)は「USB制限モード」を無効化するもので、攻撃にはターゲット端末への物理的なアクセスが必要でした*47。またMitelのIP電話機器の脆弱性(CVE-2024-41710)は管理者権限でログインできる攻撃者でなければ悪用できない設計でした*48。これらはインターネット越しに無差別スキャンで即座に攻撃できるタイプの脆弱性ではなく、限定的な条件下でのみ成立するものです。したがって攻撃の自動化は難しく、「Automatable = No」と判断されたのでしょう。

    この点は2024年の傾向と対照的です。昨年追加されたKEV脆弱性の多くは遠隔からスクリプトで容易に悪用可能なもので、「Automatable = Yes」が圧倒的多数を占めていました。たとえば2024年には認証不要のリモートコード実行や初期アクセスに使える脆弱性(OSコマンドインジェクション等)が多く含まれており、攻撃者はこれらをインターネット全体にスキャンをかけて自動的に侵入試行することができました*49。一方2025年Q1は、攻撃がより標的型(ターゲットを絞った手動攻撃)の様相を帯びているとも言えます。ただし注意すべきは、「Automatableでない」=安全という意味では決してないことです。たとえば前述のMitel MiCollabのケースでは、認証不要で自動悪用可能な脆弱性(CVSS 9.1)*50と認証必須で一見自動化が難しい脆弱性(CVSS 2.7)*51が組み合わさって使われました。後者単体では被害が限定的でも、前者で侵入した攻撃者が続けて後者を利用すれば権限あるユーザーになりすまし追加攻撃が可能になる、といった具合です*52。このように自動化が難しい脆弱性も、手動操作や他の欠陥との組み合わせで十分悪用され得るため、放置は禁物です。

    Technical Impact(技術的影響範囲)の傾向

    Technical Impactは「その脆弱性が与えるシステムへの影響範囲」の大きさを指し、CISAの基準では完全なシステム乗っ取りに至るものを“Total”(全面的影響)、情報漏えいや一部機能停止に留まるものを“Partial”(部分的影響)と分類しています*53。2025年Q1に追加された脆弱性のTechnical Impactをみると、“Total”が大半を占めていました。これは2024年通年の傾向とも一致しており、攻撃者が狙う脆弱性は基本的に「悪用すればシステムを完全制御できる」類のものが多いことを意味します。実際、Q1のKEVにはリモートコード実行(RCE)や認証回避による管理者権限奪取、任意コード実行といった致命的な影響をもたらす脆弱性が多数含まれました。例えばMicrosoft Hyper-Vのカーネル脆弱性は悪用によりホストOSを乗っ取れる(=Total)ものですし、FortinetやCiscoの認証バイパス欠陥も攻撃者にシステム完全制御を許します。

    一方で一部には“Partial”に分類される例も存在します。典型は情報漏えい型やサービス妨害型の脆弱性です。Q1では、例えばIvanti EPMのパストラバーサル脆弱性3件がSensitive情報の読み取りに利用できる(設定ファイル等の漏えい)ものでした*54。これらは直接コード実行はできないため影響範囲は限定的ですが、漏えいした情報(例えばパスワードハッシュ等)を足掛かりに別の攻撃を仕掛けられる可能性があります。また前述のMitelの例のように、一見Partialな脆弱性も他のTotalな脆弱性と組み合わせて利用され、結果的に全面的な被害に繋がるケースもあります*55。総じて、2025年Q1も“Total”な影響を与える脆弱性が主流ではありますが、Partialであっても油断はできません。影響範囲が限定的でもKEVに載るということは「現実に悪用された」ことを意味し、攻撃者にとって十分利用価値があるからです。

    CVSSスコア分布

    脆弱性の深刻度を表す指標として知られるCVSSスコア(基本値)について、2025年Q1のKEV追加分の分布を見てみましょう。CVSSでは一般にスコア7.0以上を“High”(高)、9.0以上を“Critical”(深刻)と分類します。Q1の73件を大まかに俯瞰すると、High帯(7.0–8.9)の脆弱性が相当数を占め、Critical帯(9.0以上)も一定数存在するといったバランスでした。つまり「深刻度がとても高いものばかり」ではなく、「高めだがCritical未満」の脆弱性も多数悪用されている状況です。

    実例を挙げると、Mitel MiCollabの2件の脆弱性はCVSSスコアが9.1(Critical)と2.7(Low相当)という極端な差がありながら、双方とも実際に攻撃に利用されています*56。Lowの方は「スコア2.7だから安全」では決してなく、前述のように他の脆弱性と組み合わされて攻撃チェーンの一部として悪用されました。加えて、2024年のKEV全体でも、CVSSスコアと実被害リスクが必ずしも比例しないことが指摘されています。たとえば2024年にKEV入りしたVersa社の脆弱性はCVSS7.2(High)の中程度スコアでしたが、実際にはISPやMSPに対する深刻なサプライチェーン攻撃に使われ得るものでした*57。このようにCVSSがCriticalでなくとも攻撃者にとって価値があれば悪用されること、逆にCriticalスコアでも条件付きでしか攻撃できないものもあることに留意が必要です。

    2024年通年と比べると、2025年Q1はCriticalの占める割合がやや低めだった可能性があります。2024年はLog4Shell(CVSS10.0)やProxyShell/ProxyLogon(9点台後半)など極めて高スコアの脆弱性が脚光を浴びましたが、2025年Q1はそれらに匹敵するような10.0満点のものは新規には見られませんでした(既存ではあるものの、新規追加分としてはなかった)。むしろCVSS7~8台の“High”クラスの脆弱性が広く悪用されていた印象です。これは、「攻撃者はCritical評価の脆弱性だけを狙うわけではない」ことの表れとも言えます。日々の運用ではどうしてもCVSSに目が行きがちですが、たとえCritical未満でもKEVに掲載された時点で放置すれば深刻なリスクとなるため、優先的に対策を講じるべきです。

    ランサムウェア悪用・APT攻撃の動き

    脆弱性が悪用される脅威として大きく分けると、金銭目的のランサムウェア攻撃と、スパイ活動やサイバー破壊を狙うAPT(国家・高度な持続的脅威)攻撃があります。2025年Q1のKEV脆弱性を見る限り、ランサムウェアによる悪用が判明している事例はごく少数でした。一方で、多くの脆弱性は国家主体のスパイ活動や高度な標的型攻撃(APT)での悪用、もしくはそれが強く疑われるケースが目立ちます。

    重要なのは、だからといってランサムウェア対策を後回しにしてよい訳ではないことです。脆弱性そのものにランサム攻撃の使用実績がなかったとしても、悪用方法が広まればサイバー犯罪集団が追随する可能性は十分にあります。またAPT攻撃経路として使われた脆弱性から情報を窃取され、その情報が二次被害として金銭目的に悪用されるリスクもあります。結局のところ、KEVに載るような脆弱性は攻撃者にとって価値が高いからこそ使われているのであり、それがAPT系かランサム系かを問わず、迅速な対応が必要である点に違いはありません。

    今後の展望と留意点

    (1). Q2以降で注視すべきCWE動向
    2025年Q1の時点で目立った脆弱性の種別(CWE)としては、OSコマンドインジェクション(CWE-78)やパストラバーサル(CWE-22)、不適切な認証(CWE-287)といったカテゴリが挙げられます*58。これらは2024年にも頻出した攻撃手法であり、引き続き「攻撃者が好む弱点」と言えるでしょう。特にコマンドインジェクションは遠隔から任意コード実行が可能になるため依然として人気が高く、Q2以降も各種ソフトウェアで類似の脆弱性が報告されれば迅速に悪用されるリスクがあります。同様に、パストラバーサルや認証回避の欠陥もVPN機器やWebアプリ等で報告が続くようなら注意が必要です。また、メモリ破壊系の脆弱性(Use-After-Freeやバッファオーバーフロー等)も依然無視できません。Q1にはMicrosoft Hyper-VやApple WebKitのゼロデイなどでメモリエラーに起因する脆弱性が悪用されました。これらは高度な攻撃者(APT等)がまず利用し、やがて犯罪集団にも手法が広まる傾向があるため、特にOSやブラウザ、主要ソフトのメモリ安全性に関する脆弱性情報には今後もアンテナを張っておくべきです。

    (2). 年間登録件数のペース
    すでに述べた通り、Q1の時点で昨年までの年間半分近い73件がKEV追加されています。このペースが維持・加速すれば年間200件を大幅に超える見込みで、仮に上振れすれば300件近くに達する可能性も否定できません*59。もっとも、Q2以降に減速する可能性もありますが、現状では少なくとも前年以上のハイペースであることは確かです。したがって組織としては「今年は昨年までよりも多くの緊急脆弱性が飛び出すかもしれない」という前提で計画を立てることが重要です。具体的には、増加する脆弱性通報に対応できるよう社内体制やプロセスの見直しを検討しましょう(後述の対策参照)。

    (3). 自組織での脆弱性管理に向けたポイント
    最後に、増え続けるKEVへの実践的な備えについて整理します。まず基本は、KEVカタログを自社の優先パッチ適用リストに組み込むことです。KEV掲載項目は、その脆弱性が未修正のままだと「深刻なリスクにさらされている」状態と言えます*60。自社で使っているシステムについてKEV該当の脆弱性がないか定期的にチェックし、該当があれば最優先でアップデートや緩和策適用を行う体制を整えましょう。可能であれば脆弱性管理ツールやスクリプトを用いて、KEVリストとの突合による影響調査を自動化すると効率的です。また、パッチ適用がすぐにできない事情がある場合でも、ベンダー提供の緩和策(設定変更や一時的無効化措置など)を講じる、該当システムへのアクセス経路を制限する(ネットワーク分離やWAF導入)など、被害を防ぐ工夫を行いましょう。

    加えて、脆弱性悪用の「検知」と「インシデント対応」も強化が必要です。既知悪用脆弱性は攻撃者が実際に使っているため、侵入の痕跡(IoC)がセキュリティベンダー等から提供されている場合があります。シグネチャベースの侵入検知システム(IDS)やエンドポイント検知(EDR)のルールを最新化し、該当する脆弱性攻撃の兆候を見逃さないようにしましょう。例えばCISAは悪用されたIvanti脆弱性に関してマルウェア解析レポートを公表し、YARAルールやSnortシグネチャを提示しています*61。こうした公開情報を活用し、もし自組織が既に攻撃を受けていないか(脆弱性が悪用された痕跡がないか)もチェックすることが望まれます。

    最後に、サプライチェーンや他社製品のリスクにも目配りしましょう。自社で使っていないソフトの脆弱性であっても、取引先や委託先のシステムが影響を受ければ、自社への間接的な被害につながる可能性があります*62。KEVカタログに重要取引先の製品が載った場合などは、その企業と連携して対策状況を確認するなど、協力体制を築くこともセキュリティリスク低減に有効です。

    まとめ

    2025年上半期(Q1時点)を振り返ると、脆弱性攻撃の脅威は昨年以上に増大し、多様化していることが分かります。攻撃者は依然としてシステム乗っ取り可能な深刻な欠陥(Technical Impactが“Total”のもの)を好んで悪用していますが、そのアプローチは巧妙化し、自動スキャンで一斉攻撃できないようなゼロデイも含め標的に応じて使い分けています。ランサムウェアなど金銭目的の攻撃だけでなく、国家絡みのスパイ攻撃でも新たな脆弱性が次々と悪用されました。

    こうした状況下で実務担当者が取るべき具体的アクションは、何より既知悪用脆弱性への迅速な対応です。KEVカタログは「サイバー攻撃者が現に使っている脆弱性」のリストであり、これを活用すればパッチ適用や緩和策の優先順位付けを的確に行えます。ぜひ社内の脆弱性管理プロセスにKEVチェックを組み込み、定期的に最新脆弱性情報をモニタしてください。また、開発部門にとってもKEVの傾向は示唆的です。どのような弱点(CWE)が現実に攻撃されやすいのか把握することで、ソフトウェア開発時のセキュリティ設計やテストにフィードバックできます。たとえば入力検証の不足(コマンドインジェクション)や認証周りの不備がどれほど危険か、KEV事例は警鐘を鳴らしています。

    最後に経営層の方々へ強調したいのは、脆弱性対策への投資は喫緊かつ最善のリスクヘッジであるという点です。2025年は脆弱性攻撃のペースがさらに加速する可能性があり、待ったなしの状況です。幸いKEVカタログをはじめ有益な情報源やツールも整いつつあります。これらをフル活用し、組織横断で脆弱性管理に取り組むことで、サイバー攻撃による甚大な被害を未然に防ぐことができるでしょう。「脅威のいま」を正しく把握し、迅速かつ着実な対策を講じて、2025年後半以降の更なる脅威にも備えていきましょう。

    【参考情報】

  • Known Exploited Vulnerabilities Catalog (CISA), wilderssecurity.com
  • CISA Alerts and VulnCheck Reports, channele2e/comvulncheck.com
  • Binding Operational Directive 22-01, cisa.gov
  • Security NEWS TOPに戻る
    バックナンバー TOPに戻る

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

  • 2025年6月4日(水)13:00~14:00
    知っておきたいIPA『情報セキュリティ10大脅威 2025』~セキュリティ診断による予防的コントロール~
  • 2025年6月11日(水)13:50~15:00
    DDoS攻撃から守る!大規模イベント時のセキュリティ-大規模イベント開催中に急増するDDoS攻撃の事例と防御策を解説-
  • 2025年6月18日(水)14:00~15:00
    侵入が防げない時代に選ぶべき脆弱性診断サービスとは?~実績・サポート・診断基準で比較する、最適な脆弱性診断の選び方~
  • 最新情報はこちら


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

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


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    CVEとは?共通脆弱性識別子の基本と管理方法を徹底解説

    Share

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

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。


    はじめに

    情報セキュリティにおいて“CVE”は必ずといっていいほど登場するキーワードです。本記事では「CVEとはなにか?」という基本的な疑問に答えながら、脆弱性管理の観点で知っておきたいCVE番号の仕組みや運用方法を解説します。

    CVEの概要

    • CVE(Common Vulnerabilities and Exposures) は、ソフトウェアやハードウェアの脆弱性に一意の識別番号を付与する仕組みです。
    • 米国政府支援のMITRE社が運営し、世界中のセキュリティ関係者が共通の脆弱性情報を参照できます。 (CVE – Mitre, Common Vulnerabilities and Exposures)
    • 目的:脆弱性情報の共有とトラッキングを標準化し、誤解や情報の断絶を防ぐこと。

    CVE識別子の構造

    CVE番号は以下のような形式を取ります。

    例:CVE-2025-22457

    項目 説明
    プレフィックス CVE 一意の脆弱性識別子の接頭辞
    発行年 2025 脆弱性が登録された西暦年
    識別番号 22457 当該年に発行された通し番号

    CVEの仕組みと運用フロー

    1. 発見・報告
      セキュリティリサーチャーやベンダーが脆弱性を発見し、MITREに報告
    2. 分析・番号割当
      MITREが報告内容を審査し、CVE番号を割り当て
    3. 公表・共有
      NVD(National Vulnerability Database)や各国CERTなどで情報公開
      (Vulnerabilities – NVD – National Institute of Standards and Technology)
    4. 対応策検討
      ベンダーは修正プログラム(パッチ)を開発・公開
    5. 適用・監視
      利用者はCVE番号を基にリスク評価し、パッチ適用や対策を実施

    CVE情報の取得方法

    CVEを活用した脆弱性管理

    1. 脆弱性スキャンとの連携
      スキャンツールが検出した脆弱性にCVE番号を紐付け、一覧化
    2. 優先順位付け(プライオリティ設定)
      CVSSスコア(Common Vulnerability Scoring System)や影響範囲から対応の緊急度を判断 (Common Vulnerability Scoring System SIG)
    3. パッチ管理プロセス
      定期的にCVEリストを更新し、パッチ適用状況を追跡
    4. 報告・監査
      CVE番号を用いたレポートでセキュリティ監査に対応

    よくある質問(FAQ)

    Q1. CVEとCWEの違いは?

    • CVE:脆弱性そのものを識別する番号
    • CWE:脆弱性の種類や原因を分類する共通項目(例:CWE-79=クロスサイトスクリプティング) (Common Weakness Enumeration: CWE – Mitre)

    Q2. CVE番号はどこで確認できる?

    Q3. CVE情報の更新頻度は?

    • NVDは原則毎日更新
    • 各ベンダーは脆弱性発見後数日〜数週間でアドバイザリ公開

    まとめ

    CVEは、全世界で共通の脆弱性識別子として脆弱性管理の基盤を支えています。番号の仕組みや運用フローを理解し、定期的に情報を取得・対応することで、自社システムのセキュリティを大幅に向上させることが可能です。まずはNVDやJPCERT/CCを定期チェックし、CVE番号による脆弱性トラッキングを始めましょう。

    【参考情報】

    以上の参考情報を活用し、CVEを軸とした脆弱性管理を強化していきましょう。

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

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

  • 2025年5月21日(水)14:00~15:00
    Webサイト改ざん攻撃の手口と防御策とは?リアルタイム検知で守るセキュリティ
  • 2025年5月28日(水)13:00~14:00
    脆弱性診断の新提案!スピード診断と短納期で解決する「SQAT® with Swift Delivery」セミナー
  • 2025年6月4日(水)13:00~14:00
    知っておきたいIPA『情報セキュリティ10大脅威 2025』~セキュリティ診断による予防的コントロール~
  • 最新情報はこちら


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

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


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    2025年春のAI最新動向第3回:
    生成AIの未来と安全な活用法 -私たちはAIをどう使うべきか?-

    Share

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

    本記事では全3回のシリーズを通して、2025年春時点でのAIをめぐる様々な事象をまとめています。連載第3回目となる今回は、生成AIを私たちはどのように活用すべきか、今後の展望について解説します。

    OWASP Top 10でみる生成AIのセキュリティリスク

    AIをめぐるセキュリティリスクを簡便にまとめた情報がOWASP Top 10 for LLM Applications 2025として公開されています。2024年11月に公開された2025年版では、以下の10項目がトップ10に挙げられています。

    • LLM01:2025 プロンプトインジェクション
      概要:ユーザーが入力したプロンプトが、意図しない形で LLM の挙動や出力に影響を与える脆弱性
    • LLM02:2025 センシティブ情報漏洩
      概要:LLMとそのアプリケーションのコンテキストにおいて、個人情報、金融情報、機密ビジネスデータ、セキュリティ認証情報などのセンシティブな情報が漏洩するリスク
    • LLM03:2025 サプライチェーン
      概要:LLMのサプライチェーンにおける脆弱性が、トレーニングデータ、モデル、デプロイメントプラットフォームの完全性に影響を与え、バイアスのある出力やセキュリティ侵害を引き起こすリスク
    • LLM04: データとモデルの汚染
      概要:事前学習、ファインチューニング、または埋め込みデータが操作され、脆弱性、バックドア、またはバイアスが導入されることによって、モデルのセキュリティ、パフォーマンス、または倫理的行動が損なわれるリスク
    • LLM05:2025 不適切な出力処理
      概要:LLMによって生成されたコンテンツの検証、サニタイズ、および処理が不十分なまま、他のコンポーネントやシステムに渡されることによって生じる脆弱性
    • LLM06:2025 過剰な代理権
      概要:LLMベースのシステムが、プロンプトに応答してアクションを実行するために、他のシステムと連携する機能を与えられることによるリスク
    • LLM07:2025 システムプロンプトリーク
      概要:LLMアプリケーションのシステムプロンプトが漏洩することにより、攻撃者がアプリケーションの内部動作を理解し、悪用するリスク
    • LLM08:2025 過度な信頼
      概要:LLMの出力の正確さや適切さに対する過度な依存によって生じるリスク。ユーザーがLLMの出力を効果的に評価できない場合、誤情報や不適切なアドバイスを受け入れる可能性が高まる
    • LLM09:2025 誤情報の生成
      概要:LLMが誤った情報や偏った情報を生成・拡散するリスク
    • LLM10:2025 無制限の消費
      概要:LLMが入力クエリまたはプロンプトに基づいて出力を生成するプロセスにおいて、リソース管理が不適切であることによって生じるリスク。モデルの窃取やシャドウモデルの作成につながる可能性もある

    Top10には実際にジェイルブレイクの手法として用いられるものも含まれています。また、AIによるサービスを提供する側がガードレールによって回避すべき問題も多く含みますが、LLM08:2025 過度な信頼のようにユーザ側の問題も含まれています。

    生成AIの利用用途 -私たちはAIをどう使うべきか?-

    生成AIサービスであり基盤モデルでもある「Claude」を提供するAnthropic社が、2025年2月10日、「The Anthropic Economic Index」という分析レポートを公開しました。同レポートでは、Claudeの利用データ(匿名データ)を用いて私たちが普段どのようにAIを使っているかを具体的に分析しています。

    生成AIの主な利用用途

    • ソフトウェア開発とテクニカルライティングが主要な利用用途
    • 生成AIが人間の能力と協力して強化・拡張(Augumentation)する目的で使用されることが57%を占めており、AI が直接タスクを実行する自動化(Automation, 43%)を上回っている
    • 生成AIの使用はコンピュータープログラマーやデータサイエンティストなどの中~高程度の賃金を得られる職業※ で一般的
      ※Claudeのユーザーの利用用途をタスク別に割り当て、そのタスクが実行される可能性が高い職業を割り当てている点に注意
    • 最高賃金帯と最低賃金帯のタスクで利用頻度が低い

    ここまで書いてきましたが、生成 AI・基盤モデル(LLM含む)をめぐっては2025年3月現在、以下のような問題があります。

    • 過度な信頼や誤情報に対する警戒(OWASP Top 10 for LLM Applications 2025やEU AI法)
    • 機微情報や著作物の取り扱いに関するルール作り(日本をはじめとする各国法制度)

    機微情報や著作物に影響されない分野としてソフトウェア開発やテクニカルライティングがあり、その中でもある程度誤情報の検知や生成AIの出力に対して過度に期待しない一定程度の経験のある層が生成AIを使いやすいという状況の結果として、現時点での利用方法があると考えられるかもしれません。

    AIの安全な利用に向けて

    機微情報や著作物の扱いに関する問題やジェイルブレイクによる危険な情報の出力、誤情報といった具体的な問題がある一方、生成AIに限らずAI全般において安全性をどう保証するのか、インシデントをどのように調査し報告するのかといった面については現在も議論が続いています。EUでAI法は施行されてはいるものの、実際の法規制はこれからとなります。容認できないリスクに当たるAIへの規制はすでに2025年2月2日から始まっていますが、そのほかのAIシステムについてはこれから規則が適用されることになっています。EUのAI法のアプローチによる安全性の保証がどう効果をもたらすかは1年以上を経ないとわからないのが実情です。また、2025年2月4日に内閣府のAI戦略会議から公開された「中間とりまとめ(案)」でも、安全性については制度・施策の中で透明性・適正性の確保と並んで課題として挙げられています。

    まとめ

    2025年春、生成AIは急速に進化し、私たちの日常やビジネスに大きな影響を与えています。しかし、その一方でジェイルブレイク、情報漏洩、誤情報生成など、数多くのセキュリティリスクも指摘されています。各国の政府や監督機関は、これらのリスクに対応するための法規制やガイドラインを整備しつつあり、利用者としても安全対策の強化が求められています。今後、生成AIを安全に活用するためには、最新の規制情報やガイドラインに基づいた対策を実施し、脆弱性診断などを通じてシステムの弱点を常に把握することが必要です。SQAT.jpでは、今後も生成AIの安全性に関する問題に注視し、ご紹介していきたいと思います。

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

    【連載一覧】

    ―第1回「生成AIとは? -生成AIの基礎知識と最新動向-」―
    ―第2回「生成AIをめぐる政府機関および世界各国の対応」―


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

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


    Security Serviceへのリンクバナー画像

    BBsecコーポレートサイトへのリンクバナー画像

    セキュリティ緊急対応のバナー画像

    2025年サポート終了製品リスト付!サポートが終了したソフトウェアを使い続けるリスクとその対策

    Share

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

    現代のビジネス環境では、ソフトウェアやシステムのセキュリティ対策が極めて重要です。しかし、多くの企業や個人が気づかぬうちに、サポートが終了したソフトウェアを使い続けることで、深刻なサイバーセキュリティのリスクにさらされています。本記事では、サポート終了製品を利用し続けることの危険性と、その対策について詳しく解説します。

    お問い合わせ

    お問い合わせはこちらからお願いします。後ほど、担当者よりご連絡いたします。


    サポートが終了したソフトウェアとは?

    ソフトウェアベンダーは、一定の期間ソフトウェアのアップデートやセキュリティパッチを提供します。しかし、開発の継続が難しくなると、メーカーはその製品のサポートを終了し、新しいバージョンへの移行を促します。例えば、Windows 10は2025年10月にサポート終了が予定されており、企業や個人ユーザーは今後の対応を迫られています。

    表.2025年中にEOLとなる製品

    サポート終了後のソフトウェアは、新たな脆弱性が発見されても修正されず、そのまま放置されることになります。このため、サイバー攻撃の標的となるリスクが非常に高くなります。

    サポートが終了したソフトウェアを使い続けるリスク

    1. セキュリティの脆弱性が修正されない
      サポートが終了したソフトウェアには、新たに発見された脆弱性に対するセキュリティパッチが提供されません。そのため、ハッカーにとって格好の標的となり、マルウェア感染や不正アクセスのリスクが高まります。
    2. ランサムウェアやマルウェア攻撃の増加
      近年、サポート終了ソフトウェアを狙ったランサムウェア攻撃が増加しています。例えばWindows XPのサポート終了後、「WannaCry」というランサムウェアが流行し、多くの企業が被害を受けました。これと同様の攻撃が、サポート終了後のWindows 10やその他の古いソフトウェアでも発生する可能性があります。
    3. 法規制やコンプライアンス違反
      企業がサポート終了ソフトウェアを使い続けることは、法的リスクを伴います。特にGDPR(EU一般データ保護規則)や日本の個人情報保護法では、適切なセキュリティ対策を講じることが求められています。サポートが終了したソフトウェアを利用することは、これらの規制違反となる可能性があり、企業の信頼性が損なわれる要因となります。
    4. ソフトウェアの互換性問題
      古いソフトウェアを使い続けると、最新のアプリケーションやハードウェアとの互換性が失われる可能性があります。例えば、最新のクラウドサービスが利用できなかったり、新しいデバイスとの接続ができなかったりすることで、業務の効率が低下します。
    5. ITコストの増加
      一見すると、古いソフトウェアを使い続けることはコスト削減につながるように思えますが、実際にはその逆です。セキュリティの問題が発生すれば、データ漏えいやシステム停止による損害が発生し、結果的に大きなコストがかかる可能性があります。

    サポート終了ソフトウェアへの対応策

    1. 速やかなアップグレード
      最も安全な対策は、最新のソフトウェアへアップグレードすることです。例えば、Windows 10のサポート終了が迫っているため、企業や個人はWindows 11への移行を検討することが推奨されます。
    2. 仮想環境での隔離
      どうしてもサポートが終了したソフトウェアを使い続ける必要がある場合は、**仮想マシン(VM)**を利用し、ネットワークから切り離して運用する方法もあります。これにより、セキュリティリスクを最小限に抑えることが可能です。
    3. セキュリティ対策の強化
      古いソフトウェアを使用する場合、ファイアウォールの強化や最新のエンドポイントセキュリティを導入することで、攻撃のリスクを軽減できます。また、多要素認証(MFA)を導入することで、不正アクセスのリスクを低減できます。
    4. 定期的な脆弱性診断
      企業では、定期的な脆弱性診断を実施し、セキュリティの問題を早期に発見することが不可欠です。セキュリティ専門家による診断を受けることで、サイバー攻撃のリスクを軽減できます。
    5. クラウドサービスへの移行
      古いソフトウェアの代替として、クラウドベースのサービスを活用する方法もあります。例えば、Microsoft 365やGoogle Workspaceといったクラウドサービスに移行することで、常に最新のセキュリティアップデートを受けられます。

    サポート終了後に脆弱性が公表された事例と考察

    【事例1】

    サポート終了となったCisco社のVPNルータ「RV016、RV042、RV042G、RV082、RV320、RV325」は、緊急の脆弱性(CVE-2023-20025等)により任意のコマンド実行される脆弱性を公表したが更新ファームウェアを提供しないことを表明した。

    【事例2】

    GeoVision社のいくつかの機器はサポート終了となっており、緊急の脆弱性(CVE-2024-11120)により認証不要のOSコマンドインジェクションがあり、攻撃者による悪用も確認されているが修正パッチ等はない。

    上記のように、EOL後に危険な脆弱性が発見された場合でも、公式の対応はなく危険な状態が続きます。また、代替製品への移行など、アップデートだけでは解決しない修正を行う際、迅速に対応できないケースが起こりうることにも注意が必要です。

    まとめ

    サポートが終了したソフトウェアを使い続けることは、重大なセキュリティリスクを伴うだけでなく、企業の信頼性や業務効率にも影響を及ぼします。特に、サイバー攻撃の標的になりやすく、ランサムウェア被害やデータ漏えいのリスクが高まります。安全なIT環境を維持するためには、定期的なアップグレードや適切なセキュリティ対策を講じることが不可欠です。サポート終了前に適切な対応を行い、安心して業務を継続できる環境を整えましょう。


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

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

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

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

  • 2025年2月26日(水)13:00~14:00
    AWS/Azure/GCPユーザー必見!企業が直面するクラウドセキュリティリスク
  • 2025年3月5日(水)13:00~14:00
    ランサムウェア対策の要!ペネトレーションテストとは?-ペネトレーションテストの効果、脆弱性診断との違い-
  • 2025年3月12日(水)14:00~15:00
    サイバー攻撃に備えるために定期的な脆弱性診断の実施を!-ツール診断と手動診断の比較-
  • 最新情報はこちら


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

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

    APIとは何か(3)
    ~APIセキュリティのベストプラクティス~

    Share

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

    APIセキュリティは、適切な認証と認可が鍵です。本記事では、APIのセキュリティを強化するための基本的な対策からベストプラクティスまで解説します。脅威に対抗するための対策案を紹介し、セキュアなAPI運用のポイントを提供します。

    前回記事はこちら。
    シリーズ第1回目「APIとは何か(1)~基本概念とセキュリティの重要性~
    シリーズ第2回目「APIとは何か(2)~APIの脅威とリスク~

    認証と認可の重要性

    ソフトウェアセキュリティにおける問題の多くは、信頼境界をまたぐデータ(プログラム内の入出力)やモノ(フレームワーク)に起因しています。様々な場所から様々なデバイスによりアクセスされる昨今の環境下では、既存の認証を信用せず、あらゆるアクセスを信用しないという前提に立った上で動的なアクセスコントロールによって認可する「ゼロトラスト」の考え方が必要です。ポイントは、「認証」と「認可」の違いを的確に理解することです。「認証」と「認可」が適切に区別されていないシステムの場合、本人確認を行うユーザ認証さえ突破してしまえば、システムのどこにでも自由にアクセス可能となってしまい、非常に危険です。

    「認証」と「認可」を明確に区別して信頼境界の安全を保つことが重要であり、その実現にあたっては、厳格なセッション管理が鍵となります。代表例として、ソフトウェアにおけるアクセス認可において、アクセストークンによる堅牢な制御の上で、信頼境界ごとのリソースに認可プロセスを設定するといった方法が挙げられます。

    基本的なセキュリティ対策

    セキュリティ対策の取り組みには、基本的なセキュリティ対策こそが効果的であるという前提に立って、今一度自組織のセキュリティを見直すことが重要です。

    セキュリティ基本10項目

    標的型攻撃メール訓練の実施

    標的型攻撃メール訓練は、従業員のセキュリティ意識向上と実践的なスキル習得に効果的です。訓練では、攻撃メールを模倣したシナリオを用いて、従業員が疑わしいメールを識別し、適切に対応するスキルを養います。定期的な訓練実施により、従業員のセキュリティ意識が継続的に高まり、実際の攻撃に対する組織の耐性が強化されます。また、訓練後のフィードバックやセキュリティ教育との組み合わせにより、より効果的な対策が可能になります。

    定期的なバックアップの実施と安全な保管(別場所での保管推奨)

    ランサムウェアによる被害からデータを保護するために、サーバに対してオフラインバックアップ(データだけを独立して磁気テープ・ストレートなどで物理的に隔離しておくこと)を行うことがおすすめです。バックアップの頻度や保管場所を見直し、最新の情報が常に保存されるようにすることが重要です。

    バックアップ等から復旧可能であることの定期的な確認

    バックアップが確実に復旧可能であることを確認するため、定期的にリカバリーテストを実施します。これにより、実際の復旧作業時に問題が発生しないことを保証し、緊急時に迅速かつ確実なデータ復旧が可能となります。また、テスト結果を文書化し、必要に応じて復旧手順の改善を図ります。このような確認作業を怠ると、いざという時にデータ復旧が困難になるリスクが高まります。

    OS、各種コンポーネントのバージョン管理、パッチ適用

    システムの脆弱性を悪用する攻撃を防ぐためには、OSやソフトウェアコンポーネントの最新バージョンへの更新・パッチ適用の実施をすることが必要不可欠です。定期的なパッチ適用とバージョン管理により、サイバー攻撃のリスクを大幅に軽減できます。特にゼロデイ攻撃のリスクを軽減するためには、普段から脆弱性関連の情報収集やバージョン更新が求められます。

    認証機構の強化(14文字以上といった長いパスフレーズの強制や、適切な多要素認証の導入など)

    認証の強化は、サイバー攻撃から組織を守るための基本的な対策です。単純なパスワードではなく、長く複雑なパスワードにし、さらに多要素認証(MFA)を導入することを推奨します。多要素認証はパスワードに加え、物理トークンや生体認証などの認証要素を用いることで、不正アクセスされるリスクを低減します。これにより、アカウントのセキュリティが飛躍的に向上します。

    適切なアクセス制御および監視、ログの取得・分析

    システム内の情報やリソースへのアクセスを厳格に管理し、適切なアクセス制御を行うことは、内部からの不正行為を防ぐために重要です。また、システムの稼働状況やアクセスログを定期的に取得し分析することで、異常な挙動を早期に検知できます。

    シャドーIT(管理者が許可しない端末やソフトウェア)の有無の確認

    シャドーITは、組織のセキュリティポリシーに反する可能性があり、脆弱性やデータ漏洩の原因となることがあります。定期的な監査や従業員への教育を通じて、シャドーITの存在を確認し、適切な対策を講じることが重要です。

    攻撃を受けた場合に想定される影響範囲の把握

    サイバー攻撃を受けた際に、どのような影響が組織に及ぶかを事前に把握しておくことは重要です。影響範囲を明確にすることで、インシデント発生時の対応計画を具体化し、迅速な対策を講じることが可能になります。システム全体の依存関係や業務の優先度を考慮し、被害を最小限に抑えましょう。

    システムのセキュリティ状態、および実装済みセキュリティ対策の有効性の確認

    定期的にシステムのセキュリティ状態を確認し、現在のセキュリティ対策が有効に機能しているかを確認することが効果的です。脆弱性診断やペネトレーションテストを実施することで、システムの弱点を特定し、自組織の状況に適した対応の実施が可能になります。

    CSIRTの整備(全社的なインシデントレスポンス体制の構築と維持)

    CSIRT(Computer Security Incident Response Team)は、サイバー攻撃やインシデント発生時に迅速かつ適切な対応を行うための専門チームです。CSIRTの整備は、全社的なセキュリティ体制を強化し、インシデント発生時の被害を最小限に抑えるために不可欠です。定期的な訓練とシミュレーションを通じて、CSIRTの対応力を維持し、常に最新の脅威に対応できる体制を整えます。

    APIセキュリティのベストプラクティス

    OAuthトークン

    OAuthトークンは、APIへのアクセスを安全に制御するための認可手段です。ユーザのパスワードを直接共有せず、一時的なトークンでアクセスを許可する仕組みにより、不正アクセスのリスクを軽減します。

    暗号化と署名

    API通信では、暗号化が重要です。また、署名による送信者の認証をすることも重要です。SSL/TLS(TLS 1.3推奨)での暗号化により、データが送受信される途中で盗聴されないようにします。署名には一般的にRSA暗号やECDSAなどのアルゴリズムが使用され、SHA-256などのハッシュ関数と組み合わせてデータの完全性を保証します。デジタル証明書を使用することで、通信相手の身元確認も可能になり、より強固なセキュリティを実現できます。

    レート制限とスロットリング

    レート制限とスロットリングは、APIへのリクエスト数を一定範囲に抑え、サーバへの負荷を管理するための手法です。過剰なリクエストをブロックし、DDoS攻撃などのリスクを軽減します。また、正規ユーザの快適な利用を維持し、サービスの安定稼働を支えます。

    APIゲートウェイの使用

    APIゲートウェイは、API管理を一元化するためのツールです。認証、認可、レート制限、監視など、APIに関連するセキュリティ機能を提供します。これにより、システム全体のAPI運用を最適化します。APIの脆弱性を効果的に軽減することができます。また、監視とログ収集を行うことで、問題発生時の迅速な対応が可能になります。

    APIのセキュリティ対策

    ここまで見てきたAPIセキュリティ脅威を踏まえると、以下のようなポイントにおいて脆弱でないことが重要と考えられます。

    APIのセキュリティ対策のポイント図

    開発中、リリース後、更新時といった、いかなる状況においても、適切な脆弱性管理・対応ができているかどうかが、鍵となります。

    APIのセキュリティ対策の概要図

    APIの開発にあたっては、DevSecOpsを適用して脆弱性を作り込まないようにすること、APIリリース後も、新たな脆弱性が生まれていないか、APIセキュリティ診断などを通じて確認を継続することが重要です。

    APIはスマホアプリでも多く活用されています。誰もがスマートフォンを利用している今、攻撃の被害が多くの人々に影響を及ぼす可能性があるからこそ、スマホアプリにおいて次の攻撃につながる情報が漏洩したり、スマホアプリの改竄が行われたりする可能性を摘んでおくことが、スマホアプリを提供するうえで重要となります。スマホアプリのセキュリティ対策の一つとしては、信頼できる第三者機関による脆弱性診断の実施があげられます。第三者の専門家からの診断を受けることで、網羅的な確認ができるため、早急に効率よく対策を実施するのに役立つでしょう。

    関連記事:

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

      APIのセキュリティについて、認証と認可は基本となる重要な要素です。現代では従来の境界型セキュリティでは不十分となり、あらゆるアクセスを疑う「ゼロトラスト」モデルが求められています。認証は「誰か」を確認するプロセス、認可は「何を許可するか」を決める仕組みであり、両者の違いを明確に理解しておくことが重要です。

      組織の安全を守るには、基本的なセキュリティ対策の実施が不可欠です。具体的には、攻撃メール訓練の実施、バックアップ管理、システムの更新、強固な認証の導入、アクセス制御とログ分析などが推奨されます。また、インシデント対応チーム(CSIRT)の整備により、問題発生時の迅速な対応が可能となります。

      APIセキュリティの観点からは、OAuthトークンの導入、通信の暗号化と署名、レート制限やスロットリングでの制限、APIゲートウェイが推奨されます。開発段階からリリース・運用後まで脆弱性管理を徹底し、特にユーザへの影響が大きいと考えられるサービスでは第三者機関によるセキュリティ診断も活用することをおすすめします。

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


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

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


      Security Serviceへのリンクバナー画像

      BBsecコーポレートサイトへのリンクバナー画像

      セキュリティ緊急対応のバナー画像