社内 GitLab に本番 DB の鍵を置かない：91APP の 480 万人分の注文データ侵害

外から入られた後、攻撃者が最初に探すのは社内のリポジトリ。「社内だから」とコードや設定に書いた本番の鍵が、そのまま本丸への切符になる。

台湾の EC 基盤事業者 91APP は、未更新のアプリ開発基盤 Appsmith の脆弱性から社内ネットワークへ入られ、内部 GitLab で得た鍵で注文データベースに侵入されたと説明している。
盗まれた注文を特定できず、最大 1,329 ブランド・約 480 万人を通知・補償の対象にした。攻撃では、脆弱性探索から窃取までを AI で自動化する「ARTEX」の痕跡も確認された。
同社は防御とパッチ管理の遅れを認め、マイクロセグメンテーションと最小権限化に移る方針。

社内リポジトリもシークレットスキャンする: 公開リポジトリと同じく、社内 GitLab・GitHub Enterprise の全リポジトリと Git 履歴を gitleaks や TruffleHog で走査する（Semgrep＋gitleaks（＋secretlint）の二段構えを全リポジトリに入れる）。見つかった鍵は削除ではなく失効・交換する。
本番の鍵はリポジトリに置かない: 実行時にシークレット管理から注入する（シークレットを実行時に注入するツールの選び方）。
社内向けの開発基盤も更新対象に入れる: Appsmith のような社内ツール作成基盤、Jenkins、GitLab 自体は「社内だから」と更新が後回しになりやすい。外部公開の有無にかかわらず、パッチ管理の一覧に載せる。
DB への経路を分ける: 社内ネットワークに入れただけで本番 DB に届かないよう、DB への接続元を特定のアプリサーバーに限定する。鍵が漏れても経路がなければ使えない。
影響範囲を絞れるログを残す: 91APP は「どの注文が盗まれたか」を特定できず、18 か月分を最大範囲にした。DB の読み取りログ（誰が・どのテーブルを・何件）を残しておくと、通知範囲を小さくできる。