Лендинг за «5 минут». Кто отвечает за то, что ИИ установил под капотом?
ИИ сокращает путь от маркетинговой идеи до работающей страницы. Можно поручить агенту подготовить материал, собрать оформление, добавить форму и показать результат. Но приёмка часто заканчивается там, где начинается самый неприятный риск: страница открывается, а код, который обеспечил её работу, никто не проверил.
Я развиваю сайт и блог Андаты вместе с Codex. Мы переехали с Тильды на WordPress ради такого способа работы. И столкнулись с последствиями собственной ошибки: агент установил плагин без проверки безопасности, а позже через плагин мы обнаружили опасный доступ к сайту. После очистки вредоносный код возвращался.
Для меня этот случай изменил требования к выпуску маркетинговых материалов.
Автоматизировать хотелось весь выпуск
Написать текст с ИИ — только одна часть работы. Дальше нужны оформление, изображения, ссылки, поисковые метаданные, проверка с телефона и публикация. После замечаний начинается следующий круг правок.
Мне хотелось ставить задачу один раз и получать вариант, который можно открыть и оценить. Поэтому в выборе CMS стала важна возможность управлять материалами программно.
У Тильды есть API для экспорта и синхронизации готовых страниц. Методов создания и редактирования страниц для нужного нам процесса в документированном перечне нет. WordPress через штатный REST API позволяет создать запись, обновить её содержимое и управлять статусом. Это давало агенту возможность сначала подготовить черновик и показать его мне. Tilda API, WordPress REST API.
Миграцию делали с сохранением существующего сайта: карта адресов, перенос партиями, исходные тексты и ссылки, закрытая проверка. Для маркетинга было важно сохранить накопленные материалы, а затем получить более удобный способ выпускать следующие.
Где потерялся контроль
WordPress дал нам возможность менять код и подключать компоненты. Codex этим пользовался. Вместе с полезными изменениями появился плагин, который до установки не прошёл проверку безопасности.
При расследовании выяснилось, что установщик сверял контрольную сумму архива. Пакет доставлялся без подмены в процессе передачи, но его содержимое до подключения не проверялось. Ещё раньше в списке компонентов были видны подозрительные копии плагинов. Агент увидел их и продолжил публикации.
Так обнаружился разрыв в самой процедуре: собрать сведения не означало принять по ним решение. Предупреждение попадало в отчёт, но следующий шаг оставался прежним.
Затем пришлось искать не только вредоносные файлы, но и механизм их восстановления. Отдельной работой стали посторонние административные доступы и сессии. Полную цепочку первого проникновения восстановить не удалось. Установка без проверки и продолжение работы после подозрительной находки при этом были нашими собственными ошибками.
Codex:Задачу на полезную функцию я превратил в разрешение подключать код без проверки. Это была моя ошибка. Теперь необходимость нового компонента, согласие на него и проверка пакета — отдельные шаги до установки.
Почему это задача маркетинга
Страница может принимать платный трафик, пока команда ещё выясняет, можно ли доверять её содержимому и форме. Приходится отвлекаться от кампаний и контента на проверку сайта. Выигрыш в скорости разработки легко потратить на восстановление.
Поэтому я включаю безопасность в обычную приёмку изменения. Если агент делает форму, нужно проверить обработчик, доступы и внешние запросы. Если предлагает плагин, сначала нужно понять необходимость компонента и проверить точный пакет. Наличие нужной функции остаётся обязательным, но уже не завершает проверку.
Пять требований перед следующим выпуском
- Новый компонент требует отдельного решения. Задача подготовить статью или страницу не даёт агенту права самостоятельно устанавливать плагины. Сначала он объясняет, зачем нужен пакет и почему не хватает существующего механизма.
- Код проверяется до исполнения. Источник, версия, известные уязвимости, состав архива, публичные обработчики, операции с файлами и внешние обращения. Рабочий сайт не подходит для эксперимента с подозрительным компонентом.
- Аномалия останавливает выпуск. Неизвестный администратор или неожиданная копия плагина требуют разбора. Предупреждение в отчёте не заменяет этого действия.
- Тестовая среда проверяется на изоляцию. Два домена могут использовать общие файлы и базу. Нужно понимать эту связь до изменения кода.
- После записи нужен проверяемый результат. Что именно изменилось, работает ли функция, сохранены ли соседние элементы и как вернуть предыдущую версию. При заражении файлы, доступы и фоновые процессы проверяются отдельно.
Обновления безопасности существующих компонентов должны продолжать выходить. Наше ограничение касается самовольной установки и неконтролируемого выпуска, а не отказа от обслуживания сайта.
Из инцидента — в рабочую инструкцию
В Андате мы оформили эти требования в WordPress Security Operator — бесплатный скил для Codex. В нём есть инструкции, пример манифеста и локальный скрипт проверки файлов. Он помогает включить проверки в следующую задачу разработки; плагин на сайт для его использования устанавливать не нужно.
Скрипт не исполняет PHP, не отправляет файлы наружу и не удаляет их. Он отмечает ограниченный набор подозрительных конструкций и изменения контрольных сумм. Такой отчёт помогает разбору, но не является гарантией безопасности.
Разбор проекта и бесплатный скил мы выложили на сайте Андаты. Его можно применять самостоятельно.
Я продолжаю использовать Codex для развития сайта и маркетинга. Теперь в задачу входит не только сделать нужное изменение, но и показать, почему его можно выпускать.