ソースコードの脆弱性による情報漏洩事例｜原因と3つの対策

自社のWebサービスや社内システムについて、「セキュリティ対策は大丈夫だろうか」と気になっていても、ソースコードの中身までは確認したことがなく、不安を感じているIT担当者や経営層の方も多いのではないでしょうか。

日頃から問題なく動いているシステムであっても、コードの中に潜むわずかな不備がきっかけとなり、十数万件のカード情報や1億人を超える個人情報が流出した事故は、国内外で現実に起きています。

しかも今回取り上げる事例の多くは、未知の高度な攻撃ではなく、「直せたはずの欠陥がそのままになっていた」「第三者の目で中身を確かめていなかった」という身近な見落としから発生しています。

そこで今回は、ソースコードの脆弱性が引き起こした代表的な漏洩事例をパターン別に振り返ります。そのうえで、なぜ防げなかったのかという共通の原因と、自社コードのリスクを確かめるには何から始めればよいのかをまとめます。

ソースコードの脆弱性とは？動いていても安全とは限らない

システムの不具合というと「画面が真っ白になる」「エラーが出て動かなくなる」といったバグを思い浮かべがちですが、脆弱性はこれらとは性質が大きく違います。

脆弱性とは、画面上は何ごともなく正常に動いているように見えても、攻撃者が不正に侵入したりデータを盗み出したりできる「抜け穴や欠陥」がコードの内部に残ってしまっている状態を指します。

つまり、システムが「普段どおり動いていること」と「安全であること」は全く別の話です。

プログラムは、開発者がコードに書いた指示（仕様）のとおりに動きます。

しかし攻撃者が狙うのは、まさにその「開発者が想定していなかった操作や入力の隙間」です。

通常の開発現場では「機能が正しく動くか」をテストしますが、「攻撃者の視点から悪用されない作りになっているか」を確かめるには、まったく異なるセキュリティの視点が必要になります。

国際的なセキュリティ組織であるOWASPが公開している「OWASP Top 10」でも、アクセス権限の不備や古いコンポーネントの放置などが代表的なリスクとして定義されており、実際に起きている漏洩事例の多くもこの分類に当てはまっています。

あわせて読みたい

OWASP TOP10 とは？対策必須のリスクと費用対効果を最大化する対策

「うちのWebシステムのセキュリティ、本当にこれで大丈夫なのかな…？」 「Webアプリのセキュリティ対策、何から手をつければいいんだろう…？」 Webアプリケーションの開発や運用に携わっていると、こんな不安を感じることはありませんか？ セキュリティ対策は、今や避けて通れない重要な課題ですよね。

ソースコード脆弱性による情報漏洩事例

ソースコードの脆弱性が引き起こした実際の情報漏洩事故を振り返ると、原因は大きく「既知の脆弱性の放置」「設計や実装の不備」「コードや設定情報の露出」という3つのパターンに分けることができます。

なお、ここでいうソースコードの脆弱性には、自社で書いたコードの欠陥だけでなく、利用しているライブラリやCMSの脆弱性、コードや認証情報の管理不備も含みます。

いずれも「コードとその周辺を誰も確認していなかった」ことが被害につながった点は共通しています。

既知の脆弱性を放置：修正パッチを当てず1.47億人分が流出（Equifaxの事例）

2017年、米国の信用情報大手Equifax社で起きた情報漏洩事件は、既知のソフトウェア脆弱性を放置したことで起きた大規模な事故です。

この事件の原因は、自社システムで利用していたWebアプリケーションフレームワーク「Apache Struts」に存在していた既知の脆弱性を、修正プログラム（パッチ）を適用せずに放置していたことでした。

その結果、約1億4,700万人分もの個人情報が流出する事態となりました。

ここで重要なのは、攻撃者が未知の高度な手法を使って侵入したわけではないという点です。

脆弱性の存在自体はすでに公表されており、修正する方法も用意されていました。

つまり「知らなかった」のではなく、修正パッチが用意されていたにもかかわらず、それが適用されないまま運用が続いていたために防げなかったのです。

設計・実装の不備：CMSの脆弱性を突かれ約14万件のカード情報が漏洩（EC-CUBEの事例）

外部とのネットワーク境界やリポジトリへのアクセス管理をどれほど固めていても、プログラムの処理ロジックそのものに欠陥があれば、正規の利用を装ってデータを抜き取られてしまいます。

広く普及しているECサイト構築用CMS「EC-CUBE」の脆弱性が狙われた事例では、経済産業省とIPAが2019年12月に注意喚起を出しています。

その時点で、漏洩したクレジットカード番号等は約14万件にのぼるとされました。

ECサイトのように多くのユーザーが利用し、決済や個人情報の入力を伴うシステムでは、コードの処理ロジックにわずかな隙が残っているだけで、被害が一気に広がるおそれがあります。

「画面が正常に動いて決済も完了できているから問題ない」と見過ごされやすい箇所だからこそ、アクセス制御や入力処理に不備がないかを、設計や実装の段階で第三者の目で確かめる必要があります。

コード・設定情報の露出：外部に出た認証情報から22万件超が漏洩（CAMPFIREの事例）

個人情報の流出には至っていなくても、ソースコードや設定ファイルが外部から見える状態になれば、攻撃の手がかりを与えるおそれがあります。

2026年3月には、AI開発ツール「Claude Code」の公開パッケージに、ソースマップファイルが誤って同梱されたまま配布される事態が起きました。

ソースマップは、製品版のコードを元のソースコードに対応づけるための開発用ファイルです。これが同梱されていたため、第三者が元のTypeScriptコードを復元できる状態になっていました。

原因は攻撃ではなく、ビルドツールが既定で生成するファイルを、公開時の除外設定に入れ忘れたことでした。開発元のAnthropicも「人為的ミスによるリリースパッケージングの問題であり、セキュリティ侵害ではない」とコメントしています。

あわせて読みたい

Claude Codeは情報漏洩する？AIで作ったアプリに潜むリスクと対策を解説！

「Claude Code（クロードコード）、便利だよ」。そんな声を、最近あちこちで見かけるようになりました。プログラミングをやったことがない人でも、日本語で頼むだけでアプリやツールが作れる。実際に自分の仕事を楽にするツールを作ってみて、「これはすごい」と感じた方もいるはずです。 ところが、社内で使

さらに、コードや設定情報の露出が実際の個人情報漏洩につながった国内事例として、クラウドファンディング大手のCAMPFIRE社が2026年4月から6月にかけて公表した事案があります。

同社の発表によると、従業員が発行したGitHub認証情報が個人開発用サーバー上に意図せずアップロードされ、それが第三者に不正利用されたことが発端となりました。

攻撃者はそこから社内クラウド環境の認証情報を探索・取得し、管理領域へ不正アクセスをおこないました。

結果として、プロジェクトオーナーや支援者など、重複を除いて225,846件の個人情報（氏名・住所・電話番号・メールアドレス・口座情報等）が漏洩した可能性があると報告されています。

この事例が示しているのは、「ソースコードが外部に見られただけでは終わらない」ということです。

外部に露出した認証情報を足がかりに、別の認証情報や権限までたどられ、データベース本体へ侵入される危険があるのです。

なぜ情報漏洩を防げなかったのか？

これほどの大規模な被害をもたらした事例であっても、根本的な原因をたどると「なぜ今まで誰も気づかなかったのか」という疑問に行き着きます。

その背景には、開発や運用の現場に共通する構造的な見落としがあります。

「誰かが確認しているはず」という思い込み：セキュリティ視点での検証が抜け落ちる

日々のシステム開発では、どうしてもリリースの納期や新機能の実装スピードが最優先になりがちです。

その結果、セキュリティの確認は「後回し」にされやすくなります。

特に外注先へ開発を依頼している場合や、AIツールを使ってコードを生成している場合、「納品されて画面が動いているから大丈夫だろう」と受け入れ、コードの中身までセキュリティの観点で精査しないまま本番環境へ公開してしまうことも珍しくありません。

また、度重なる改修で担当エンジニアが入れ替わっていくうちに、システム全体のコード構造を把握している人が社内からいなくなってしまうこともあります。

「開発者がコードを書いた（読んだ）」ことと、「セキュリティの専門家が攻撃者の視点で中身を検証した」ことは、全く別物です。

この構造的な盲点を示す国内の事例が、転職サービス「doda」を運営するパーソルキャリアの事案です。

求人広告の販売代理店向けシステムに不備があり、代理店の業務では閲覧する必要のない採用担当者の個人情報（氏名・メールアドレス）が、代理店1,164社から閲覧できる状態になっていました。

対象は549,195件。この状態が2018年5月から2024年8月まで、6年以上にわたって誰にも気づかれていませんでした。

発覚のきっかけは、取引のない代理店から営業を受けた採用担当者が「なぜ自分の情報を知っているのか」と問い合わせたことです。社内の点検ではなく、外部からの指摘で初めて分かりました。

この事例が示しているのは、「事前に第三者の視点でコードや設定を確認していれば、防げた可能性があった」という点です。

「ツールで確認済み」という安心感：設計レベルの欠陥は自動スキャンでは見つけにくい

セキュリティ対策として、ツールによる自動スキャンを導入する企業も増えています。

しかし、自動スキャンは既知のパターンを機械的に検出するのに向いているものの、「他人のデータが見えてしまうようなアクセス権限の不備」など、システムの仕様や文脈に依存する設計・実装レベルの欠陥を捉えるのは困難です。

OWASP Top 10でもアクセス制御の不備が第1位に挙げられています。こうした設計上の問題はツールの自動判定だけでは見落とされやすいため、手動による確認と組み合わせることが欠かせません。

「うちは狙われない」は通用しない、自社コードは確認されているか

ここまで見てきた事例は、「古いライブラリの放置」「実装上のロジック不備」「認証情報やコードの外部露出」と、それぞれ原因が異なります。

ただし、公開前や運用中の確認が十分でなかった点は共通しています。

「うちのような規模の会社は狙われないだろう」「専門のエンジニアや外注先に任せているから問題ないはずだ」と考えてしまうのは自然なことです。

しかし、攻撃者は企業の知名度にかかわらず、Web上に公開されているシステムの隙を広く探して攻撃を仕掛けてきます。

これらを「大企業だけの特別なトラブル」として片付けるのではなく、「自社のWebサイトやWebアプリの中身は、誰かが攻撃者目線で確認したことがあるだろうか」と問い直してみることが、リスクを未然に防ぐ第一歩となります。

自社コードの脆弱性を放置しないために取り組むべき3つの対策

では、自社のコードに潜むリスクを放置せず、安全性を保つには何から始めればよいのでしょうか。

対策は、開発時の予防、既存コードの点検、継続的な運用の3段階で考えます。

開発段階の予防：ライブラリの更新と安全なコード管理を徹底する

これから新しく開発するシステムや追加機能については、コードを書く段階からリスクを減らすルールを整えることが基本です。