Сканирование безопасности кода, сгенерированного ИИ: DAST для vibe-coded приложений

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

Инструменты кодирования AI обучаются в репозиториях с открытым исходным кодом в любом масштабе. Данные обучения смещены в сторону make it work, а не make it secure. Из этого следует несколько структурных закономерностей:

• Autocomplete bias. Выигрывает ближайший соответствующий импорт. Вставка фрагмента Supabase, использующего ключ service_role, в один файл делает этот ключ предложением автозаполнения в следующем — даже в компонентах React на стороне клиента, где он никогда не принадлежал.
• No long-term context. LLM не помнит ни вашего последнего обхода RLS, ни посмертного инцидента вашей команды. Каждый сгенерированный файл является свежим, в нем часто отсутствуют защитные шаблоны, которые люди переносят в файлы.
• Speed as the rewarded metric. Пользователи хвалят скорость; Обучение LLM усиливает это. «Создать самую быструю аутентификацию Next.js» лучше, чем «создать самую безопасную аутентификацию Next.js» по сигналам обратной связи по задержке.
• Training data gaps. Старые кодовые базы доминируют в обучающих данных и предшествуют современным настройкам безопасности по умолчанию (строгие CSP, SameSite=Lax, HSTS, RLS). Сгенерированный код повторяет шаблоны, которые были нормальными в 2019 году, но небезопасными сегодня.
• Implicit platform trust. Когда Cursor создает приложение Vercel, оно предполагает, что настройки Vercel по умолчанию безопасны. Некоторые из них (авто-HTTPS, подписанные файлы cookie). Многие из них этого не делают (по умолчанию нет CSP, разрешающие маршруты CORS, маршруты отладки Next.js по умолчанию).

Десять классов уязвимостей перепредставлены в приложениях с кодом Vibe

При тысячах сканирований приложений, созданных AI-, одни и те же классы поиска обнаруживаются непропорционально:

1. Exposed Supabase service-role keys. service_role JWT (начинается с eyJ), привязанный к клиентскому пакету, обходит все политики RLS в проекте. Cursor автоматически завершает его не на той стороне границы; ключи будут отправлены в /_next/static/....
2. Missing Row-Level Security (RLS). Модель видит CREATE TABLE public.items и продолжает работу без включения RLS. Анонимные пользователи могут затем читать или писать любую строку с помощью открытого анонимного ключа. См. baas.supabase-rls.
3. Open Firebase / Firestore rules. Сгенерированные файлы правил часто читают allow read, write: if true; или полностью пропускают файл правил. Правила тестового режима по умолчанию истекают через 30 дней и блокируют базу данных, но только если разработчик заметил.
4. Hardcoded API keys in bundles. Stripe живые ключи, Anthropic sk-ant-*, OpenAI sk-*, Google AIza* и AWS AKIA* ключи в конечном итоге встраиваются в полезные нагрузки JS, когда дисциплина env-var истекает. secrets.browser-storage отмечает их на уровне отображаемой страницы.
5. Missing Content Security Policy. Отсутствие заголовка ответа Content-Security-Policy означает, что каждый встроенный скрипт XSS находится в одном клике от полного захвата учетной записи. CSP абстрактно; codegen обычно пропускает его. headers.security-headers сообщает о пробелах в руководстве по исправлению для конкретной платформы развертывания.
6. Next.js middleware misplacement. В макете src/ Next.js принимает только src/middleware.ts — middleware.ts корневого уровня молча игнорируется. Аутентификация по-прежнему работает, поскольку страницы вызывают requireAuth(), но заголовки, CSP и ограничения скорости не достигаются.
7. IDOR via unsigned IDs. Сгенерированные обработчики GET /api/items/[id] доверяют параметру пути и никогда не проверяют право собственности. Обход целого числа или пространства UUID открывает доступ к данным каждого арендатора.
8. Broken auth flows. токены Magic-link без expires_at; проверка JWT, пропускающая aud и exp; вызовы getSession() на стороне клиента (которые считывают непроверенный файл cookie) вместо getUser() на стороне сервера.
9. Debug endpoints in production. Созданные /api/debug, /api/health, /api/__nextjs_original-stack-frame или /.next/trace маршруты утечки внутренних данных. discovery.platform-vercel проверяет их с помощью проверки содержимого, чтобы избежать ложных срабатываний на резервных версиях SPA.
10. Plaintext sensitive fields. Пароли, API ключи и PII хранятся в Postgres в виде обычного текста, поскольку миграция не затронула pgcrypto или внешнее хранилище.

DAST против SAST: почему оба значения важны для AI-сгенерированного кода

Статический анализ (SAST) и динамический анализ (DAST) дополняют, а не заменяют друг друга. Разделение имеет большее значение для кода, сгенерированного AI-, чем для кода, написанного вручную.

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

DAST обращается к развернутому приложению как пользователь. Он видит отправленные ответы, работает с производственным пакетом и фиксирует смещение конфигурации между репозиторием и развертыванием. Он находит жестко закодированные ключи в транспилированном JavaScript, которые SAST никогда не видел, поскольку они были введены через назначение process.env во время сборки.

For AI-generated code, DAST is essential потому что то, что кораблик, отличается от того, что написала модель. Объединение, встряхивание деревьев, транспиляция и встраивание переменных среды — все это создает новые поверхности. SAST в исходном коде может полностью пропустить встроенные в пакет секреты. DAST улавливает оба слоя. Зрелый конвейер запускает SAST в CI и DAST на основе развернутой предварительной версии — это шаблон FixVibe.

Что искать в сканере кода AI-code

Большинство сканеров DAST общего назначения (Burp Suite, OWASP ZAP, Nessus) были разработаны для монолитных приложений и традиционных потоков аутентификации. Для сканирования сгенерированного приложения Vercel + Supabase + Stripe AI- необходимо:

• BaaS coverage. Реальные проверки на соответствие Supabase RLS, Firebase / правилам Firestore, конфигурации Clerk, AWS Amplify и JWT, формирующим эти службы. Общие правила OWASP не знают, что помечать.
• JS bundle inspection. Настроенное регулярное выражение для API-форматов ключей, подписанных токенов и шаблонов, специфичных для поставщика (Stripe sk_live_, Anthropic sk-ant-, Supabase JWTs, начиная с eyJ). Общие энтропийные эвристики выдают слишком много ложных срабатываний.
• Passive + active split. Пассивные проверки (заголовки, файлы cookie, секреты, конфигурация BaaS, DNS) безопасно выполняются относительно любого URL. Активным зондам (SQLi, XSS, SSTI, IDOR ходьбы) требуется граница авторизации, поскольку они запускают полезные нагрузки в стиле атаки.
• Framework awareness. Распознавание Next.js App Router и Pages Router, перезапись Vite SPA, Vercel защита развертывания, Cloudflare маршрутизация страниц. Сканер, который не отличает резервный вариант SPA Vite от настоящего /_next/build-manifest.json, генерирует шум.
• Rate-limit safety. Ограниченные бюджеты запросов на одно сканирование, сравнение базовых показателей и ответов во избежание WAF-путанных ложных срабатываний, рандомизированные базовые показатели проверки пути для обнаружения развертываний Blanket-403.
• Authorization gating for intrusive payloads. Отправка полезных данных SQLi или OS-command в домен, которым вы не владеете, является незаконной в большинстве юрисдикций. Настоящий сканер требует DNS или HTTP- подтверждения владения файлом, прежде чем разрешить запуск активного режима для цели.

Подход FixVibe: доказательное сканирование, низкая ложноположительная нагрузка

FixVibe is a DAST built specifically for AI-generated web apps. The passive phase runs 200+ checks on the rendered page (headers, CSP, cookies, leaked secrets, BaaS misconfiguration, tech fingerprinting, DNS, attack-surface discovery). The active phase adds payload-firing probes (SQLi, XSS, SSTI, CORS, redirects, IDOR walking, CSRF, account enumeration, blind-SSRF) gated behind verified-domain ownership. Repo scans add code-phase checks against connected GitHub repositories. Every finding includes evidence, a CWE link, a remediation recipe, and either a coding-agent prompt or operator steps depending on who can actually apply the fix. The scan engine is open in the changelog — every new check, accuracy improvement, and false-positive fix is logged publicly.

FixVibe против Burp Suite, ZAP и Nessus: когда выигрывает каждый инструмент

Ни один инструмент не охватывает каждый рабочий процесс. Честная формулировка того, куда подходит FixVibe:

Где инструменты дополняют друг друга

• Start with FixVibe passive в качестве бесплатного 30-секундного базового показателя по сравнению с любой предварительной версией развертывания. Если ничего не появляется, у вас есть быстрый сигнал уверенности.
• Move to FixVibe active на проверенном домене, если вам нужно полное активное покрытие (SQLi/SSTI/IDOR/etc.) вашей собственной инфраструктуры.
• Layer SAST (Semgrep, CodeQL, Snyk) в исходном коде CI. SAST улавливает то, что не видит среда выполнения — рискованные шаблоны в путях кода, которые никогда не достигают развертывания.
• Reach for Burp Suite, когда вам нужны специальные цепочки атак (специфические обходы аутентификации, сложные сценарии IDOR, недостатки бизнес-логики). Burp — самый глубокий из доступных ручных инструментов; FixVibe — это самая быстрая автоматизированная базовая линия.

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

Continue с Vibe coding security checklist для проверки перед отправкой из 44 элементов или перейдите к How to secure an app built with AI coding tools для пошагового усиления безопасности с помощью фрагментов кода.