セキュリティレビューのゲート
ここまでのすべてを「不安」から「プロセス」へと変える、たった1つの習慣がある。出荷する前に、AIに自分のコードを攻撃させることだ。その機能を書いたモデルは、たいていその中の穴を見つけられる——ただ、頼まれない限りそうしないだけだ。AIを「作る側」から「敵対する側」へ反転させよう。
あなたはこのエンドポイントを書いた。今度は、それを破ろうとする攻撃者として振る舞ってほしい。
悪意あるユーザーが次のことをできるあらゆる方法を挙げて:
- 本来読んだり変更したりできないはずのデータを読む・変更する(認可の穴)
- 入力経由でコードを注入する(SQL injection, XSS, command injection)
- 検証やレート制限の欠如を悪用する
それぞれについて、悪用する正確なリクエストを示し、それから修正を示して。
私を安心させようとしないで——脆弱性は「ある」と仮定して、それを見つけて。
最後の一行が重要だ。中立のままにしておくと、AIは「安全に見えます!」と言いがちだ。欠陥が存在すると仮定するよう指示されると、AIは実際に探しにいく。この敵対的なパスを、ユーザーに触れるものすべてに対して実行する短い出荷前チェックリストと組み合わせよう。
- すべてのエンドポイントが、ユーザーがログイン済みかだけでなく認可をチェックしている
- すべてのデータベースクエリがパラメータ化されている——文字列で組み立てたがない
- ページにレンダリングされるユーザー入力がエスケープされている(生のHTML注入がない)
- クライアントコードにシークレットがなく、リポジトリにコミットされたものもない
-
.envがgitignoreされている。漏れたキーはローテーション済み - ファイルアップロードが型とサイズを検証し、生成した名前を使っている
- 新しい依存関係が、実在と評判について目視確認されている
通らなければ何も出荷されないシーケンスとして、このゲートを思い描いてください。AIが作り手から攻撃者へと帽子をかぶり替え、その後、自動スキャンが人間のパスが見逃しうるものを下支えします。
機能コード
│
▼
┌──────────────────┐ "バグがあると仮定して探せ"
│ 敵対的レビュー │ authz穴 · インジェクション · 検証
│ (AI=攻撃者) │
└────────┬─────────┘
│ 問題発見? ── はい ──▶ 修正 ─┐
│ いいえ │
▼ │
┌──────────────────┐ ◀─────────────────── ┘
│ 自動ゲート │ 秘密スキャン(gitleaks) · npm audit
│ (CI, 毎push) │ パラメータ化? · 秘密がクライアントの外?
└────────┬─────────┘
│ 全部緑
▼
SHIP ✓ ── 赤が一つでもpushをブロック ──
そしてpushする前にシークレットスキャナを実行すること——gitleaks のようなツール(あるいはあなたのプラットフォームの組み込みスキャン)が、キーのような形をしたものをコードと履歴からgrepする。これはこのリストで最も高くつくミスに対する、ワンコマンドのセーフティネットで、AIに(コンティニュアス・インテグレーション。コードをpushするたびに、あなたのチェックを自動で走らせてくれるロボットだ)へ組み込ませて毎回のpushで走るようにできる。