Как провести read-only аудит сайта с ИИ: безопасная методика проверки

ИИ удобно использовать для первого прохода по коду, конфигурации и журналам, но начинать нужно не с автономных исправлений, а с режима read-only. В нём агент может читать только заранее разрешённые материалы, формулировать гипотезы и предлагать проверки. Менять DNS, сервер, зависимости и права он не может.

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

Шаг 1. Зафиксируйте область и полномочия

Запишите домены, репозитории, окружения и временной интервал. Отдельно перечислите то, чего касаться нельзя: платёжные данные, производственная база, чужие аккаунты, активное сканирование и эксплуатация.

Минимальный бриф:

• цель проверки;
• владелец системы;
• разрешённые файлы и URL;
• запрещённые действия;
• контакт для подтверждения критичного вывода;
• место хранения отчёта;
• срок удаления временных данных.

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

Шаг 2. Подготовьте безопасную копию данных

Для репозитория создайте отдельную копию без файлов окружения, ключей, токенов и пользовательских данных. Для журналов оставьте только необходимый интервал и замените идентификаторы. Список зависимостей и конфигурацию CI передавайте отдельно от секретов.

До подключения модели полезно автоматически найти потенциальные секреты и проверить, что они исключены. Если корпоративная политика не разрешает внешний API, используйте одобренный закрытый контур или локальную модель.

Шаг 3. Начните с инвентаризации

Попросите ИИ не искать «все уязвимости», а сначала построить карту:

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

Проверьте ссылки на файлы вручную. Если модель ссылается на несуществующую строку или выдумывает компонент, остановите этот вывод.

Шаг 4. Проверяйте класс проблем по одному

Разделите аудит на небольшие проходы:

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

Для каждого потенциального дефекта требуйте: условие возникновения, затронутый файл, минимальный безопасный способ подтверждения, возможное влияние и причину, по которой это может быть ложным срабатыванием.

Шаг 5. Оцените приоритет, а не громкость

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

Оцените влияние, вероятность эксплуатации, внешнюю доступность и наличие компенсирующих мер. Калькулятор приоритета делает это локально и не отправляет описание проблемы на сервер.

Шаг 6. Отделите отчёт от исправления

Первый результат — отчёт, а не патч. В нём должны быть:

• краткое описание;
• доказательство с файлом и строкой;
• сценарий риска без вредной инструкции;
• предлагаемая мера;
• тест, который воспроизводит проблему безопасно;
• уровень уверенности;
• владелец решения.

Только подтверждённые пункты переходят во вторую фазу. Для спорных находок нужен профильный специалист.

Шаг 7. Готовьте минимальный патч

Попросите изменить только подтверждённую проблему и добавить регрессионный тест. Запретите попутный рефакторинг. Проверьте diff человеком, запустите тесты и сборку в изолированной среде.

Для DNS, IAM, межсетевого экрана и продакшен-секретов сначала нужен план изменения и отката. Автоматическое применение допустимо лишь для узких, повторяемых действий с отдельным подтверждением.

Шаг 8. Проверьте результат независимо

После патча:

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

Другой ИИ может помочь со вторым мнением, но две модели способны повторить одну ошибку. Критический вывод подтверждает человек.

Шаблон итогового запроса

Работай только с приложенными файлами в режиме read-only. Не выполняй команды и не предлагай активную эксплуатацию. Для каждой находки дай: файл и строку, наблюдение, предпосылки, влияние, безопасную проверку, вероятность ложного срабатывания и минимальное исправление. Если доказательства недостаточны, пометь как гипотезу.

Важно: модель не является источником истины о безопасности. Любая её находка должна быть подтверждена наблюдаемым доказательством, а любое изменение — пройти установленный процесс ревью. Для команды полезно хранить решения и причины отклонённых гипотез: это снижает повторную работу и показывает, какие классы проблем действительно встречаются в системе.

FAQ

Read-only аудит гарантирует безопасность?

Нет. Он снижает риск случайного изменения системы, но данные всё равно могут быть чувствительными, а выводы — ошибочными.

Нужно ли давать агенту доступ ко всему репозиторию?

Не обязательно. Начните с одного сервиса и минимального набора файлов. Расширяйте область только после проверки качества.

Можно ли автоматически принять все патчи?

Нет. Патч должен пройти человеческое ревью, тесты и проверку отката. Для критичных систем нужен установленный процесс изменений.

Чек-лист перед завершением

• область аудита и разрешение зафиксированы;
• секреты и персональные данные исключены;
• каждая находка имеет проверяемое доказательство;
• гипотезы отделены от подтверждённых дефектов;
• приоритет учитывает реальную доступность и влияние;
• патчи минимальны и покрыты тестами;
• есть владелец решения и план отката;
• отчёт не содержит секретов, персональных данных и вредных инструкций.

Проведите контрольный снимок до и после аудита

Перед первым проходом сохраните безопасный снимок состояния: список разрешённых URL, версии зависимостей, заголовки ответа и текущие настройки, которые можно фиксировать без секретов. Не включайте в снимок токены, содержимое баз и реальные персональные данные. После проверки или патча повторите тот же набор наблюдений. Разница между снимками показывает, что действительно изменилось, и помогает не принять побочный эффект за исправление.

Сравнивайте результаты по одной области. Если одновременно обновить заголовки, зависимости и правила доступа, невозможно понять, какой шаг повлиял на проблему. Для каждого изменения запишите ожидаемый эффект и условие отката. Если снимок показывает неожиданное расширение прав, остановите работу и верните последнюю подтверждённую версию, не пытаясь «дочинить» её поверх.

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