セキュリティレビューのゲート

ここまでのすべてを「不安」から「プロセス」へと変える、たった1つの習慣がある。出荷する前に、AIに自分のコードを攻撃させることだ。その機能を書いたモデルは、たいていその中の穴を見つけられる——ただ、頼まれない限りそうしないだけだ。AIを「作る側」から「敵対する側」へ反転させよう。

あなたはこのエンドポイントを書いた。今度は、それを破ろうとする攻撃者として振る舞ってほしい。
悪意あるユーザーが次のことをできるあらゆる方法を挙げて:
  - 本来読んだり変更したりできないはずのデータを読む・変更する(認可の穴)
  - 入力経由でコードを注入する(SQL injection, XSS, command injection)
  - 検証やレート制限の欠如を悪用する
それぞれについて、悪用する正確なリクエストを示し、それから修正を示して。
私を安心させようとしないで——脆弱性は「ある」と仮定して、それを見つけて。

最後の一行が重要だ。中立のままにしておくと、AIは「安全に見えます!」と言いがちだ。欠陥が存在すると仮定するよう指示されると、AIは実際に探しにいく。この敵対的なパスを、ユーザーに触れるものすべてに対して実行する短い出荷前チェックリストと組み合わせよう。

• すべてのエンドポイントが、ユーザーがログイン済みかだけでなく認可をチェックしている
• すべてのデータベースクエリがパラメータ化されている——文字列で組み立てたSQLがない
• ページにレンダリングされるユーザー入力がエスケープされている(生のHTML注入がない)
• クライアントコードにシークレットがなく、リポジトリにコミットされたものもない
• .env がgitignoreされている。漏れたキーはローテーション済み
• ファイルアップロードが型とサイズを検証し、生成した名前を使っている
• 新しい依存関係が、実在と評判について目視確認されている

そしてpushする前にシークレットスキャナを実行すること——gitleaks のようなツール(あるいはあなたのプラットフォームの組み込みスキャン)が、キーのような形をしたものをコードと履歴からgrepする。これはこのリストで最も高くつくミスに対する、ワンコマンドのセーフティネットで、AIにCIへ組み込ませて毎回のpushで走るようにできる。