Руководство
Чек-лист безопасности перед выпуском приложения, написанного через vibe coding
Привяжите релиз к просканированному коммиту, проверьте границы доступа и браузерные ассеты, сбои и восстановление, прежде чем выпускать приложение, созданное ИИ.
· 6 мин чтения · Команда vetkit
Прежде чем выпускать приложение, написанное через vibe coding, определите точный коммит релиза, просканируйте его и протестируйте границы доступа, обработку секретов и сценарии сбоев в контролируемом окружении. Используйте находки vetkit как доказательства для проверки наряду с вашими тестами и конфигурацией деплоя. Пройденное сканирование не доказывает, что работающее приложение безопасно или готово к релизу.
Этот чек-лист — для решения о релизе после код-ревью. Для построчного ревью изменений ассистента начните с чек-листа ревью кода, сгенерированного ИИ. Храните описанные ниже доказательства вместе с релизом, чтобы другой человек мог понять, что было проверено.
1. Привяжите доказательства к релизу
- Запишите SHA коммита и артефакт сборки, который планируете задеплоить.
- Убедитесь, что в отчёте аудита указан тот же коммит. Отчёт по более старой вершине ветки не покрывает последующие исправления или сгенерированные файлы.
- Соберите проект и запустите его тесты из этой версии с контролируемой конфигурацией и синтетическими данными. Сохраните фактические результаты команд, включая падения и пропущенные тесты.
2. Проверьте, что на самом деле выполнилось
Security Quick Scan включает posture, обнаружение секретов с помощью gitleaks и проверку зависимостей с помощью OSV. Более широкие аудиты могут включать дополнительные проверки, если это позволяют ваш аккаунт и выбранная область. Шаблон релиза в vetkit выбирает проверки для таких областей, как статический анализ безопасности, инфраструктура, workflow и эксплуатационная готовность, но это не все доступные анализаторы. Например, secrets-history и llm-app не входят в выборку этого шаблона.
| Доказательство | Что проверить перед релизом |
|---|---|
| Завершённый аудит | Читайте результаты анализаторов и предупреждения о частичном отчёте, а не только общий балл. |
| Нет находок | Убедитесь, что нужная проверка выполнилась и поддерживает ваш язык и фреймворк. |
| Находка помечена как исправленная или подавленная | Проверьте исправление или обоснование применительно к этой версии релиза; назначьте ответственного за исключения. |
| Конфигурация на уровне исходного кода выглядит правильной | Отдельно проверьте настройки и поведение целевого деплоя. |
Частичный отчёт означает, что один или несколько анализаторов не завершились и по затронутым категориям находок может быть меньше, чем на самом деле. Прежде чем полагаться на результат, закройте значимые пробелы в покрытии или задокументируйте альтернативную проверку.
3. Проверьте границы доступа на практике
В тестовом окружении создайте два обычных аккаунта и один с повышенными привилегиями. Попробуйте прочитать и изменить записи одного аккаунта от имени другого и вызовите защищённые эндпоинты без входа в систему. Убедитесь, что сервер отклоняет неавторизованные операции, даже если браузерный интерфейс прячет кнопку. Включите в проверку скачивание файлов, экспорт и фоновые операции, использующие те же данные.
Для приложения на Supabase проверьте развёрнутые политики row-level security и storage на синтетических записях. Правила vibe-stack в vetkit могут помечать поддерживаемые паттерны в исходном коде, например отсутствующие или слишком разрешительные политики row-level security и публичные storage-бакеты. Проверка исходного кода не устанавливает текущую конфигурацию вашей размещённой базы данных и не доказывает изоляцию тенантов.
4. Проверьте секреты и браузерные ассеты
Разберите находки по секретам, публичные префиксы переменных окружения и сгенерированные браузерные ассеты. Учётные данные провайдеров и service role храните на сервере. Аудит репозитория не видит секрет деплоя, которого нет в просканированных файлах, и не проверяет автоматически ваш развёрнутый браузерный бандл. Если учётные данные были раскрыты, отзовите или ротируйте их; удалить строку из исходного кода недостаточно. В руководстве об утёкших секретах объясняются отдельные проверки репозитория, истории и браузера.
5. Проверьте зависимости и ИИ-функции
Используйте lock-файл, предназначенный для релиза, и разберите находки по зависимостям. Поиск известных уязвимостей не может установить, что незнакомому пакету можно доверять. Проверьте имена новых пакетов и их происхождение; см. руководство о галлюцинированных пакетах.
Если ваше приложение вызывает LLM, проверьте, что происходит при слишком большом вводе, ошибках провайдера и выводе, который запрашивает привилегированную операцию. Установите лимиты использования на сервере и требуйте авторизации вокруг инструментов, изменяющих данные. Правила llm-app в vetkit находят поддерживаемые паттерны, например вывод модели, выполняемый как команды или SQL, и вызовы по инициативе пользователя без ограничения выходных токенов. Они не доказывают, что любая попытка prompt injection провалится, и не измеряют ваши механизмы контроля расходов в продакшене.
6. Протестируйте сценарии сбоев и восстановление
- Смоделируйте таймаут зависимости и неудачную запись. Убедитесь, что пользователь видит понятное состояние ошибки, а повторная попытка не дублирует операцию незаметно.
- Проверьте команду запуска в продакшене, отчёты о состоянии и отчёты об ошибках. С помощью синтетических сбоев убедитесь, что ответственный оператор может заметить сломанный релиз, при этом учётные данные не попадают в логи.
- Отрепетируйте процедуру отката или восстановления в тестовом окружении. Если релиз меняет хранимые данные, проверьте путь восстановления отдельно: откат кода приложения может не восстановить эти данные.
В vetkit есть статические правила для таких паттернов, как исходящие вызовы без таймаутов, dev-серверы в команде запуска для продакшена и потенциально разрушительная синхронизация схемы. Эти находки могут направить ваше ревью, но аудит не проводит за вас эту репетицию сбоев и не восстанавливает бэкап.
7. Зафиксируйте решение о релизе
Храните вместе коммит, идентификатор сборки, область аудита, результаты тестов и проверки деплоя. Прежде чем выпускать релиз, устраните раскрытые учётные данные и подтверждённый неавторизованный доступ. Для остальных находок запишите доказательства, влияние, ответственного за решение и дату повторной проверки. Если нужный анализатор упал или критичное поведение так и не было протестировано, явно обозначьте этот пробел, а не принимайте молчание за одобрение.
Источники и ограничения
Проверено 1 ноября 2026 года по конфигурации Quick Scan в vetkit, шаблонам аудита, форматировщику отчётов и правилам vibe-stack, llm-app, resilience, data-access и operability. Публичный каталог проверок описывает собственные правила и поддерживаемые ими языки; документация описывает настройку аудита. На покрытие влияют доступность анализаторов, поддерживаемые паттерны, ограничения сканирования и выбранная область.
Описанные здесь ручные проверки — работа для вашей команды, а не утверждение, что vetkit проводит живое тестирование на проникновение, запускает набор тестов вашего приложения или сертифицирует релиз. Аудит исходного кода не может проверить каждое право доступа в продакшене, каждую настройку деплоя или каждое бизнес-требование. Оставляйте эти проверки в процессе релиза, даже если в отчёте нет находок.