Почему ИИ-инструменты оставляют пробелы в безопасности

Почему AI-сгенерированный код отличается безопасностью

AI инструменты кодирования имеют структурные причины для брешей в безопасности, которые они создают. Это не случайные упущения; это предсказуемые результаты обучения и оптимизации.

• Training data skews toward "make it work." Репозитории с открытым исходным кодом и учебные пособия доминируют в обучении LLM. Медианный репозиторий OSS был написан для решения проблемы, а не для того, чтобы служить образцом усиления безопасности. LLM изучает распространение кода в реальных условиях, а не распространение безопасного кода.
• Autocomplete is sticky. Когда вы вставляете фрагмент кода, использующий ключ service_role, он становится шаблоном для следующего файла. Автозаполнение Cursor предложит его в клиентском компоненте, которому оно никогда не принадлежало. Инструмент делает то, для чего он оптимизирован (скорость), но не знает границ безопасности.
• No long-term context or incident memory. Разработчик-человек, который сжег рабочую базу данных с отсутствующим предложением WHERE, переносит этот урок на долгие годы. У LLM нет эпизодической памяти. Каждый файл — это новое начало. Инструмент не изучает ваш последний обход RLS или анализ инцидентов вашей команды.
• Speed is the rewarded metric. Разработчики выбирают эти инструменты, потому что они быстро поставляются. Обратная связь по задержке немедленная и прямая. Обратная связь по безопасности отсутствует или задерживается — уязвимость обнаружена при сканировании FixVibe через три недели после поставки. LLM был оптимизирован для показателей вознаграждения людей в режиме реального времени.
• Implicit trust in platform defaults. Когда Cursor создает приложение Vercel, предполагается, что настройки по умолчанию Vercel усилены. Некоторые из них: auto-HTTPS, подписанные файлы cookie, защита от DDoS. Остальные нет: нет CSP по умолчанию, нет HSTS, разрешающий CORS. Сгенерированный код наследует предположения платформы, которые не всегда оправданы.

Пробел 1: Секреты в клиентских пакетах

Ключи сервисной роли API, токены OAuth и закрытые ключи попадают в пакеты JavaScript, отправляемые в браузер. FixVibe помечает их как выводы Secrets in JavaScript Bundles и Secrets in JavaScript Bundles. Ключи можно обнаружить в исходных картах, минимизированном коде или открытом тексте JS.

Why it happens: Cursor вставка фрагмента Supabase, который инициализирует клиента с ролью службы, означает, что код теперь находится в режиме автозаполнения. Сгенерированный компонент React запрашивает «получить все элементы из базы данных», а Cursor предлагает импортировать сервис-клиент. Граница между серверным и клиентским кодом абстрактна для LLM.

Fix: Храните секреты в переменных среды, отмеченных NEXT_PUBLIC_, только для открытых ключей. Служебные ключи, частные ключи API и секреты подписи должны находиться в src/lib/secrets.ts с import 'server-only'. Используйте действия сервера или маршруты API для вызова конфиденциальных служб, а не клиентских компонентов.

Пробел 2: Отсутствует или неполный уровень безопасности на уровне строк

Таблицы Supabase создаются без включения RLS. Firebase Правила Firestore никогда не записываются или остаются в разрешительном тестовом режиме. Пользователи Anon могут читать и писать каждую строку. FixVibe помечает это как Supabase Row-Level Security и Firebase Security Rules.

Why it happens: RLS — это функция, специфичная для Postgres. LLM, обученные работе с Rails, Django, Laravel и Express, считают проверку аутентификации на уровне приложения нормой. Включение RLS на Supabase требует явных операторов ALTER TABLE и определений политики — шаблоны, менее распространенные в обучающих данных.

Fix: For Supabase, enable RLS with ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; on every table and author policies that scope rows to the authenticated user or organization. For Firebase, never leave rules as default test mode; write explicit rules scoped to the authenticated user.

Пробел 3: путаница в границах аутентификации

Сессии проверяются на стороне клиента с помощью getSession() (который считывает непроверенный файл cookie). Магические ссылки не имеют срока действия. JWTs пропускает проверки aud и exp. Сброс пароля является обратимым. FixVibe помечает их как выводы Auth Flow Defects.

Why it happens: Supabase Auth, Clerk и подобные службы обрабатывают состояние сеанса, но их APIs имеют безопасные и небезопасные режимы. getSession() удобно, но не проверено. LLM видит удобство API чаще, чем безопасность в обучающих данных. Проверка токена на стороне сервера является абстрактной и требует явных заголовков HTTP или вызова промежуточного программного обеспечения.

Fix: Всегда используйте supabase.auth.getUser() на стороне сервера. Никогда не доверяйте getSession() на защищенных маршрутах. Подтверждайте JWTs в каждом запросе, проверяя exp, aud и подпись. Установите срок действия токена на 1 час для токенов доступа и используйте токены обновления для более длительных сеансов.

Пробел 4: Отсутствуют заголовки безопасности HTTP

Нет Content-Security-Policy, нет X-Frame-Options, нет Strict-Transport-Security, нет X-Content-Type-Options. FixVibe отмечает это как вывод HTTP Security Headers.

Why it happens: Заголовки безопасности зависят от платформы развертывания. Cursor генерирует код для Next.js; настройка CSP требует настройки next.config.js, промежуточного программного обеспечения или переопределения vercel.json. Их нет в каркасах проектов по умолчанию. Ментальная модель «заголовки предназначены для DevOps» все еще распространена.

Fix: Установите CSP в next.config.js или промежуточном программном обеспечении с поддержкой nonce: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; .... Добавьте HSTS: Strict-Transport-Security: max-age=31536000; includeSubDomains. Используйте заголовки vercel.json Vercel или промежуточное программное обеспечение для статических хостов.

Недостаток 5: неправильные настройки интеграции со сторонними организациями

Ключи Stripe, токены Sentry, ключи Anthropic API жестко запрограммированы или зафиксированы в репозиториях. Истоки аналитики слишком либеральны. Зависимости npm устарели. Сканирование FixVibe помечает их как находки в Technology Fingerprinting и наших средствах проверки секретов.

Why it happens: Интеграции вставлены из документации и туториалов. LLM копирует шаблон, включая все жестко запрограммированные значения. Дисциплина Env-var требует явной дисциплины в CI/CD, которую LLM не может обеспечить.

Fix: Используйте переменные среды для всех сторонних учетных данных. Храните секреты на своей платформе развертывания (Vercel, Netlify, Heroku или в хранилище). Проверяйте зависимости npm с помощью npm audit ежемесячно. Используйте Dependabot или Renovate для автоматических PR, когда доступны обновления безопасности.

Схема исправления

Закрытие этих пробелов не требует перестройки с нуля. Схема соответствует:

1. Audit: Запустите FixVibe в своем действующем приложении. Для сканирования репозиториев включите приложение FixVibe GitHub. Соберите находки — секреты, RLS, авторизация, заголовки, сторонние.
2. Harden: Fix the high-confidence findings. Enable RLS and add owner-scoped policies. Move secrets to env vars. Set CSP and HSTS in middleware. Use server-side auth validation. Use the coding-agent prompt only where code/config changes apply, and follow operator steps for DNS or provider-owned fixes.
3. Monitor: Запланируйте ежедневное пассивное сканирование или еженедельное активное сканирование проверенного домена. Настройте вебхуки для Slack. Каждое критическое обнаружение должно вызывать тревогу в течение нескольких минут после прибытия корабля.
4. Реагируйте: Когда появляется находка, скопируйте действие по устранению FixVibe, соответствующее ответственному за исправление: промпт coding-агента для работы с кодом/конфигурацией или шаги оператора для DNS, консоли провайдера, ротации секретов и ручной проверки. Запустите повторное сканирование для подтверждения.

Куда движется поле

Устранение этих пробелов — задача сегодняшних команд. В течение следующих 2-3 лет граница сдвинется: лучшие настройки по умолчанию в средах и инструментах (Next.js промежуточное программное обеспечение auto-CSP, Supabase RLS по умолчанию), IDE-time обратная связь по безопасности (Cursor предлагает предупреждения, когда вы собираетесь вставить сервисный ключ в клиентский компонент) и MCP-управляемое автоисправление (ваш агент кодирования имеет доступ к выводам FixVibe и может исправить их автономно). Паблик FixVibe changelog отслеживает, какие пробелы закрываются первыми.

Следующие шаги

Контрольный список go/no-go перед запуском см. в разделе Pre-launch SaaS security checklist. Пошаговое руководство по усилению защиты с фрагментами кода и реальными шаблонами ошибок можно найти в How to secure an app built with AI coding tools.