Шлюз ревью безопасности

Вот одна привычка, которая превращает всё вышеперечисленное из тревоги в процесс: перед релизом заставьте AI атаковать собственный код. Модель, написавшая функцию, обычно может найти в ней дыры — просто не станет, пока вы не попросите. Переключите её из строителя в противника:

Ты написал этот эндпоинт. Теперь действуй как атакующий, пытающийся его сломать.
Перечисли все способы, которыми зловредный пользователь мог бы:
  - прочитать или изменить данные, к которым не должен иметь доступ (дыры в авторизации)
  - внедрить код через ввод (SQL injection, XSS, command injection)
  - злоупотребить отсутствием валидации или ограничений по частоте запросов
Для каждого покажи точный запрос, который это эксплуатирует, а затем исправление.
Не успокаивай меня — исходи из того, что уязвимость ЕСТЬ, и найди её.

Последняя строка важна: оставленный нейтральным, AI склонен говорить «выглядит безопасно!». Если же сказать ему исходить из того, что изъян существует, он действительно идёт искать. Соедините состязательный прогон с коротким предрелизным чек-листом, который вы прогоняете по всему, что обращено к пользователю:

• Каждый эндпоинт проверяет авторизацию, а не только то, что пользователь залогинен
• Все запросы к базе параметризованы — никакого SQL, собранного из строк
• Пользовательский ввод, выводимый на страницу, экранирован (никакой инъекции сырого HTML)
• Нет секретов в клиентском коде и ни одного закоммиченного в репозиторий
• .env добавлен в gitignore; любой утёкший ключ ротирован
• Загрузки файлов проверяют тип и размер и используют сгенерированные имена
• Новые зависимости осмотрены на реальность существования и репутацию

И запускайте сканер секретов перед push — инструмент вроде gitleaks (или встроенное сканирование вашей платформы) прочёсывает ваш код и историю на предмет того, что по форме похоже на ключи. Это однокомандная страховочная сетка для самой дорогой ошибки из списка, а сам процесс можно поручить AI встроить в CI, чтобы он запускался на каждый push.