2,300万人。2,250万件。さらに1,100万件。
これはShopServe、Sourcenext、Burger King Japanの数字です。ここ数週間に日本企業が公表した侵害のうちの3件です。
侵害はこれだけではありません。
10月9日、日本の国会議員が集まり、国内の企業を襲うデータ侵害について議論しました。自由民主党のサイバーセキュリティに関するグループを率いるMasaaki Tairaは、この状況を緊急事態と呼びました。そして、政府と国民が一体となった国全体での対応を求めました。
その日の政府の助言はシンプルでした。Webの脆弱性を速やかに修正し、取引先を確認し、最も重要なデータに誰がアクセスしているかを監視すること。
1週間後、 JPCERT/CC（日本の国家インシデント対応チーム）が攻撃者の手口を明らかにしました。攻撃者はAIを使って既知の弱点を探し、APIを攻撃していました。さらに、攻撃対象となるAPIを見つけるために、モバイルアプリのコードまで調べていました。
今号では、この話を最初から最後まで追います。
この号の内容
🌡️ 脅威レベル：厳重警戒
⚡ ニュース：3件の侵害を取り上げます。Sourcenext、Burger King Japan、Studioです。
🔎 ディープダイブ：ShopServeの内側に迫ります。何年も前にプラットフォームを離れた店舗まで、侵害の影響を受けていました。
🎣 これはフィッシング？
🔬 技術研究：Metabaseのパスワードリセットが攻撃者に管理者権限を与えた仕組み（CVE-2026-72898）
🛠️ 今週のツール：Blutter。JPCERTが攻撃者のツールキットから発見したものです。自社のアプリが何を明かしてしまっているかを確認するのに使えます。
👏 今週の人物：Loren Kohnfelder。書籍『Designing Secure Software』の著者です。
📅 今週のイベント：東京で11月17〜18日に開催されるCODE BLUE。JPCERT/CCのCTOであるShusei Tomonagaが登壇します。
📚 今週の本：『Designing Secure Software』。攻撃者が仕組みを正確に知っていても安全であり続けるアプリの設計についての本です。
😅 今週のミーム
❓ 最後にひとつ質問
では、始めましょう。
🌡️ 脅威レベル
⚡ ニュース
攻撃者がSourcenextの会員APIを悪用し、2,250万件の記録が危険に
Sourcenextは、一般消費者向けにアプリやPCソフトウェアを販売している日本のソフトウェア企業です。
10月9日から13日にかけて、攻撃者はSourcenextが会員情報の照会に使っているAPIを悪用しました。同社は影響を受けた可能性のある記録として22,519,960件を挙げています。
顧客によって、これらの記録にはメールアドレス、パスワード、氏名、住所、電話番号、生年月日、アカウント情報が含まれる可能性があります。カード情報は、影響を受けたシステムには保存されていませんでした。
なぜ重要か：露出したデータには顧客のパスワードが含まれる可能性があります。そこが懸念すべき点です。
ほとんどの人は同じパスワードを複数の場所で使っています。そのため、あなたのメールアドレスとSourcenextのパスワードがあれば、攻撃者はあなたのメール、ショッピングのアカウント、さらには仕事用のアカウントへのログインを試せます。パスワードを使い回していれば、侵入されてしまいます。
だからこそSourcenextの通知では、そのパスワードを他で使っている場合はすべて変更するよう顧客に求めています。
Burger King Japanのアプリから約1,100万件の会員記録が漏えい
10月2日から7日にかけて、攻撃者はBurger King Japanのアプリ会員を管理するシステムに侵入しました。同社は約1,118万件の記録の漏えいを確認しました。氏名、連絡先、生年月日、会員情報です。
そのシステムにはカード番号は保存されておらず、現時点ではパスワードが漏えいした兆候もありません。攻撃者の侵入経路はまだ調査中です。
なぜ重要か：カード番号は漏えいしていないので、この件は無害だと考えがちです。しかし、そうではありません。
氏名、電話番号、生年月日があれば、詐欺師はBurger Kingを装ったメッセージを送れます。あなたについての本当の情報を知っているので、本物らしく見えます。リンクをタップすると、偽のページがパスワードやカード番号を求めてきます。
だからこそBurger Kingは顧客に不審なメール、SMS、電話に注意するよう呼びかけています。
Studioのデータは暗号化されていた。攻撃者は鍵にも到達した。
日本のWebサイト作成サービスであるStudioの脆弱性により、攻撃者がクラウド環境に侵入しました。登録しているすべての顧客が影響を受けた可能性があります。
露出した可能性があるもの：アカウント情報、Webサイトのコンテンツ、フォームの回答、そして顧客がStudioを他のサービスと連携させるために使っていたAPIキー。Studioはデータがダウンロードされたことを確認していませんが、ダウンロードされたものとして対応しています。
なぜ重要か：注意深く読むべきはStudioの件です。普段なら安全だと感じる3つのことが、持ちこたえなかったからです。
暗号化。一部のデータは暗号化されていましたが、攻撃者はそれを復号する鍵にも到達しました。
削除。ゴミ箱に入っていたフォームの回答も露出した可能性があります。対象外となったのは、9月30日より前に完全に削除されたものだけでした。
修正。Studioにパッチを適用しても、それで終わりではありません。顧客は、他のサービスへの鍵の一部を自分で差し替えなければなりませんでした。
Webサイト作成サービスが保持しているのはWebサイトだけではありません。それらのWebサイトがつながるすべてのものへの鍵を握っているのです。
🔎 ディープダイブ
ShopServeの侵害で、すでにプラットフォームを離れた店舗の顧客まで情報が露出
2022年8月、日本の文具メーカーKing Jimは、主要なオンラインストアをShopServeから移転しました。
4年後、同社はShopServeでの侵害について顧客に謝罪していました。
King Jimは、この侵害に巻き込まれた現在および過去の7,858店舗の一つでした。侵害の影響は約2,336万人に及びました。
King JimはもうShopServeを使っていませんでした。しかし、当時同社で買い物をした人々の記録はまだそこに残っていました。ShopServeが侵害されたとき、それらの記録が露出したのです。
そこで今回のディープダイブでは、シンプルな問いを立てます。プラットフォームを離れるとき、後に残した顧客データはどうなるのか。
ShopServeで何が起きたのか
ShopServeは、日本企業のE Storeが運営するオンラインストアのプラットフォームです。数千の事業者がオンライン販売に利用してきました。
2026年5月21日から8月1日にかけて、攻撃者はそのアプリケーションの一つにある欠陥を使って独自のプログラムを実行し、データベースの情報をシステムの外に送り出しました。E Storeは、その欠陥が何だったのかを明らかにしていません。
E Storeは10月16日に最終報告書を公表しました。影響を受けたのは約2,336万人で、7,858の現在および過去の店舗にわたります。そのうち約210万人はカード情報の一部が露出しましたが、完全なカード番号やセキュリティコードは含まれていませんでした。
攻撃者が手に入れたのは買い物客のデータだけではありません。店舗がショップの管理に使うログイン情報や、E Storeのアフィリエイトプログラムのログイン情報も手に入れました。
そして「現在および過去の」という言葉に注目してください。それらの店舗の中には、ずっと前にShopServeを離れていたのに、侵害の影響を受けたところがあったのです。
主要ショップをShopServeから移転していたのに侵害を受けた2つの店舗
文具のKing Jimは4年前に離れていた。
King Jimの9月4日の通知は、過去の顧客に関する情報が露出したことを確認しました。現在のオンラインストアは影響を受けていません。
しかも、影響を受けたのは旧ストアだけではありませんでした。通知では、すでに閉鎖されていたKing Jimの別のストアOffice Onlineも対象になっていました。そのストアはもう存在しないのに、顧客のデータはまだ侵害の一部だったのです。
そして厄介な点が出てきます。King Jimは、個々の顧客が影響を受けたかどうかを確認できないと述べました。それを確認するための情報を持っていなかったからです。顧客からの問い合わせはE Storeに回すしかありませんでした。
つまりKing Jimは、すでに離れたプラットフォームでの侵害について謝罪し、それでも自社の顧客の質問に答えられなかったのです。
PFUの記録は2008年までさかのぼっていた。
スキャナーを製造するRicohグループのPFUは、2025年10月に主要ストアをShopServeから移転しました。一部の個別の販売ページは2026年9月までプラットフォーム上に残っていました。
危険にさらされた記録は2008年12月までさかのぼり、最大169,355件の注文に及びました。
目を引くのは、自社の顧客が関係していると知るまでにPFUがどれだけ時間を要したかです。
8月2日：PFUが侵害について知らされる
9月8日：PFUがE Storeに問い合わせ、主要ストアの過去の顧客が影響を受けた可能性があると知る
9月17日：PFUが、過去の顧客のデータが影響を受けたとの確認を得る
9月18日：PFUが謝罪を公表
侵害について聞いてから、自社の顧客が含まれていると知るまで、6週間以上かかったことになります。
それでも顧客に説明しなければならなかったのは店舗だった
侵害が起きたのはShopServeです。しかし、顧客に連絡し、謝罪し、質問に答えたのはKing Jim とPFUでした。
顧客から見ればそうなります。顧客はE Storeで買い物をしたわけではありません。King JimやPFUで買い物をしたのです。データが漏えいすれば、知っている名前に目を向けます。
プラットフォームを離れても、それは変わりませんでした。古いデータがまだそこにあったからです。なぜ保持されていたのか、誰かが削除を求めたのかどうかは、誰も明らかにしていません。
私たちが読んだのは、7,858店舗のうちこの2店舗の通知だけです。しかし、古い顧客データを残したままShopServeを離れた店舗は、どこも同じ立場にある可能性があります。
ベンダーを離れるときにすべきこと
削除を書面で依頼する。プラットフォームを移行するときは、ベンダーに顧客データの削除を依頼し、完了したことを確認してもらってください。
まだ何を保持しているかを把握する。一部の記録を保持しなければならない場合は、どの記録をいつまで保持するのかを確認してください。
侵害された場合の対応を取り決めておく。ベンダーは速やかに連絡し、自社のどの顧客が影響を受けたかを伝えるべきです。そうすれば、知るまでに6週間も待たずに済みます。
プラットフォームの変更は一つのステップです。顧客データを削除してもらうのは別のステップであり、忘れがちです。
出典： E Storeの最終報告書 · King Jimの通知 · PFUの通知
🎣 これはフィッシング？
「ShopServeカスタマーサポート」からのメールで、あなたの情報がShopServeの侵害に含まれていたと告げられます。
メールはあなたの氏名、以前の配送先住所、カードの下4桁を知っています。何が露出したかを確認するには、インシデント確認ポータルにサインインするよう求めてきます。
メッセージと、ボタンのリンク先をよく見てください。
これはフィッシング？
🔬 技術研究
Metabaseのパスワードリセットが攻撃者に管理者権限を与えた仕組み（CVE-2026-72898）
パスワードリセットのページは誰でも使えます。それが目的です。パスワードを忘れたなら、先にログインすることはできないからです。
したがって、このページが求めるべきものは2つだけです。メールで届いたリセットトークンと新しいパスワードです。それ以外に送られてきたものはすべて無視すべきです。
Metabaseのリセットページは、それ以外を無視しませんでした。攻撃者がフィールドを1つ余分に送ると、Metabaseはそれをそのままデータベースクエリに入れてしまいました。しかも、リセットトークンが有効かどうかを確認する前にそうしていたのです。
これがCVE-2026-72898、ログインなしで機能するSQLインジェクションです。影響を受けるのはMetabaseで、多くの企業がデータウェアハウス上にダッシュボードを構築するために使っているオープンソースのツールです。
評価はCVSS 10.0です。攻撃者は修正が存在する前からこれを悪用していました。最初はMetabase自身のクラウドサービスに対して、その後は世界中で自社サーバー上でMetabaseを運用している企業に対してです。
これは今号のテーマとつながっています。JPCERT/CCは8月14日、この欠陥について専用の注意喚起を公表しました。10月8日には、日本の組織で最近相次いでいる侵害の背後にある手法の一つとして、Metabaseへの攻撃を挙げました。
JPCERTは日本の被害組織の名前も数も明らかにしておらず、この欠陥とディープダイブで取り上げたShopServeの侵害を結び付ける公開情報もありません。ただ、インターネットから到達可能な一つの社内ツールが、攻撃者をその背後にある顧客データへと導き得ることは示しています。
Metabaseとは何か、なぜ攻撃者に狙われるのか
Metabaseを使えば、社内の誰もがSQLを書かずにダッシュボードを作成し、クエリを実行できます。そのために、Metabaseは企業の実際のデータベース（PostgreSQL、MySQL、Snowflake、BigQuery、Redshiftなど）に接続し、それらの接続用の認証情報を保存しています。
つまり設計上、次のようなシステムです。
企業の最も重要なデータベースに対して有効な認証情報を保持している
それらすべてからデータをクエリし、エクスポートできる
セキュリティチームではなくデータチームによってデプロイされることが多く、どこからでも使えるようにインターネットから到達可能なまま放置されることもある
Metabaseは自らの状態（ユーザー、セッション、APIキー、設定、そして先ほどの接続情報）を内部のアプリケーションデータベースに保存しています。今回のインジェクションが届くのは、この内部データベースです。
バグ：リセット用エンドポイントが余分なフィールドを受け入れていた
Metabaseのリセット用エンドポイントPOST /api/session/reset_passwordは、想定する2つのフィールドを宣言していました。
request-body :- [:map
[:token ms/NonBlankString]
[:password ms/ValidPassword]]このスキーマは、tokenとpasswordが存在し、有効であることを確認します。それ以外のフィールドは拒否しません。
MetabaseのスキーマライブラリであるMalliは、デフォルトでマップをオープンとして扱います。そのため、JSONボディ内の余分なキーはすべて検証を通過し、tokenとpasswordとともに共通のログイン処理に渡されていました。
そのログイン処理は次のように始まっていました（バージョン0.58.22のauth_identity/provider.cljより）。
(merge request (authenticate provider request))
...
(when-let [user-id (:user-id $)]
(t2/select-one [:model/User ...] :id user-id))リクエストと認証結果をマージし、:user-idでユーザーを検索します。
認証が成功すると、結果には本物の:user-idが含まれ、リクエスト内の値を上書きします。
認証が失敗すると、たとえばリセットトークンが無効な場合、結果には:user-idが含まれません。Clojureのmergeは両方のマップに存在するキーしか上書きしないため、攻撃者が指定したuser-idはマージ後も残り、コードはその値でユーザーを検索します。
これが1つ目の問題です。認証が失敗した場合でも検索が実行されていたのです。
余分なフィールドがSQLインジェクションになった経緯
残ったuser-idだけなら、攻撃者はコードが取得するユーザーレコードを選べるにすぎません。それをSQLインジェクションに変えたのは、Metabaseのクエリの組み立て方でした。
MetabaseはHoneySQLを使っています。Clojureのデータ構造からSQLを組み立てるライブラリです。通常、値はパラメーターとして送られ、それがクエリを安全に保っています。しかしHoneySQLは:raw形式もサポートしており、その内容はパラメーター化されずにSQLのテキストへ直接入ります。Wizの分析が説明しているように、user-idとして送られたJSONオブジェクトはClojureのマップとして届き、そのマップにrawキーがあると、HoneySQLはそれを文字列をそのままクエリに挿入する指示として扱います。
まとめると、次のようになります。
攻撃者は、任意のトークン、有効に見えるパスワード、そして生のSQL断片を含む余分なuser-idフィールドを付けてリセットリクエストを送る
スキーマは宣言したフィールドしか確認しないため、検証を通過する
トークンのチェックは失敗するため、認証結果には攻撃者の値を上書きするuser-idがない
ユーザー検索は、攻撃者の断片からWHERE id = ...句を組み立て、アプリケーションデータベースに対して実行する
リクエストは400「Invalid reset token」エラーで失敗するが、その時点で注入されたSQLはすでにアプリケーションデータベースに対して実行されている
ここではバグを説明しているのであって、動作するエクスプロイトを配布しているわけではありません。正確なペイロードは、Metabaseのバックエンドがどのデータベース（H2、PostgreSQL、MySQL、MariaDB）かによって異なります。また、公開された概念実証（PoC）コードは8月10日から入手可能になっています。
攻撃者が得るもの：管理者権限と、接続されたすべてのデータベース
インジェクションが実行されるのはMetabaseの内部ストアであり、顧客のデータに直接ではありません。それでも、内部ストアが保持しているものを考えれば、攻撃者は多くを得ます。ベンダーのアドバイザリのタイトルは「SQL injection using an unauthenticated endpoint leading to admin access」であり、Bishop Foxはそこから生じる結果を次のように挙げています。
Metabaseへの完全な管理者権限
アプリケーション設定の変更と、実行中のアプリケーションが利用できるシークレットの読み取り
Metabaseの権限による、Metabaseが接続しているすべてのデータベースからのデータのクエリとエクスポート
だからこそ、CVSSベクトルではスコープが「変更あり」とされています。バグはMetabaseにありますが、被害はMetabaseがクエリできるすべてのデータベースに及びます。
実際のインシデントがこれを裏付けています。Metabaseは実環境での悪用を確認し、CISAは8月11日にこの欠陥をKnown Exploited Vulnerabilitiesカタログに追加しました。さらに、Framework、Tally、n8n、ChecklyHQなどの企業が、自社のMetabaseインスタンスを通じて顧客データにアクセスされたことを公表しました。
報告されたデータには、氏名、メールアドレス、電話番号、請求先住所、パスワードハッシュ、APIトークンが含まれていました。
Metabaseはこの脆弱性をどう修正したか
修正は0.58.24、0.59.21、0.60.17、0.61.11、0.62.9、0.63.5で提供され、対応するEnterprise 1.xのリリースも出ています。これらより前のバージョンで、58から63のリリースラインのセルフホスト型Metabaseが影響を受けます。Metabase Cloudは公開アドバイザリの前にパッチが適用されました。
Metabaseの現在のソースにあるリセットとログインのコードを見ると、問題は1か所ではなく複数の箇所でふさがれています。
エンドポイントのスキーマがクローズドになった。現在は[:map {:closed true} ...]となっており、宣言されていないフィールドを含むリクエストは拒否されます。
想定されたフィールドだけが渡される。ハンドラーはselect-keysを呼び出して:tokenと:passwordだけを転送し、それ以外は何も渡しません。
リクエストデータが本人確認用のフィールドを供給できない。マージの前に、ログイン処理は認証によって設定されるべきキー（:user-id、:user、:success?など）をすべてリクエストから削除します。
成功しなければ検索しない。ユーザーが解決されるのは、認証が実際に成功し、かつuser-idが正の整数である場合だけです。それ以外はログに記録され、拒否されます。
これらのどれか一つでも、今回のエクスプロイトは防げていたはずです。4つすべてがあることで、将来どこか一つの層でミスがあっても、それが新たなCVEになる可能性は低くなります。
Metabaseを運用している場合に確認すべきこと
パッチ適用は「まだ脆弱か」には答えますが、「すでに侵害されていたか」には答えません。
影響を受けるバージョンで/api/session/reset_passwordがインターネットから到達可能だった場合、ベンダーとJPCERTはいずれも、そのインスタンスを侵害された可能性があるものとして扱うよう求めています。
悪用のパターンを探す。POST /api/session/reset_passwordが400を返し、その後にGET /api/user/currentが200を返すパターンです。JPCERTは、この一連の流れは侵害を強く示唆するとしています。Wizは、正当なリセットリクエストにはtokenとpasswordしか含まれないため、user-idキーを含むボディはすべて疑わしいと補足しています。
JPCERTが公表した痕跡を確認する。2026年8月上旬から9月上旬にかけての、213.163.202[.]171、221.216.140[.]49、221.216.140[.]129からのリクエスト、またはユーザーエージェントがpython-requests/2.33.1やMetabase-GHSA-vwf4/2.0のリクエストです。JPCERTは、これらのIPは現在では正当に使われている可能性があると注記しています。
無効化とローテーション。core_sessionテーブルの全行を削除してすべてのセッションを終了させ、誰も心当たりのないAPIキーを削除し、管理者アカウントを見直し、接続されているすべてのデータベースの認証情報をローテーションしてください。
データ側を確認する。Metabaseのアクティビティとクエリの履歴、そしてデータウェアハウスのログを確認し、チームの誰も実行していないクエリやエクスポートがないか調べてください。
すぐにアップグレードできない場合は、リバースプロキシまたはファイアウォールで/api/session/reset_passwordをブロックしてください。
開発者への教訓
想定するものだけでなく、受け取るものを検証する。必須フィールドは確認しても余分なものを受け入れるスキーマは、穴の開いたフィルターです。認証不要のエンドポイントでは、宣言されていないフィールドを拒否するか、必要なフィールドだけを渡してください。
リクエストデータと信頼されたデータに名前空間を共有させない。認証結果も保持するマップにユーザー入力をマージすると、一方でキーが欠けていれば、それがもう一方では攻撃者の入力になります。両者を分けておくか、先に入力から信頼されたキーを取り除いてください。
失敗時の経路にも、成功時の経路と同じだけの注意が必要。今回の検索は、認証がすでに失敗した後に実行されていました。エラー時の経路で実行されるコードも、そのエラーを引き起こせる者なら誰でも到達できます。リセット用エンドポイントの場合、それは全員です。
クエリビルダーでも、抜け道がどこにあるかを把握しておく必要がある。HoneySQLはデフォルトで値をパラメーター化しますが、:raw形式はそうではありません。信頼できないデータがスカラー値ではなく構造としてクエリビルダーに届き得るなら、その構造で生のSQLを表現できないかを確認してください。
インターネットに公開されている社内ツールは、公開システムとして扱う。JPCERTの10月の注意喚起は、BIツールと従業員向けシステムを特に挙げています。公開アプリと同じ対策で確認してください。データウェアハウスの認証情報を保存したダッシュボードツールは、攻撃者が到達できるシステムの中でも最も価値の高いものの一つです。
🛠️ 今週のツール：Blutter
調査したサーバー上で、JPCERT/CCはAndroidアプリのファイルとともに、2つのリバースエンジニアリングツールに関連するファイルを発見しました。逆コンパイラーのJADXとBlutterです。
攻撃者はアプリをリバースエンジニアリングして背後にあるAPIを見つけ、それらのAPIに弱点がないかテストしていました。
Blutterは、Flutterアプリ向けに作られたツールです。
Blutterでできること
JADXのような逆コンパイラーでは、Flutterアプリはあまり解析できません。Dartのコードがネイティブのマシンコードとしてlibapp.soにコンパイルされているためです。Blutterは、そのファイルをリバースエンジニアリングするために作られています。得られるものは次のとおりです。
関数名が復元された、アセンブリ形式のアプリのコード
アプリのDartオブジェクトのダンプ。サーバーのアドレスやハードコードされたキーが現れる
実行時にアプリをフックするためのFridaスクリプトのテンプレート
自社アプリでBlutterを使う方法
自社のアプリ、またはテストする権限のあるアプリに対して実行してください。抽出されたオブジェクトからサーバーのアドレスやハードコードされたキーを探し、それぞれのキーが何にアクセスできるかを確認してください。
制限事項
Android ARM64のみ、かつ比較的新しいDartのバージョンのみに対応。iOS対応は未完成で、難読化されたアプリには完全には対応していない
完全な逆コンパイラーではない。得られるのはアセンブリとオブジェクトで、ソースコードではない
セットアップにはビルドツールが必要で、対応するDartランタイムを先にコンパイルしなければならない場合がある
まとめ
このようなツールがあれば、アプリをダウンロードした人は誰でも、そのアプリがサーバーとどう通信しているかを解明できます。APIをアプリの中に隠しておいても、守ることにはなりません。
APIを守るのは、リクエストのたびに、誰が要求していて何を見ることが許されているかをサーバーが確認することです。
👏 今週の人物：Loren Kohnfelder
1978年、Loren KohnfelderはMITで学部の卒業論文Towards a Practical Public-key Cryptosystemを執筆しました。この論文はデジタル証明書を導入しました。公開鍵を名前に結び付ける署名付きの記録です。今日のHTTPSを支える証明書は、この考え方の上に成り立っています。
Microsoftでは、Praerit GargとともにSTRIDEを考案しました。システムに対する脅威を検討する手法として、最も広く使われているものの一つです。また、.NETプラットフォームのセキュリティ業務も率いました。Googleではセキュリティチームに所属し、プライバシーチームの立ち上げに携わり、大規模システムのセキュリティ設計をレビューしました。
現在は引退し、その経験を今号の「今週の本」にまとめています。
40年以上にわたり、設計段階からシステムを安全にするために取り組んできた功績により、Loren Kohnfelderを今週の人物に選びました。
📅 今週のイベント
CODE BLUE 2026
CODE BLUEは東京で開催される国際セキュリティカンファレンスです。日本、アジア各国、欧州、米国の研究者が最新の成果を発表し、ワークショップ、コンテスト、25歳以下の登壇者向けトラックも用意されています。
日本の侵害の波を扱った号の後には、自然な次の目的地です。ほとんどの講演には日英の通訳が付くので、日本語が話せなくても内容を追えます。
今号と特に関係の深い講演があります。JPCERT/CCのCTOであるShusei Tomonagaと、Yuki Yano（同組織のインシデントレスポンスグループ所属）が、Quality Assurance for Incident Response in the Age of AIを発表します。
侵害の後、誰かが調査報告書を書きます。しかし、その報告書が結論を本当に裏付けているかどうか、どうすればわかるのでしょうか。
講演では、JPCERT/CCが日本のインシデント対応事業者、CSIRT、SOCチームの13組織と協力して2つのチェックリストとサンプル報告書を作成し、それらに照らして報告書をレビューするLLMエージェントを構築した経緯を説明します。
📍 Bellesalle Takadanobaba、日本・東京 📅 2026年11月17〜18日
📚 今週の本
Designing Secure Software
今号では、一つの事実に繰り返し立ち返ってきました。攻撃者はシステムの仕組みを解明する、ということです。JPCERTは、攻撃者がモバイルアプリを読み解いて背後にあるAPIを洗い出していたことを突き止めました。
Designing Secure Software: A Guide for Developers（著：今週の人物であるLoren Kohnfelder）は、その前提から出発します。この本は、最後に付け足すのではなく、システムの設計にセキュリティを組み込むことをテーマにしています。
そのパターンの一つがTransparent Designです。攻撃者が仕組みを正確に知っていても、システムは安全であり続けるべきだという考え方です。パスワードや鍵を公開するという意味ではありません。それらは秘密のままです。設計そのものが、隠されていることに依存してはならないという意味です。
😅 今週のミーム
昔のベンダーの一つが明日侵害されたとしたら、自社の顧客が影響を受けたかどうかを知るまでに、どれくらいかかるでしょうか。
The Breach Brief、
Ostorlabチーム