#なぜ今日これを選んだか

鍵の漏洩は、腕のいいエンジニアでも「置いた場所が思ったより見えていた」で起きる事故です。バグバウンティでも定番の入口で、守る側と探す側の両方の視点が一度に手に入ります。個人開発でAPIやMCPを多用している今、自分の足元を見直すきっかけになると思って選びました。

#要点

• 筆者のサイトには22日間で攻撃らしき要求が8,219件届き、そのうち .env を探すものが1,566件以上、.git を探すものが108件以上あった（中身を返したのは0件）
• 漏れる経路は7つ: ①公開リポジトリ（2025年に公開GitHubで見つかった鍵は2,865万件）②Webの公開フォルダ ③パッケージ・コンテナ ④ログと会話記録 ⑤AI設定とMCP ⑥学習用の公開データ ⑦後から広がる権限
• コードから鍵を消しても、鍵そのものは使える。気づいたら最初にやるのは「その鍵を無効化する」こと

#自分にとっての示唆

ローカルで動かしているサーバーやAIエージェントの設定ファイルに、鍵を直書きしている箇所がないかを一度洗い出したい。特に⑤のMCP設定と④のログは、AIを使うほど増えていく新しい経路で、昔の「.envをgitignoreすれば安心」では守れない。明日からの具体的な一手は、手元のリポジトリにシークレットスキャン（gitleaks など）を1回かけてみること。見つかった鍵はコードを直す前にまず取り消す。この順番を体で覚えておけば、仕事でもバグバウンティでも同じ型で動ける。

原文を読む →