セキュリティの脆弱性とは｜原因と被害、個人と小規模チームの対策手順

2026年1月15日

＠SOHO編集部

この記事のポイント

✓セキュリティ脆弱性とは何かを
✓バグとの違いから丁寧に整理します
✓突かれたときに起きる被害

「セキュリティ脆弱性」と検索してこのページに来た方の多くは、取引先から送られてきた診断結果の読み方が分からない、あるいは自分が運用しているサイトに「脆弱性があります」という通知が届いて青ざめている、そんな状況ではないかと思います。脆弱性という言葉はニュースでは毎週のように流れるのに、いざ自分の問題になると「何が悪いのか」「どこまでやれば済むのか」の輪郭がつかめません。この記事では、脆弱性の正体を定義から整理し、原因、実際に起きる被害、情報の集め方、そして手を動かす順番までを通しでまとめます。専門部署を持たない個人事業主や数人のチームでも、読み終えたその日に最初の1手を打てる状態を目標にしています。

セキュリティの脆弱性とは何か、バグとの違いから整理する

セキュリティの脆弱性とは、ソフトウェアやハードウェア、設定、運用の手順に含まれている「攻撃に悪用できる弱点」のことです。英語ではvulnerabilityと呼び、日本語では「セキュリティホール」という言い方もほぼ同じ意味で使われます。ポイントは、脆弱性が単独では事故を起こさないという性質にあります。鍵のかかっていない窓のようなもので、窓が開いているだけでは何も起きませんが、そこに侵入者が来ると被害になります。だから脆弱性の議論は必ず「弱点」と「それを突く攻撃」の2つをセットで考えます。

よく混同されるのがバグとの違いです。バグは仕様どおりに動かない不具合の総称で、ボタンを押しても保存されない、表示が崩れる、といった見た目に分かるものも含みます。脆弱性はそのバグのうち、第三者が悪用すると本来できないことができてしまう一部分を指します。つまり脆弱性はバグの部分集合です。ただし全部がバグ由来ではないという点も押さえておく必要があります。プログラムとしては正しく動いていても、管理画面が初期パスワードのまま公開されている、権限設定が緩すぎて誰でも顧客一覧を開ける、といった設定や運用の問題も脆弱性に数えます。むしろ小規模な事業者で実害につながるのは、この設定と運用の側が圧倒的に多いのが実感です。

もう1つ理解しておきたいのが、脆弱性は「なくす」ものではなく「管理する」ものだという発想です。ソフトウェアは人が書くので、書けば必ずどこかに弱点が残ります。世界中の研究者と攻撃者が日々新しい弱点を見つけ続けているので、今日安全だったコードが来週には危険になります。だから目標は「脆弱性ゼロ」ではなく、「見つかった脆弱性を、悪用される前に塞ぐ速度を保つこと」になります。この発想の転換ができると、対策の優先順位が自然に決まっていきます。全部を完璧にする予算はないが、危険なものから順に塞ぐ仕組みは小さくても作れる、という話に落ちるからです。

脆弱性を語るときによく出てくる3つの言葉も、ここで整理しておきます。1つめは脅威で、攻撃者やマルウェアといった「弱点を突いてくる側」を指します。2つめはリスクで、脆弱性と脅威が組み合わさったときに発生する損害の見込みです。3つめが対策で、弱点を塞ぐか、脅威が届かないようにするか、被害を小さくするかのいずれかを打ちます。診断報告書やセキュリティベンダーの提案書はこの3語で構成されていることが多く、どの語について話しているかを見分けられるだけで、書類の読みやすさが変わります。

脆弱性が生まれる4つの原因

脆弱性がどこから生まれるのかを知ると、自分の環境で疑うべき場所が絞れます。原因は大きく4つに分けられます。

1つめはプログラムの実装ミスです。入力された文字列をそのままデータベースへの命令に混ぜてしまうSQLインジェクション、利用者のブラウザで意図しないスクリプトが動いてしまうクロスサイトスクリプティング、ファイルのパスを外部から操作されてしまうディレクトリトラバーサル、いずれも「外から来た値を信用してしまった」ことが共通の根っこです。自社でシステムを開発している場合はここが主戦場になります。逆に、既製のCMSやSaaSを使っているだけなら、自分でこの種類を作り込むことはほとんどありません。

2つめは更新の放置です。使っているOS、ミドルウェア、CMS、プラグイン、ライブラリのどれかに脆弱性が公表され、修正版も出ているのに当てていない状態です。攻撃者から見ると、これがいちばん効率のよい入口になります。なぜなら公表情報に「どこが弱いか」が書いてあり、攻撃コードも流通しているからです。実装ミスを自力で探すより、パッチを当てていないサーバーを機械的に探すほうが早い。世の中で起きている侵入事故の相当な割合が、この既知の脆弱性の放置から始まっています。

3つめは設定の不備です。管理画面をインターネット全体に公開している、クラウドストレージのアクセス権を「全員が読める」にしたまま本番データを置いている、テスト用のアカウントを消していない、デバッグ表示が本番で有効になっていてエラーメッセージに内部構造が出ている、といったものです。コードは1行も間違っていないのに穴が空くので、開発者だけに任せていると抜けます。

4つめは人と運用です。パスワードの使い回し、フィッシングメールに書かれたリンクからの認証情報の入力、退職者のアカウントの残置、業務端末への私物アプリの導入。技術的には正しく作られていても、認証情報が渡ってしまえば正規の利用者として入ってこられます。社員教育の効果については、模擬的なフィッシングメールを送って開封と入力の傾向を測る訓練の考え方をまとめた社員のセキュリティ意識を向上させるフィッシングメール模擬訓練の効果｜2026年最新の従業員教育ガイドが参考になります。訓練は「引っかかった人を責める」ためではなく、どの文面に弱いかを把握して手順を変えるために実施するものだという整理が書かれています。

私が実務でいちばんヒヤリとしたのは、2つめの更新放置でした。あるブランドのECサイトの運用を引き受けたとき、決済や在庫の連携に使っていた拡張機能が2年近く更新されていませんでした。作った会社はもう保守を受けていないと言い、更新すると表示が崩れるから触るなと前任者のメモに書いてある。結局、代替の仕組みに差し替えるまで6週間かかりました。この期間、公開されている弱点を抱えたまま運用していたことになります。デザインや売り上げの話は毎週するのに、依存しているソフトの寿命の話は誰もしていなかった。それが小さな現場のいちばん典型的な穴だと、そのとき理解しました。

脆弱性を突かれると実際に何が起きるか

脆弱性が悪用されたときの被害は、被害の種類ごとに回復の難しさがまったく違います。ここを区別しないまま「怖い」で終わると、対策の優先順位が付けられません。

いちばん多いのが情報の持ち出しです。顧客の氏名、住所、メールアドレス、注文履歴、場合によってはクレジットカード情報が外部に出ます。厄介なのは、データが消えるわけではないので気付きにくいことです。気付くきっかけは、カード会社からの連絡、外部の研究者からの通報、あるいは流出データが売買されているのを第三者が見つけた、といった外部由来がほとんどです。そして一度出た情報は取り戻せません。対応としては全件への通知、監督官庁への報告、問い合わせ窓口の設置、原因調査の外部委託が必要になり、金額よりも時間と信頼の消耗が痛みます。

次に多いのが改ざんと悪用です。サイトに不正なスクリプトが埋め込まれ、訪問者が別のサイトへ飛ばされたり、入力フォームの内容が攻撃者にも送られるようになったりします。自社が被害者であると同時に、加害の踏み台にされる形です。検索エンジンから警告が表示されるようになると集客が止まり、解除にも時間がかかります。サーバーを仮想通貨の採掘やスパムメールの送信に使われるケースもここに含まれます。

3つめがランサムウェアなどによる業務停止です。データが暗号化されて業務が止まり、復旧までの日数がそのまま売り上げの損失になります。侵入の入口として、公開サーバーの既知の脆弱性や、VPN機器の未更新が使われる例が繰り返し報告されています。

そして最も対処が難しいのがゼロデイ攻撃です。修正が公開される前、あるいは公開直後で当てる前の隙を狙う攻撃で、こちらには塞ぐ手段が一時的に存在しません。

総務省では、メーカーから脆弱性の発表・修正予定を公表されて実際に修正が行われるまでに、間髪をいれずサイバー攻撃を仕掛ける「ゼロデイ攻撃」についても注意喚起されています。出典: sei-info.co.jp

ゼロデイに対しては、「塞ぐ」以外の打ち手を用意しておくのが現実的な答えになります。具体的には、該当機能を一時的に止める、外部からの接続元を限定する、通信を監視して異常を検知する、被害が出ても復元できるバックアップを持っておく、の4つです。つまり脆弱性対策は修正パッチを当てるだけの作業ではなく、当てられない期間をどう乗り切るかまで含めた設計になります。国が出している注意喚起や最新の攻撃傾向は総務省のサイトでも随時公開されていますので、業種に関係する情報が出ていないか定期的に見に行く習慣を作ると判断が早くなります。

脆弱性の情報はどこで手に入り、どう優先順位を付けるか

対策を回すには、自分が使っているソフトの弱点が公表されたことを知る経路が必要です。そして公表される数は膨大なので、優先順位を機械的に決める仕組みも要ります。ここで使うのが識別番号と評価指標です。

まず識別番号です。世界共通で脆弱性1件ごとに付く番号がCVEで、CVE-年号-連番の形をしています。ベンダーの告知にもこの番号が載るので、「自分の環境に影響するか」を調べるときの検索キーになります。日本語で読める情報源としては、脆弱性対策情報のポータルであるJVNと、その詳細を集めたJVN iPediaがあり、製品名から絞り込めます。加えて、使っているソフトの公式リリースノートとセキュリティ告知のメール配信に登録しておくのが、遠回りに見えていちばん確実です。

次に評価指標です。CVSSは脆弱性の深刻度を0から10の数値で表す共通の尺度で、攻撃に必要な条件の難しさ、認証が必要か、影響が機密性と完全性と可用性のどれに及ぶか、といった観点を組み合わせて算出されます。一般に7.0以上を「重要」、9.0以上を「緊急」として扱う運用が多く、まずこの数値で並べ替えるのが第一段階です。

ただしCVSSの数値だけで順番を決めると外します。実務では次の3つを掛け合わせて判断します。1つめは、その機能を実際に使っているかどうか。導入しているが無効にしているモジュールの脆弱性は、優先度が下がります。2つめは、インターネットに面しているかどうか。社内LANからしか触れないシステムと、誰でもアクセスできる入口では緊急度がまったく違います。3つめは、攻撃コードが公開されているかどうか。実際に悪用が観測されている脆弱性は、数値が中程度でも真っ先に塞ぐべき対象になります。この3つを足すと、「CVSSは8.1だが該当機能は未使用だから今週でよい」「CVSSは6.5だが公開サーバーで悪用報告があるから今日やる」という判断ができるようになります。

この判断を毎回ゼロから考えるのは続きません。私が勧めているのは、自分が使っているソフトの一覧を1枚の表にしておくことです。列は、ソフト名、バージョン、用途、インターネットに面しているか、更新の担当者、最終更新日の6つでいい。この表があるだけで、ニュースで「あの製品に緊急の脆弱性」と流れたときに、自分に関係あるかを数分で判定できます。表がないと、毎回「そもそも何を使っていたか」の調査から始まるので、そこで力尽きます。脆弱性管理の入口は、道具ではなくこの一覧表です。

個人事業主と小規模チームが今日から踏める対策手順

ここからは手順の話です。専門部署も予算もない前提で、効果の大きい順に並べます。上から順に片付けるだけで、既知の弱点を突かれる確率は大きく下がります。

第1に、資産の棚卸しをします。前の節で触れた一覧表を作る作業です。使っているサーバー、ドメイン、CMS、プラグイン、SaaS、業務端末、クラウドストレージを書き出します。ここで毎回見つかるのが「もう使っていないのに動いている物」です。テスト用に立てたサブドメイン、昔のキャンペーンサイト、退職者が作ったフォーム。攻撃者はこういう放置された物を好んで探します。使っていないなら止める、これが最も費用がかからず効果の大きい対策です。

第2に、更新の仕組みを決めます。自動更新を有効にできるものは有効にし、できないものは月に1回の点検日を決めてカレンダーに入れます。日付を決めないと必ず先送りになります。更新で表示が壊れることを恐れて止めている場合は、壊れてもすぐ戻せる状態、つまりバックアップと復元手順を先に用意します。順番が逆になっているせいで更新できない現場が本当に多い。

第3に、認証を固めます。パスワードは使い回さず、パスワード管理ソフトで生成した長いものにし、管理画面には多要素認証を必ず入れます。ここは投資効率が最も高い部分です。仮に認証情報が漏れても、2つめの要素がある限り侵入は止まります。導入する製品の選び方と社内での進め方はMFA（多要素認証）導入のメリットと製品比較｜2026年の認証セキュリティ決定版に整理されており、認証アプリと物理キーの使い分けや、運用で詰まる場所が具体的に書かれています。

第4に、権限を絞ります。全員が管理者になっている状態をやめ、必要な人に必要な範囲だけを与えます。外注先に渡すアカウントは作業範囲に限定し、契約が終わったらその日に止める。この「止める日を決める」運用ができているかどうかで、事故の確率が変わります。

第5に、バックアップを取り、復元を試します。取っているだけでは資産になりません。実際に別の場所へ戻してみて、手順書に沿って何時間で復旧できるかを測っておきます。ランサムウェアに備えるなら、本番から切り離された場所に置き、書き換えられない設定にすることが条件になります。

第6に、公開している入口を減らします。管理画面のアクセス元をIPアドレスで制限する、使っていないポートを閉じる、不要なAPIを止める。攻撃できる面積を小さくするだけで、脆弱性が公表されたときの緊急度が下がります。

第7に、記録を残します。ログを一定期間保管し、誰がいつ管理画面に入ったかを追えるようにします。事故が起きたときに「何が持ち出されたか」を確定できるかどうかが、その後の対応の重さを左右します。ログがないと、最悪の想定で全件通知するしかなくなります。

補助金を使って費用を抑える選択肢もあります。中小企業向けの支援制度を使ってセキュリティ製品や診断を導入する進め方は中小企業のサイバーセキュリティ対策2026｜IT導入補助金で防御力を強化する方法にまとまっており、申請の流れと対象になりやすい費目が具体的に示されています。制度の要件は年度で変わるため、最新の公募要領は中小企業庁で確認してから動くのが確実です。

脆弱性診断と脆弱性管理の違い、外注するときの見方

ある程度規模が出てくると、自力の点検だけでは足りず、外部の力を借りる段階に入ります。このとき混ざりやすいのが脆弱性診断と脆弱性管理という2つの言葉です。

脆弱性診断は、ある時点のシステムを調べて弱点を洗い出す作業です。健康診断と同じで、受けた日の状態が分かります。診断には段階があり、ツールで機械的にスキャンするものと、技術者が手を動かして業務ロジックの穴まで探すものがあります。前者は費用が抑えられますが、権限の設計ミスのような文脈依存の問題は見つけにくい。後者は費用が上がりますが、決済やポイントのように金銭が動く機能では手動の診断でないと見つからない欠陥があります。予算が限られるなら、全体をツールで広く見て、金銭と個人情報に触れる画面だけ手動で深く見る、という配分が現実的です。

脆弱性管理は、診断で見つかったものと、日々公表される新しいものを、継続的に把握して塞ぎ続ける運用です。診断が点なら管理は線です。ここを外注せずに自社で回すなら、前述の資産一覧、更新の点検日、優先順位の決め方の3つを手順として書き残すことが最低条件になります。人の記憶で回している運用は、担当者が変わった瞬間に止まります。

外注先を見るときの観点も挙げておきます。1つめは、報告書に再現手順が書いてあるかどうか。「脆弱性があります」だけの報告書では直せません。どのリクエストを送るとどうなるか、どこを修正すればよいかまで書かれているかを、契約前にサンプルで確認します。2つめは、再診断が含まれているか。直したあとに本当に塞がったかを確認しないと、作業が完了しません。3つめは、検出した内容の説明を、開発者ではない担当者にもしてもらえるか。経営判断に必要なのは技術的な詳細より「放置すると何が起きるか」なので、そこを翻訳できる相手のほうが使いやすい。

なお、こうしたセキュリティ関連の実務は、正社員として組織に属さなくても業務委託で関わる形が増えています。どんな依頼が動いているのかはAI・マーケティング・セキュリティのお仕事に職種ごとの仕事内容がまとめられており、診断の実施だけでなく、社内規程の整備や教育の設計といった非開発の依頼もあることが分かります。システムの内側を触る側の仕事の広がりはアプリケーション開発のお仕事で、要件定義から保守までのどの工程が外部委託されやすいかを確認できます。

取引先からセキュリティチェックシートを渡されたときの読み方

小規模な事業者が脆弱性という言葉に初めて向き合うきっかけは、事故よりも取引先からの要求であることが多いです。新規に契約する段階、あるいは既存の取引で相手側の規程が変わった段階で、数十項目のチェックシートが送られてきます。この書類を前に固まってしまう人が多いので、読み方を書いておきます。

まず、全項目に「はい」と書く必要はありません。チェックシートの目的は、相手が自社の情報を預けたときのリスクを見積もることです。したがって重要なのは、できていない項目を隠すことではなく、できていない理由と代わりの手当を書けることです。たとえば「脆弱性診断を年1回実施しているか」に該当しない場合、自社では預かるデータが限定されており、該当システムを持たないので診断の対象がない、と書けば通ることがあります。逆に、できていないのに「はい」と書いて後で事故が起きると、契約違反として扱われます。正直に書いて代替策を添えるほうが、契約上も実務上も安全です。

次に、項目の意味が分からないときは相手に聞きます。この書類は一般的な様式を流用していることが多く、業態に合わない項目が混ざっているのが普通です。「当社の業務範囲ではこの項目に該当する設備がありませんが、その場合の記載方法をご指示ください」と1行聞くだけで、記入不要と返ってくることがよくあります。分からないまま空欄にすると差し戻しで往復が増えます。

そして、返送したあとが本番です。チェックシートで「はい」と答えた項目は、以後その状態を保つ約束になります。月1回の点検日に、シートで答えた項目をそのまま点検項目として使うのがいちばん楽な運用です。書類のために一度だけ整えて、半年後には元に戻っている状態が、いちばん危ない。答えた内容と実態を一致させ続ける仕組みまで作って、はじめてこの書類は意味を持ちます。私の場合は、返送したシートのコピーを点検日のカレンダーに添付して、毎回それを見ながら確認する形に落ち着きました。

市場の側から見えている、脆弱性対応の担い手の変化

手数料0%の直接取引を含むかたちで在宅と業務委託の市場を20年見てきた立場から、脆弱性対応の担い手について気付いていることを2つ書きます。

1つめは、依頼の入口が「診断してほしい」から「続けられる形にしてほしい」へ移っていることです。以前は年に1回の診断を発注して報告書を受け取る形が主流でした。ここ数年で増えているのは、月に数時間の関与で更新状況を点検し、公表された脆弱性が自社に影響するかを判定し、必要なら手を動かす、という継続的な関わりです。発注する側にとっては、専任を雇うほどの量はないが放置もできない、という中間の需要が満たされます。受ける側にとっては、単発の診断よりも収入が読めます。長く続いている人ほど、この「任せると楽な状態」を作ることに時間を使っています。技術力を上げることと同じくらい、相手の業務に合わせて報告の粒度を調整することが継続の条件になっている、というのが現場の実感です。

2つめは、中間マージンの構造が受け手の手取りに直結する話です。同じ予算でも、間に何社も入る形だと依頼者が実際に買える作業時間は目減りし、受け手の手取りも薄くなります。直接取引が成立している現場では、依頼者は同じ予算でより多くの点検を頼めて、受け手は同じ作業でも手取りが厚くなります。金額の多寡ではなく、支払った金額のうちどれだけが実作業に届いているかという質の差です。セキュリティのように継続的な関与が前提の仕事では、この差が年単位で積み上がります。

報酬の相場感を掴みたい場合、開発側の職種の水準はソフトウェア作成者の年収・単価相場に統計ベースの数字がまとまっており、常勤と業務委託で見るべき指標が違うことが分かります。セキュリティ領域で最初に取りやすい資格としては、ネットワークの基礎を体系的に押さえられるCCNA（シスコ技術者認定）が実務との距離が近く、通信の仕組みを理解していないと脆弱性の影響範囲を判断できない場面が多いため、遠回りになりません。診断結果を社内向けの文書に落とす作業が多い人は、報告書の型を学べるビジネス文書検定の内容が意外に役立ちます。技術的に正しくても伝わらない報告書は動かないからです。

最後に、20年見てきて変わらないことを1つ。事故を起こした現場と起こさなかった現場の差は、知識の量ではなく「使っている物を把握しているか」でした。何を使っているか書き出せる現場は、ニュースが流れたときに数分で自分に関係があるかを判定でき、関係があれば動けます。書き出せない現場は、調査で1日を使い、その間に決断が遅れます。脆弱性対策の第一歩が資産の棚卸しである理由は、技術の話ではなく、この判断速度の話です。今日できることが1つだけなら、使っているソフトの名前とバージョンを紙に書き出すところから始めてください。AIの活用や業務の自動化を進めている現場では、導入したツールの管理まで含めて相談を受ける形も増えており、どんな関与の仕方があるかはAIコンサル・業務活用支援のお仕事で依頼の実例を見ておくと、自分の守備範囲を決める助けになります。

よくある質問

Q. セキュリティの脆弱性とバグはどう違いますか？

バグは仕様どおりに動かない不具合の総称で、脆弱性はそのうち第三者が悪用すると本来できない操作ができてしまうものを指します。脆弱性はバグの部分集合ですが、コードが正しくても初期パスワードのまま公開している、権限が緩いといった設定や運用の問題も脆弱性に数えます。小規模な現場では後者のほうが実害につながりやすいです。

Q. 脆弱性の深刻度はどう判断すればよいですか？

まずCVSSの数値で並べ替え、7.0以上を重要、9.0以上を緊急として扱います。ただし数値だけでは足りません。その機能を実際に使っているか、インターネットに面しているか、攻撃コードが公開されているかの3点を掛け合わせて判断します。数値が中程度でも悪用が観測されている公開サーバーの脆弱性は、最優先で塞ぐ対象になります。