В последние пару лет мы научились отдавать нейросетям почти весь цикл разработки. AI пишет компоненты, API, тесты, Dockerfile, конфиги nginx, миграции базы данных и даже помогает настроить CI/CD.

Но есть один вопрос, который при таком подходе становится только важнее:

а кто проверяет безопасность всего того, что AI написал?

Особенно если речь идёт о вайбкодинге, когда разработчик ставит сборку сайтов практически на конвейер:

задача → AI → код → тесты → deploy.

На мой взгляд, в этой цепочке давно пора добавить ещё один шаг:

lint → tests → build → security checks → AI security review → deploy

Почему именно AI аудит безопасности?

Потому что он стоит дёшево, выполняется быстро и способен заметить класс ошибок, которые разработчик легко пропускает просто потому, что проект работает (либо потому, что разработчик не знает, что в этом месте должны быть ошибки).

И хороший свежий пример этого подхода показал президент OpenAI Грег Брокман.

Предыстория

В августе 2026 года Брокман рассказал, что попросил ChatGPT Work проверить безопасность своего личного сайта gregbrockman.com. Это простой статический сайт, размещённый в AWS с Cloudflare перед ним.

Это не интернет-банк и не система с миллионами пользователей. Тем не менее примерно за 15 минут ChatGPT обнаружил 13 проблем. Среди них Брокман отдельно упомянул:

• DNS-конфигурацию, которая недостаточно защищала от подделки писем от его имени;
• небезопасную версию jQuery;
• соединение от Cloudflare до AWS-origin по незашифрованному HTTP.

После этого Брокман попросил ChatGPT Work помочь исправить найденное. По его словам, примерно за час AI настроил DNS и TLS через панель Cloudflare, удалил jQuery, помог перенести сайт с AWS на Cloudflare Pages и начал поэтапную настройку DMARC.

Но лично мне в этой истории больше всего понравилась другая деталь.

Брокман отметил, что многие найденные проблемы сами по себе, вероятно, не представляли критической опасности.

Настоящий риск появляется тогда, когда злоумышленник может объединить несколько небольших слабостей в одну цепочку атаки.

И вот именно здесь AI может быть особенно полезен.

AI-аудит безопасности не заменяет реальный аудит безопасности

Сразу проговорим важное. Если ChatGPT написал, что «Уязвимостей не обнаружено», это не означает, что сайт безопасен.

AI security review не заменяет:

• профессиональный pentest;
• SAST;
• dependency scanning;
• npm audit;
• Dependabot;
• Snyk;
• DAST;
• ручное code review;
• security review инфраструктуры.

Особенно если вы разрабатываете нечто большее, нежели простую посадочную страницу. Чем сложнее проект - тем более важным является даже минимальный аудит безопасности. Таким образом, даже для обычного сайта или веб-приложения AI аудит безопасности может стать ещё одним дешёвым уровнем защиты.

Примерно как линтер.

ESLint не гарантирует, что приложение работает правильно, но это не повод его отключать. И то же самое с безопасностью: AI аудит вовсе не гарантирует безопасность системы, но если десятиминутная проверка найдет дыру до production, она уже окупилась.

Что именно я бы давал AI проверять, по шагам

1. API endpoints

Если в проекте есть backend, я бы начал именно отсюда. AI можно попросить составить карту всех endpoint'ов:

METHOD
PATH
AUTH REQUIRED
ROLE
INPUT
OUTPUT
SIDE EFFECTS

После этого проверить:

• какие endpoint'ы доступны без авторизации;
• какие позволяют изменять данные;
• где ID ресурса приходит от клиента;
• проверяется ли владелец ресурса;
• существуют ли admin/debug endpoint'ы;
• нет ли потенциального IDOR.

Например

Представим запрос:

DELETE /api/posts/123

Проверить, что пользователь залогинен, недостаточно.

Нужно проверить:

имеет ли этот конкретный пользователь право и возможность удалить именно post с id 123?

Плохая логика:

if (!user) {
  throw new UnauthorizedException();
}

deletePost(id);

Лучше:

const post = await getPost(id);

if (post.authorId !== user.id) {
  throw new ForbiddenException();
}

Пример промта

Проанализируй API проекта как security reviewer. Составь список endpoint'ов и найди места, где пользователь потенциально может получить, изменить или удалить данные другого пользователя. Особое внимание удели IDOR и отсутствующим permission checks. Пока ничего не исправляй — сначала составь список рисков, severity и возможный сценарий эксплуатации каждого.

---

2. Authentication flow

После endpoint'ов я бы отдельно попросил разобрать всю систему аутентификации. Не один файл, а именно flow:

login → session/token → refresh → protected request → logout

Например, если есть восстановление пароля:

request reset → reset token → password change → token invalidation

Попросите AI ответить:

• где хранятся access tokens;
• где хранится refresh token;
• какой у них TTL;
• можно ли повторно использовать refresh token;
• происходит ли rotation;
• инвалидируются ли токены после logout;
• инвалидируются ли существующие сессии после смены пароля;
• можно ли подобрать reset token;
• раскрывает ли API существование пользователя.

Пример промта

Нарисуй authentication flow этого проекта от момента ввода логина и пароля до logout. Покажи, где создаются, хранятся, обновляются и инвалидируются токены или sessions. После этого перечисли возможные security risks.

И здесь есть ещё одна польза, порой AI объяснит как работает ваш проект лучше любого ментора.

3. Authorization и permissions

Это стоит проверять отдельно от authentication.

Authentication отвечает:

Кто ты?

Authorization:

Что тебе разрешено?

И многие проекты отлично отвечают на первый вопрос и довольно плохо - на второй.

Я бы попросил AI построить матрицу:

Role	Resource	Read	Create	Update	Delete
guest	post	✓	✗	✗	✗
user	own post	✓	✓	✓	✓
user	чужой post	✓	✗	✗	✗
admin	any post	✓	✓	✓	✓

А затем пройтись по коду и убедиться, что реализация действительно соответствует таблице.

Особенно внимательно:

• админка;
• платежи;
• заказы;
• файлы;
• профили;
• корпоративные сущности;
• управление пользователями.

---

4. Cookies и HTTP headers

Очень скучная часть, потому что её легко забыть проверить.

Многие ограничиваются лишь проверкой галочки сайта и зеленым HTTPS, но этого мало.

Я бы попросил AI проверить как минимум:

Content-Security-Policy
Strict-Transport-Security
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
CORS

И настройки cookies:

Secure
HttpOnly
SameSite
Path
Domain
Expires / Max-Age

Например:

Set-Cookie: session=...

и

Set-Cookie: session=...; HttpOnly; Secure; SameSite=Lax

- это довольно разные истории с точки зрения безопасности.

Кейс Брокмана как раз показывает, почему этот слой легко пропустить: одна из найденных проблем вообще находилась между Cloudflare и origin-сервером, а не внутри JavaScript-приложения.

5. Forms и пользовательский ввод

Один из моих любимых вопросов при security review:

Где пользователь может заставить систему обработать данные, которые придумал пользователь?

Ответ обычно:

почти везде.

Это:

• регистрация;
• login;
• поиск;
• комментарии;
• формы обратной связи;
• профиль;
• URL parameters;
• JSON body;
• query parameters;
• headers.

Просим AI искать:

• XSS;
• injection;
• отсутствие серверной валидации;
• неправильную sanitization;
• слишком подробные error messages;
• отсутствие rate limiting.

И очень полезно явно добавить:

Не рассматривай frontend validation как security boundary.

Потому что:

<input maxlength="100">

защищает ваш backend примерно до момента:

curl

или Postman.

Валидация критических данных должна происходить на сервере.

6. File upload

Если на сайте предусмотрена работа с файлами, я бы вынес это в отдельный аудит.

Проверить:

• MIME type;
• extension;
• размер;
• оригинальное имя файла;
• генерируется ли безопасное новое имя;
• путь сохранения;
• доступность файла;
• возможность исполнения;
• можно ли загрузить HTML/SVG;
• можно ли перезаписать существующий файл;
• можно ли использовать ../ и изменить путь.

Например:

avatar.png

выглядит спокойно.

А файл:

../../config.js

уже намекает, что вечер может стать длиннее запланированного.

7. Secrets

После активного AI-assisted coding этот пункт я бы вообще сделал обязательным.

Попроси AI поискать:

• API keys;
• access tokens;
• private keys;
• database credentials;
• .env;
• secrets в исходниках;
• secrets в client bundle;
• credentials в config;
• чувствительные значения в логах.

Особенно на frontend, потому что AI спокойно может создать нечто вроде:

const OPENAI_API_KEY = "sk-...";

в клиентском приложении и радостно сообщает:

Всё готово 🚀

И правда, готово, особенно когда секреты можно будет вытащить через devtools.

Важный момент

Нельзя просто сказать AI:

«Найди секреты».

Лучше попросить:

Составь список всех внешних сервисов, используемых проектом, определи, какие credentials требуются каждому сервису, а затем проверь, где именно эти credentials хранятся и могут ли они попасть в клиентский bundle, Git repository или logs.

Так проверка становится намного системнее.

8. Dependencies

Вот здесь многие вообще не думают о security, а зря. Современное веб-приложение может содержать сотни или тысячи transitive dependencies, и случаев взлома проектов через npm пакеты уже немало.

Поэтому стоит проверить:

• устаревшие пакеты;
• известные CVE;
• deprecated dependencies;
• подозрительно новые или малоизвестные пакеты;
• библиотеки с широкими возможностями;
• пакеты, которые больше не используются.

Для Node.js можно запустить команду:

npm audit

а ИИшка здесь будет полезна как дополнительный аналитик.

Например:

Вот результаты npm audit. Разбери каждую уязвимость: используется ли реально уязвимый код в нашем проекте, насколько реалистична эксплуатация и какой вариант исправления минимально рискованный.

9. Infrastructure

Вот этот пункт особенно хорошо демонстрирует история Брокмана. Код может быть нормальным, а инфраструктура нет.

Я бы просил проверить:

• HTTPS;
• TLS;
• DNS;
• CDN;
• origin;
• firewall;
• открытые порты;
• storage permissions;
• публичные buckets;
• database exposure;
• deployment secrets;
• CORS;
• environments.

Особенно популярная ошибка:

Browser → HTTPS → Cloudflare → HTTP → Origin

Пользователь видит замочек, а внутри инфраструктуры часть соединения остается незашифрованной. Именно такую ошибку AI обнаружил на сайте Брокмана.

10. Rate limits и abuse

Ещё одна вещь, которая прекрасно работает на тестовом стенде:

POST /api/reset-password

Работает? Работает.

А что произойдёт, если вызвать его 10 000 раз?

Стоит проверить:

• login;
• password reset;
• регистрация;
• email/SMS;
• expensive API calls;
• AI endpoints;
• upload;
• search.

Особенно AI endpoints. Если запрос к вашей модели стоит деньги, отсутствие rate limit превращается уже не только в security-проблему, но и в финансовую.

---

Как попросить AI провести полноценный review

Огромный запрос тут будет плохим решением. Я бы делал итерациями. Ниже - пример метапромта.

Этап 1. Построить модель системы

Сначала не ищи уязвимости. Изучи проект и опиши его архитектуру с точки зрения безопасности: frontend, backend, база данных, authentication, внешние API, файловое хранилище, инфраструктура и границы доверия. Отдельно перечисли все места, где в систему попадают данные пользователя. Это создаёт foundation для дальнейшего анализа.

Этап 2. Найти потенциальные проблемы

Теперь выступи как security reviewer. Для каждого компонента найди потенциальные проблемы безопасности. Для каждой проблемы укажи:

Пока не исправляй код.

Важно: не стоит исправлять сразу, потому что если ИИ будет одновременно искать проблему, предлагать решение и менять код, можно не понять, что он вообще нашел. Иными словами, сначала review, потом fix.

Этап 3. Проверить цепочки атак

Пример промта:

Представь, что ты атакующий, но не выполняй никаких разрушительных действий. Используя только найденные выше слабости, построй пять наиболее реалистичных attack chains. Для каждой укажи:

1. точку входа;
2. необходимые условия;
3. последовательность шагов;
4. возможный ущерб;
5. способы разорвать цепочку.

Вот этот этап особенно ценен. Потому что настоящая атака редко выглядит как "нажал кнопку и захватил сервер".

Чаще комбинация факторов:

• information leak
• weak permissions
• bad configuration
• exposed endpoint

создает одну большую головную боль.

Именно на возможность объединения небольших слабостей в цепочку обращал внимание Брокман.

После исправлений нужен второй аудит

Допустим, AI нашёл восемь проблем и вы попросили их исправить. Но на этом процесс заканчиваться не должен, потому что:

Любое исправление = это изменение системы. А любое изменение потенциально создаёт новую ошибку.

Особенно после изменений в:

• auth;
• permissions;
• dependencies;
• CORS;
• middleware;
• infrastructure.

Обязательно смотрим diff

После выполнения работ, я бы делал

git diff

И задавал себе вопросы:

• почему изменён этот файл?
• зачем добавилась эта dependency?
• почему изменился middleware?
• почему ослабился CORS?
• действительно ли нужен новый permission?
• почему удалился старый security check?

Особенно когда AI пытается "упростить" странный код.

Иногда код выглядит странно именно потому, что когда-то закрывал реальную уязвимость.

Минимальный pipeline перед релизом

Для обычного веб-проекта мой условный минимум сейчас выглядел бы примерно так:

lint
↓
unit / integration tests
↓
build
↓
dependency scan
↓
secrets scan
↓
AI security review
↓
manual diff review
↓
deploy
↓
post-deploy smoke test

Для более серьёзного проекта сверху добавляем полноценные security tools и профессиональный аудит.

---

Что AI нельзя давать делать бездумно

Есть обратная сторона.

Security-agent потенциально получает очень широкие права:

• читать весь repository;
• читать .env;
• выполнять shell commands;
• открывать Cloudflare/AWS;
• изменять DNS;
• работать с production.

То есть инструмент, который защищает систему, одновременно получает возможность её очень эффективно сломать.

Поэтому при возможности:

• используйте sandbox;
• ограничивайте permissions;
• не отдавайте production credentials без необходимости;
• подтверждайте опасные действия;
• делайте backup;
• работайте через Git;
• сохраняйте возможность rollback.

---

Так заменит ли AI специалиста по безопасности?

Нет.

И, на мой взгляд, это вообще неправильный вопрос. AI уже не обязан кого-то "заменять", чтобы быть полезным.

Если он:

• за 15 минут найдёт устаревший пакет;
• напомнит про HTTP header;
• заметит отсутствие permission check;
• найдёт API key во frontend;
• покажет слабую CORS-конфигурацию;

он уже сделал проект безопаснее.

Профессиональный security engineer сможет найти намного более сложные вещи. Но профессионального security engineer обычно не вызывают проверять каждый лендинг или маленький pet-project, а ИИшку - можно, и это обойдется дешевле.

---

Главный вывод

Кейс Грега Брокмана показателен не потому, что:

«ChatGPT нашёл 13 дыр».

Интереснее другое.

Даже маленький статический сайт, который кажется практически лишённым поверхности атаки, всё равно состоит из:

• DNS;
• TLS;
• CDN;
• dependencies;
• hosting;
• email configuration;
• браузерного кода.

И слабость может находиться в любом из этих слоёв.

Поэтому я бы воспринимал AI security review не как замену аудита и не как какую-то гарантию. Это лишь дополнительный вопрос перед релизом:

«Вот мой проект. Попробуй доказать, что я что-нибудь забыл».

Если AI ничего не найдёт - отлично. Если найдёт хотя бы одну реальную проблему до production - десять минут проверки уже окупились.

А если вы собираете сайты через AI практически на конвейере, я бы вообще сделал такой review частью стандартного Definition of Done.

Потому что вайбкодить можно быстро, а разгребать взломанный production обычно получается гораздо медленнее.

---

Материал основан в том числе на публикации Грега Брокмана «The Defender’s Window» от 17 августа 2026 года, где он описал эксперимент с аудитом собственного сайта через ChatGPT Work.