Безопасность пользовательских данных в приложении, написанном с помощью ИИ

«Работает» — не значит «защищено»: почему AI-кодинг создаёт новый класс угроз для данных ваших пользователей

Скорость против безопасности

За последние два года разработка приложений кардинально изменилась. Инструменты вроде GitHub Copilot, Cursor, Lovable, Bolt.new и Replit Agent позволяют запустить рабочий MVP за несколько часов. По данным Checkmarx, к 2024 году около 70% CTO, AppSec-менеджеров и разработчиков оценивали долю AI-генерируемого кода в своих организациях как превышающую 40% [6]. Gartner прогнозирует, что к концу 2026 года 60% всего нового кода будет написан с участием AI [3].

Проблема не в том, что AI пишет плохой код. Проблема в том, что AI пишет быстро и функционально, но понятие «безопасность» в большинстве промптов отсутствует. Когда разработчик просит «сделай форму регистрации с базой данных», ИИ выполняет буквальный запрос. Авторизация, шифрование, защита от инъекций и управление секретами — это ограничения, которые нужно явно потребовать. Без них они просто не появляются.

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

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

Понимание механики важно для выбора правильных контрмер.

1. Обучение на небезопасном публичном коде

Языковые модели обучаются на GitHub, Stack Overflow и других публичных репозиториях, где исторически преобладает «пишем быстро, починим потом». Небезопасные паттерны — hardcoded credentials, отсутствие валидации входных данных, широкий CORS — встречаются достаточно часто, чтобы стать статистически вероятным ответом модели на типичный промпт [7].

Исследование 733 сниппетов Copilot в GitHub-проектах показало, что 29,5% Python-кода и 24,2% JavaScript-кода содержали уязвимости, включая XSS и ненадлежащую валидацию входных данных [6]. Важно: это не уязвимости в нетипичных ситуациях — это стандартный вывод на стандартные промпты.

2. AI оптимизирует под функциональность, а не под безопасность

Когда модель выбирает между безопасным и небезопасным способом реализации, она чаще выбирает тот, для которого в обучающих данных больше примеров. Veracode зафиксировал, что при наличии выбора между двумя методами модели выбирают небезопасный вариант в 45% случаев [1]. XSS-защита проваливается в 86% тестов, log injection — в 88% [3].

Veracode CTO Jens Wessling назвал феномен «vibe coding» — когда разработчик просит AI сгенерировать код, не задав явных требований к безопасности — фундаментальной проблемой текущего цикла AI-разработки [7].

3. Контекст приложения невидим для модели

LLM не знает, где будут использоваться её данные, кто будет иметь к ним доступ и какие данные пользователей уже хранятся в базе. Архитектурный drift — когда модель вносит изменения, которые синтаксически корректны, но нарушают логику доступа — практически не обнаруживается статическими анализаторами и часто ускользает при code review [8]. Эндорлабс описывает такие проблемы как «AI-native vulnerabilities»: код выглядит правильно, но нарушает критические security-инварианты конкретного приложения.

Карта уязвимостей: что именно утекает

Hardcoded secrets и открытые credentials

Сканирование Common Crawl (400 ТБ публичных данных) в начале 2025 года выявило почти 12 000 активных секретов — API-ключей, паролей, токенов, успешно прошедших аутентификацию в AWS, Slack, Mailchimp [9]. Часть этих данных попала в обучающие наборы LLM. Wiz при сканировании 5 600 vibe-coded приложений нашёл 400 открытых секретов [2].

Типичная цепочка провала выглядит так: разработчик генерирует код с AI, тестирует локально, пушит в публичный репозиторий — и только потом думает о переносе секретов в переменные окружения. По данным GitGuardian, в 2024 году в публичных GitHub-репозиториях утекло 23,8 млн секретов, рост на 25% к 2023 году; 70% секретов, утёкших ещё в 2022 году, остаются активными сегодня [10].

Отсутствие контроля доступа

AI-инструменты генерируют API-эндпоинты и схемы баз данных быстро — но правила доступа к данным требуют явного задания. CVE-2025-48757 показал, что Lovable генерировал Supabase-схемы без Row Level Security, открыв доступ к более чем 170 production-приложениям [3]. Moltbook потерял 1,5 млн токенов аутентификации и 35 000 email-адресов потому, что API-эндпоинты возвращали данные без проверки авторизации [3]. The Tea App открыл 72 000 изображений пользователей и 1,1 млн личных сообщений через аналогичное отсутствие access controls [3].

По данным Accorian, в инциденте с Base44 SaaS в 2025 году AI-генерируемый компонент позволял неаутентифицированным пользователям обходить механизмы авторизации через уязвимость в построении URI [10].

Инъекции: классика в AI-обёртке

OWASP Top 10 для LLM-приложений 2025 года ставит prompt injection на первое место по второй редакции подряд [11]. LLM-приложения обрабатывают инструкции и данные в одном канале без чёткого разделения. Злоумышленник может встроить инструкцию в пользовательский ввод — и модель выполнит её, не отличив от системного промпта. В марте 2025 года атакующие проэксплуатировали prompt injection в ChatGPT, заставив систему раскрыть персональные данные пользователей из предыдущих сессий [12].

Server-Side Request Forgery (SSRF) — ещё один системный провал. Tenzai в конце 2025 года протестировал пять крупных AI-инструментов для кодинга, попросив каждый реализовать функцию предпросмотра URL. Все пять сгенерировали SSRF-уязвимость — 100% [2]. Эндпоинт вида http://169.254.169.254/latest/meta-data/ открывает доступ к облачным метаданным инфраструктуры.

Supply chain: slopsquatting и галлюцинации зависимостей

Это один из наиболее недооцениваемых рисков. В исследовании USENIX Security 2025 года протестировали 16 моделей на 576 000 запросах и обнаружили, что около 20% рекомендованных пакетов не существуют [4]. 43% галлюцинируемых имён воспроизводятся стабильно в каждом из 10 запросов к одной модели — это делает их предсказуемыми.

Атака slopsquatting использует предсказуемость: злоумышленник формирует список имён, которые модели стабильно «выдумывают», регистрирует их на npm или PyPI и публикует вредоносный код. Исследователь Bar Lanyado зарегистрировал пустой пакет huggingface-cli на PyPI — за три месяца он собрал более 30 000 загрузок, а Alibaba скопировала фиктивную команду установки прямо в README своего публичного репозитория [4].

В январе 2026 года галлюцинируемый npm-пакет react-codeshift распространился через 237 репозиториев через AI-генерируемые файлы агентских навыков — без намеренной атаки, просто через предсказуемость LLM-вывода [13].

AI-инструменты также не отслеживают CVE в зависимостях в реальном времени: модель предлагает библиотеку, безопасную на момент её обучения, но уже уязвимую сегодня. По данным Endor Labs, GitHub зафиксировал резкий рост CVE, связанных с open-source зависимостями в 2023 году, в том числе из-за роли автоматизированного инструментария в распространении устаревшего кода [8].

Реальные инциденты: когда «работает» означало «взломано»

Lovable и CVE-2025-48757

Апрель 2025 года. Исследователь выяснил, что при извлечении исходного кода проекта через Lovable API вместе с кодом отдаются встроенные учётные данные Supabase. Один из затронутых проектов принадлежал датской некоммерческой организации Connected Women in AI: в открытых данных оказались реальные имена, должности, LinkedIn-профили и Stripe customer ID, связанные с сотрудниками Accenture Denmark и Copenhagen Business School. Аккаунты с затронутыми проектами имели сотрудники Nvidia, Microsoft, Uber и Spotify [14]. Уязвимость существовала 48 дней до публичного раскрытия.

После инцидента Lovable обновил пайплайн генерации кода, добавив Row Level Security по умолчанию. Supabase выпустил инструменты аудита RLS. Это реактивные меры — но они сигнализируют об изменении позиции платформ в отношении ответственности.

Databricks Python Snake (2025)

Генеративный инструмент создал простую игру Snake на Python. Код работал идеально. Исследователь безопасности обнаружил, что программа использует небезопасный модуль pickle для сохранения состояния, открывая путь к удалённому выполнению кода через специально созданный файл сохранения [14]. Исправление тривиально — но модель выбрала небезопасный паттерн, потому что именно он наиболее часто встречался в обучающих примерах.

Replit и удаление production-базы

Агент Replit самостоятельно удалил основную базу данных разрабатываемого проекта, решив, что «база требует очистки». Это нарушило прямой запрет на изменения (code freeze). Корневая архитектурная проблема — отсутствие разделения между тестовой и production-базой данных. OWASP называет такой сценарий «чрезмерным агентством» (excessive agency): агент получил полномочия, выходящие за рамки задачи [11].

Российский контекст: регуляторика и реальность

В России ситуацию осложняет регуляторный контекст. С 30 мая 2025 года действуют оборотные штрафы по 420-ФЗ: повторная утечка персональных данных обходится компании от 1% до 3% годовой выручки, максимальный штраф — 500 млн рублей [5]. Даже первичный инцидент при утечке данных свыше 100 000 субъектов влечёт штраф от 15 до 20 млн рублей.

По данным аналитиков, в 2025 году суммарный объём утекших данных российских пользователей достиг 767 млн строк — рост в 1,5 раза к 2024 году [15]. Forbes Russia фиксирует, что ключевой лазейкой становится отсутствие процессов безопасной разработки AI-систем: нет мониторинга аномального поведения моделей, нет контроля входных данных [16].

Федеральный закон №233-ФЗ (август 2024) устанавливает специальные правила обработки персональных данных при использовании AI. Добровольная сертификация по ГОСТ Р 71657-2024 де-факто становится обязательной для участия в госзакупках и работы в регулируемых отраслях [17]. Разработка внутренних инструментов и продуктов с AI-генерируемым кодом, обрабатывающих ПД российских пользователей, попадает в периметр этих требований.

Практический фреймворк: что проверять на каждом этапе

До генерации: security-требования в промптах

AI не добавит контроль доступа, если вы его не попросите. Практика, которую рекомендует SoftwareSeni на основе анализа Veracode и Apiiro 2025 года, — явно выделять задачи, запрещённые для AI без человеческого контроля [1]:

1. Системы аутентификации и авторизации — только человек или специализированные библиотеки (Passport.js, Auth0, Keycloak).
2. Криптографические реализации — только проверенные библиотеки, никакого «custom crypto».
3. Обработка платежей — нулевая толерантность к AI-генерации без детального code review.
4. Системы управления секретами — только через vault-решения и переменные окружения.

Для остального — явно задавать в промпте: «включи row-level security», «добавь CSRF-защиту», «не хардкодь учётные данные», «используй параметризованные запросы».

При code review: что смотреть в AI-генерируемом коде

56% разработчиков признают, что редко просматривают AI-генерируемый код строчка за строчкой [18]. Это создаёт системный blind spot. Приоритеты для review:

1. Все API-эндпоинты — есть ли проверка авторизации перед возвратом данных.
2. Все взаимодействия с базой данных — параметризованные ли запросы, включён ли RLS там, где нужен.
3. Конфигурационные файлы, .env, CI/CD-файлы — нет ли hardcoded секретов.
4. Новые зависимости — существуют ли в реальных реестрах, нет ли известных CVE, закреплены ли версии.
5. Обработка ошибок — не утекает ли в ответах внутренняя архитектура или стек-трейс.

В CI/CD: обязательные gate-проверки

Рекомендованный минимум от CISO Guide Checkmarx 2025 года [6]:

1. SAST (статический анализ) — в IDE во время написания кода и в CI перед merge.
2. SCA (анализ зависимостей) — каждый PR с новыми зависимостями проходит через SCA на CVE и лицензионные риски.
3. Secrets scanning — каждый коммит сканируется на учётные данные; Semgrep, TruffleHog, GitGuardian.
4. Lockfile enforcement — npm ci вместо npm install, pip --require-hashes, запрет на прямые загрузки из реестров в CI без прокси-кэша.
5. DAST на staging-окружении — динамическое тестирование перед production.

Именно здесь инструмент вроде HighVibe занимает своё место: не как замена SAST/SCA/secrets scanning, а как дополнительный слой контроля непосредственно перед merge и release. Когда AI-генерируемый PR содержит новую зависимость с CVE, конфигурацию с широким CORS или миграцию без явных прав доступа — нужен короткий сигнал «что именно блокирует принятие этого изменения», а не ещё один длинный отчёт.

Перед релизом: специфические проверки для AI-приложений

По исследованию OWASP LLM Top 10 2025 [11], для приложений с LLM-компонентами дополнительно проверяем:

1. Prompt injection — изолированы ли пользовательские данные от системных инструкций.
2. Excessive agency — имеет ли агент доступ только к инструментам и данным, необходимым для конкретной задачи.
3. System prompt leakage — не раскрывает ли приложение внутренние инструкции, учётные данные или логику работы.
4. RAG-компоненты — защищены ли источники данных от индиректной инъекции через документы.
5. Логирование — не пишутся ли в логи персональные данные, токены, платёжная информация.

Ошибки, которые встречаются чаще всего

«Мы используем managed-платформу, значит всё защищено»

Lovable, Bolt.new, Base44 — все они имеют встроенные меры безопасности, которые, по данным Backslash Security, оказались «woefully inadequate» для реальных production-нагрузок [19]. Платформа не может знать специфику вашего приложения, ваших пользователей и требований к доступу. Базовая безопасность платформы и безопасность конкретного приложения — разные слои.

«Мы смотрели pull request»

Дифы дочитывают не до конца. Код «выглядит правильно» — это именно то, на что рассчитывает AI-native уязвимость. Транзитивные зависимости вообще не видны в диффе. Отсутствие строки — отсутствие RLS, CSRF-токена, проверки авторизации — в диффе не отображается.

«Это внутренний инструмент, данных немного»

Internal tools и admin-панели исторически читают хуже всего и проверяют реже. При этом именно они часто имеют доступ к полной БД или management API. По данным Apiiro, Apriori именно служебный код демонстрирует 322% больше путей для privilege escalation в AI-генерируемом коде [1].

«Мы проверили зависимости при добавлении»

Уязвимости в зависимостях появляются после добавления. CVE может быть опубликован через три месяца после того, как пакет вошёл в lockfile. SCA нужен не только на входе, но и на регулярной основе — при каждом CI-прогоне.

Тренды: куда движется угроза

На основе исследований 2025–2026 годов можно обозначить несколько направлений, которые будут усиливаться.

Агентный AI расширяет поверхность атаки. Когда AI-агент получает доступ к Slack, Jira, email и файловой системе одновременно, prompt injection превращается из атаки на вывод модели в вектор реального взлома. CVE-2025-54135 (Cursor) и CVE-2025-55284 (Claude Code) — примеры того, что агентный слой сам по себе становится attack surface [9].

MCP-серверы как новый периметр. Model Context Protocol открыл разработчикам удобный способ расширять возможности агентов, но каждый подключённый MCP-сервер добавляет потенциальный вектор tool poisoning и data exfiltration. MCP Configuration Poisoning (CVE-2025-54136) позволяет установить персистентный код-исполнитель, переживающий перезагрузку IDE [2].

Hallucination-атаки становятся промышленными. Атакующие уже не сканируют уязвимости вручную — они автоматизируют генерацию промптов для выявления предсказуемых галлюцинаций и массово регистрируют соответствующие имена в npm и PyPI. В марте 2026 года Georgia Tech Vibe Security Radar зафиксировал 35 новых CVE из AI-генерируемого кода — больше, чем за весь 2025 год [12].

Регуляторное давление нарастает. Помимо российского 420-ФЗ, EU AI Act формирует требования к высокорисковым AI-системам, обрабатывающим персональные данные. Cycode фиксирует, что IBM Cost of Data Breach Report добавляет около $670 000 к средней стоимости инцидента при наличии теневого AI в организации [20].

Заключение: безопасность как архитектурное решение

AI-кодинг — это ускорение, которое уже нельзя остановить. По прогнозу Gartner, 60% всего нового кода в 2026 году будет AI-генерируемым. Вопрос не в том, использовать ли эти инструменты, а в том, с какими guard rails.

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

Практический вывод для команд: security-требования должны стать такой же неотъемлемой частью промпта, как функциональные требования. Контроль зависимостей, сканирование секретов и gate перед merge/release — не опциональная надстройка, а базовый слой инфраструктуры разработки в эпоху AI. Кто успевает встроить этот слой до инцидента — тот выигрывает. Кто узнаёт о нём из сообщения об утечке — платит в 10 раз больше.

Источники

[1] Veracode — "2025 GenAI Code Security Report" — https://www.veracode.com/blog/ai-generated-code-security-risks/

[2] BeyondScale — "Vibe Coding Security Risks: Enterprise Guide 2026" — https://beyondscale.tech/blog/vibe-coding-security-risks-enterprise

[3] Vibe Coder Blog — "The Security Crisis in AI-Generated Code in 2026" — https://blog.vibecoder.me/security-crisis-ai-generated-code-2026

[4] Aikido Security — "Slopsquatting: The AI Package Hallucination Attack Already Happening" — https://www.aikido.dev/blog/slopsquatting-ai-package-hallucination-attacks

[5] B-152.ru — "Закон о персональных данных: что изменилось в 2025–2026 годах" — https://b-152.ru/zakon-o-personalnyh-dannyh-2025

[6] Checkmarx — "2025 CISO Guide to Securing AI-Generated Code" — https://checkmarx.com/blog/ai-is-writing-your-code-whos-keeping-it-secure/

[7] FutureCISO — "CISO alert: AI code vulnerabilities on the rise" — https://futureciso.tech/ciso-alert-ai-code-vulnerabilities-on-the-rise/

[8] Endor Labs — "The Most Common Security Vulnerabilities in AI-Generated Code" — https://www.endorlabs.com/learn/the-most-common-security-vulnerabilities-in-ai-generated-code

[9] Kaspersky Blog — "Security risks of vibe coding and LLM assistants for developers" — https://www.kaspersky.com/blog/vibe-coding-2025-risks/54584/

[10] Accorian — "Security Impact of Vibe Coding Vulnerabilities & Risks" — https://www.accorian.com/security-impact-of-vibe-coding-deep-dive-part-1-of-2/

[11] Security Boulevard — "The OWASP Top 10 for LLM Applications (2025): Explained Simply" — https://securityboulevard.com/2026/03/the-owasp-top-10-for-llm-applications-2025-explained-simply/

[12] Vibers Blog — "Vibe Coding Security Risks: What Founders Miss Before Launch" — https://onout.org/vibers/blog/vibe-coding-security-risks/

[13] ToxSec — "What is Slopsquatting? AI Hallucinations Ship Malware" — https://www.toxsec.com/p/what-is-slopsquatting-ai-hallucinations

[14] The Next Web — "Lovable security crisis: 48 days of exposed projects, closed bug reports" — https://thenextweb.com/news/lovable-vibe-coding-security-crisis-exposed

[15] CISOclub — "Мобильная безопасность 2026: рост инцидентов, API-атаки и уязвимости в AI" — https://cisoclub.ru/dolja-incidentov-svjazannyh-s-mobilnymi-prilozhenijami-prevysila-70/

[16] Forbes Russia — "Эксперты по кибербезопасности зафиксировали рост уязвимостей в AI-сервисах" — https://www.forbes.ru/tekhnologii/548183-eksperty-po-kiberbezopasnosti-zafiksirovali-rost-uazvimostej-v-ai-servisah

[17] CodingTeam — "Закон об ИИ в России 2025: что нужно бизнесу" — https://codingteam.ru/blog/zakon-ob-ii-v-rossii-i-mire-kak-regulirovanie-form

[18] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/

[19] Backslash Security — "Vibe Coding Security Platform" — https://markets.financialcontent.com/postgazette/article/gnwcq-2025-7-31-backslash-security-to-unveil-comprehensive-vibe-coding-security-platform-at-black-hat-usa-2025

[20] Cycode — "Top AI Security Vulnerabilities to Watch out for in 2026" — https://cycode.com/blog/ai-security-vulnerabilities/