Security questionnaire: как отвечать enterprise-клиенту, если команда пишет код с AI
Вы ускорили разработку с помощью AI — теперь вас об этом спрашивают на бумаге. Вот как отвечать честно, не теряя сделку и не завышая обещания
Новый вопрос в старом бланке
Если ваша команда уже работает с GitHub Copilot, Cursor, Claude Code или другим AI-ассистентом, вы рано или поздно столкнётесь с вопросом от потенциального клиента. Он может звучать так: «Используете ли вы AI-инструменты для генерации кода? Как вы обеспечиваете его безопасность?»
Ещё год назад этого вопроса в большинстве анкет не было. Теперь он есть. В обновлении SIG 2024 (Standardized Information Gathering — де-факто стандарт для vendor risk assessment) появился отдельный AI-домен, основанный на NIST AI RMF [1]. OWASP выпустил обновлённый LLM Top 10 2025, где prompt injection занимает первую строчку [2]. Vanta запустила отдельный AI Security Assessment, охватывающий 10 категорий рисков, включая governance, data privacy и human oversight [3].
Всё это означает одно: enterprise-клиент сегодня хочет знать не просто «вы следите за безопасностью», а «как именно вы управляете рисками, которые привносит AI в ваш код».
Эта статья — практическое руководство для CTO, Tech Lead и AppSec-инженеров: что именно спрашивают, почему это важно, и как выстроить ответы так, чтобы они были честными, подкреплёнными документацией и выдерживали аудит.
Что именно спрашивают enterprise-клиенты
Стандартные фреймворки уже адаптированы под AI
SIG 2024 — первый крупный questionnaire-фреймворк, добавивший AI Risk Domain. Вопросы в нём покрывают supply chain risk management для AI-компонентов, управление зависимостями моделей, провенанс обучающих данных [1].
Cloud Security Alliance опубликовала Consensus Assessments Initiative Questionnaire (CAIQ), ориентированный на облачных провайдеров и AI-сервисы. Vanta разработала AI Security Assessment, выровненный по NIST AI RMF и ISO 42001 [3]. Glacis опубликовал шаблон из 80+ вопросов, охватывающий SIG 2024, MITRE ATLAS, OWASP LLM Top 10 и EU AI Act [4].
Это означает: если раньше вы могли ответить стандартным набором — SOC 2, ISO 27001, шифрование, инцидент-менеджмент — теперь этого недостаточно. Аудитор ждёт ответов, специфичных для AI-процессов.
Типичные вопросы, которые появляются в анкетах
Не все questionnaire одинаковы, но несколько блоков встречаются регулярно.
Первый блок — AI governance и политика использования: используете ли вы AI-инструменты в разработке, какие именно, для каких задач, есть ли письменная политика, кто её утвердил, как она обновляется.
Второй блок — контроль качества AI-кода: как именно проверяется код, написанный с помощью AI, кто несёт ответственность за его безопасность, используются ли SAST/SCA-инструменты, есть ли специфические гейты для AI-сгенерированного кода.
Третий блок — supply chain и зависимости: как проверяются пакеты, рекомендованные AI-ассистентом, ведётся ли SBOM, используются ли lockfile и криптографическая верификация хэшей.
Четвёртый блок — обращение с секретами и чувствительными данными: попадают ли секреты, ключи, токены в промпты или в генерируемый AI код, как это проверяется, есть ли automated secret scanning.
Пятый блок — документация для аудита: кто и когда делал code review, есть ли трейл для SOC 2, задокументированы ли инциденты, связанные с AI-кодом.
Почему клиент спрашивает: цифры и риски
Прежде чем строить ответы, важно понять, откуда берётся тревога у enterprise-клиента. Она не беспочвенна.
AI-код уязвимее, и это подтверждено данными
Исследование Veracode, протестировавшее более 100 LLM, показало уязвимости в 45% сгенерированных образцов кода — при этом для Java провал составил 72% [5]. Исследование CodeRabbit зафиксировало плотность уязвимостей в AI-генерируемом коде в 2.74 раза выше, чем в коде, написанном вручную [5]. Независимое исследование Apiiro с данными Fortune 50 показало, что к июню 2025 года AI-код добавлял более 10 000 новых security findings в месяц — это рост в 10 раз по сравнению с декабрём 2024 [6].
Профиль уязвимостей тоже изменился: тривиальные синтаксические ошибки упали на 76%, зато архитектурные дефекты выросли — пути для privilege escalation выросли на 322%, архитектурные design flaws — на 153% [6]. Это важно: такие ошибки труднее обнаружить и они опаснее в production.
По данным IBM Cost of a Data Breach Report 2025, 97% организаций сообщили об AI-связанных security incidents [6]. При этом 70% компаний не имеют автоматизированного сканирования секретов для AI-генерируемого кода, а 86% используют open-source компоненты с известными уязвимостями в AI-воркфлоу [7].
Одного SAST недостаточно
Принципиальный момент для технических специалистов: традиционные SAST-инструменты (Semgrep, CodeQL, Snyk Code) не покрывают большинство категорий OWASP LLM Top 10. Они не видят галлюцинированные зависимости, не обнаруживают excessive agency, не выявляют prompt injection через среду разработки [8].
Ещё одна проблема, задокументированная в исследованиях: 78.3% подтверждённых уязвимостей в AI-коде были обнаружены только одним из пяти протестированных SAST-инструментов [9]. Это не означает, что SAST плохой — он необходим. Но одного инструмента объективно не хватает.
Slopsquatting: угроза supply chain, которую клиент уже знает
Это новая категория атак, о которой сейчас активно пишут в security-сообществе. Исследование трёх университетов (UT San Antonio, Virginia Tech, Oklahoma) проанализировало 576 000 образцов Python и JavaScript кода и выяснило: около 20% предлагаемых LLM пакетов не существуют [10].
Атакующий регистрирует несуществующий пакет с тем именем, которое AI часто галлюцинирует, — и ждёт, пока разработчик его установит. По данным исследований, 43% галлюцинированных пакетов повторяются от промпта к промпту — то есть они предсказуемы и являются готовыми мишенями [11]. Snyk зафиксировал более 440 000 таких фантомных зависимостей в Python и JavaScript экосистемах [12].
Даже ChatGPT-4 галлюцинирует примерно в 5% случаев [10] — что при масштабе разработки в сотни тысяч строк кода становится значимой цифрой.
Как строить ответы на questionnaire
Принцип первый: отвечать честно, не преувеличивать и не преуменьшать
Самая распространённая ошибка — либо скрыть факт использования AI-инструментов, либо заявить «мы полностью контролируем AI-код», не имея доказательств. Оба подхода создают репутационный и юридический риск.
Вместо этого — честная карта вашей ситуации: что именно вы используете, в каких процессах, какие контролы внедрили, где есть пробелы и как вы их закрываете. Отсутствие ответа на вопрос о данных — красный флаг для аудитора: он воспринимает это как отсутствие контроля, а не как конфиденциальность [13].
Принцип второй: документация — это и есть ответ
SOC 2 Type II требует доказательств за 6-12 месяцев: кто делал review, на основании каких критериев, что было заблокировано и почему [14]. Если у вас нет этих логов — у вас нет ответа на вопрос аудитора, даже если у вас хорошие процессы.
Для enterprise-клиентов ключевыми артефактами являются: письменная AI usage policy с датой последнего обновления; документация процесса review для AI-генерируемого кода; логи SAST/SCA с датами и результатами; incident log, включая AI-специфичные инциденты; описание ролей и ответственности за AI-код.
Принцип третий: разделять слои контроля
Клиент хочет понять, что у вас есть система, а не надежда. Система — это несколько слоёв. В зрелом enterprise-ответе обычно описываются:
Первый слой — policy и governance: письменная политика использования AI, запрещённые сценарии (аутентификация, шифрование, платёжная обработка — обычно они не делегируются AI без особого контроля), ответственный за обновление политики.
Второй слой — automated scanning: SAST и SCA как обязательные гейты в CI/CD, не опциональные проверки. Минимум два инструмента — данные исследований показывают, что один пропускает большинство AI-специфичных уязвимостей [9].
Третий слой — dependency verification: lockfile, pinned versions, проверка хэшей, мониторинг advisories, внутренний реестр или allowlist доверенных пакетов [11].
Четвёртый слой — secret scanning: автоматизированный поиск секретов во всём коде, включая AI-генерируемый, pre-commit hooks или интеграция в CI/CD.
Пятый слой — human review: кто именно читает diff для AI-кода, по каким критериям, задокументировано ли это как процедура. Это самый слабый слой в большинстве команд — дифы не дочитывают до конца.
Принцип четвёртый: признавать ограничения честно
Если у вас нет ISO 42001 — не надо его придумывать. Если SAST покрывает только классические уязвимости, так и напишите: «мы дополняем его [описание дополнительного слоя]». Честное описание пробелов с планом их закрытия всегда лучше, чем размытые гарантии.
Детальный разбор: как отвечать на конкретные типы вопросов
«Используете ли вы AI-инструменты для генерации кода?»
Типовой хороший ответ включает: список конкретных инструментов (GitHub Copilot, Cursor, Claude Code и т.д.); для каких задач разрешено использование; для каких задач запрещено или требует дополнительного контроля; кто утвердил политику и когда она последний раз обновлялась; как разработчики ознакомлены с политикой.
Чего стоит избегать: «мы используем AI по усмотрению разработчиков» без описания какого-либо контроля.
«Как вы обеспечиваете безопасность AI-генерируемого кода?»
Здесь нужно описать конкретную цепочку: какой SAST запускается, на каком этапе (pre-commit, PR, CI), что происходит при нахождении уязвимости, кто принимает решение о merge. Абстрактное «мы проводим security review» без описания конкретных шагов воспринимается аудитором как отсутствие процесса.
«Как вы управляете зависимостями, предложенными AI?»
Здесь ожидается ответ об SCA-инструменте (Snyk, Dependabot, FOSSA и т.д.), о проверке на несуществующие пакеты, о lockfile как обязательном артефакте, о процессе проверки новых пакетов перед их добавлением. Учитывая публичность темы slopsquatting [10], клиент с хорошей командой безопасности этот вопрос задаст явно.
«Как вы предотвращаете утечку секретов через AI?»
Ожидаемый ответ: конкретный инструмент для secret scanning (GitGuardian, TruffleHog, git-secrets), настроен ли он как обязательный gate, что происходит при обнаружении — алерт или блокировка merge. По данным исследований, в 2025 году в публичных репозиториях было обнаружено более 10 миллионов секретов, и 82% из них оставались активными даже после обнаружения [7].
«Есть ли у вас AI governance policy?»
Это вопрос о том, является ли управление AI-рисками системным или ситуативным. Хороший ответ описывает: документ, который существует и обновляется; роли и ответственность; процесс изменения политики при появлении новых инструментов; как политика транслируется команде разработки. Ссылка на NIST AI RMF или ISO 42001 как методологическую основу усиливает ответ [15].
Что говорит NIST AI RMF: рамка, на которую стоит опираться
NIST AI Risk Management Framework (AI RMF 1.0, 2023; Generative AI Profile, июль 2024) — наиболее влиятельный добровольный фреймворк для управления AI-рисками. Его четыре функции — GOVERN, MAP, MEASURE, MANAGE — описывают итеративный цикл, который enterprise-клиенты используют как эталон при формулировке вопросов [15].
GOVERN — политики, роли, ответственность. MAP — идентификация рисков конкретной AI-системы в её операционном контексте. MEASURE — оценка и тестирование. MANAGE — активное снижение рисков и мониторинг.
Если ваши ответы на questionnaire можно структурировать по этим четырём функциям — это читается аудитором как зрелая governance-модель, а не как набор разрозненных инструментов.
Важный нюанс: NIST AI RMF — добровольный фреймворк, он не имеет силы закона. Но по данным PwC, он становится корпоративной нормой, особенно для компаний, работающих с американскими enterprise-клиентами или стремящихся к соответствию EU AI Act [16].
SOC 2 и ISO 27001: что меняется при наличии AI в разработке
Что уже покрывается существующими стандартами
SOC 2 и ISO 27001 охватывают контроль изменений (change management), управление доступом, security в SDLC. AI-генерируемый код попадает под эти требования так же, как любой другой код: его нужно проверять, документировать review, логировать изменения.
Где появляются новые требования
Проприетарные алгоритмы, обрабатываемые внешними LLM-моделями, создают риски конфиденциальности, которых не существовало с традиционными инструментами разработки [17]. SOC 2 Confidentiality требует понимания того, что именно попадает в промпт, какие данные видит внешняя модель, где они хранятся и кто имеет к ним доступ.
SOC 2 Type II требует доказательств за период наблюдения. Это означает: если у вас нет логов code review с датами и результатами, аудитор не может проверить, что контроль реально работал, а не только задекларирован [18]. Для AI-кода это особенно критично, потому что скорость генерации высокая, а соблазн пропустить review — тоже высокий.
Документация, которую нужно подготовить заранее
Для прохождения аудита нужны: документация процесса security review с описанием, что проверяется и кем; логи SAST/SCA с датами; evidence enforcement-механизмов в CI/CD (что именно блокируется, а что только предупреждает); incident response plan с учётом AI-специфичных сценариев; board-level risk reporting, показывающий, что executive-команда осведомлена о рисках AI-кода [6].
Типичные ошибки при ответе на AI-questionnaire
Первая ошибка — отрицать использование AI. Если разработчики используют инструменты, а компания это отрицает, и это всплывает (а в enterprise-контрактах часто есть право аудита) — это репутационный и юридический риск, несопоставимо больший, чем честный ответ с описанием контролей.
Вторая ошибка — заявлять «SAST покрывает всё». По данным исследований, один SAST-инструмент пропускает большинство AI-специфичных уязвимостей [9]. SAST — необходимый, но не достаточный слой.
Третья ошибка — путать «код работает» с «код безопасен для merge». Это разные свойства. PR, который проходит все тесты и lint, может содержать логические уязвимости, галлюцинированные зависимости, hardcoded credentials в нестандартном формате — которые SAST не поймает.
Четвёртая ошибка — не иметь документации на момент заполнения анкеты. Аудитор не принимает «мы делаем review устно» как доказательство. Нужны логи, тикеты, записи решений — за 6-12 месяцев для SOC 2 Type II [18].
Пятая ошибка — игнорировать supply chain в AI-воркфлоу. Если команда устанавливает пакеты по рекомендации AI без проверки их существования в официальных реестрах — slopsquatting — реальный риск [10, 11].
Decision framework: что отвечать в зависимости от вашей ситуации
Если у вас нет AI usage policy: не стоит заявлять, что политика есть. Лучший ответ — «политика в процессе формализации, ключевые принципы использования описаны в [документ/процедуре], ожидаемая дата финализации — [срок]». Это честно и показывает движение.
Если у вас есть SAST, но нет специфического AI-гейта: опишите существующие контролы и добавьте, что вы изучаете дополнительные слои. Не нужно преувеличивать охват — важно показать, что вы понимаете ограничения.
Если у вас не налажена проверка зависимостей: это реальный пробел. Минимальный быстрый ответ — lockfile + SCA-инструмент в CI/CD. Если этого ещё нет — честно зафиксируйте как известный риск с планом закрытия.
Если у вас уже выстроен полный процесс: опишите его с конкретикой — инструменты, этапы, ответственные роли, как документируется. Ссылки на NIST AI RMF и OWASP LLM Top 10 как методологическую базу укрепляют ответ.
Как HighVibe помогает в этом контексте
Одна из самых сложных точек в описанной цепочке — human review AI-кода. Дифы дочитывают не до конца: новая зависимость приезжает незаметно, конфиг меняется в одной строке, служебный код и миграции читают хуже всего.
HighVibe — это слой контроля безопасности AI-кодинга, который работает именно на этом этапе: до merge и до релиза. Он анализирует конкретное изменение, новые и обновлённые зависимости, конфигурационные файлы и релизный контекст — и даёт команде короткий, понятный сигнал: можно ли безопасно принять это изменение сейчас.
Это не замена SAST, SCA или SBOM. Это дополнительный слой — именно тот, которого не хватает между автоматизированным сканированием и финальным решением о merge. Для enterprise-клиента наличие такого слоя — конкретный артефакт, который можно показать в ответе на questionnaire: что именно проверяется до попадания изменения в production.
Тренды: что будет в questionnaire через год
Enterprise security questionnaire по AI будут становиться точнее и жёстче. Несколько направлений, которые уже прослеживаются.
Agentic AI — отдельный домен вопросов. NIST выпустил черновик Agentic Profile для AI RMF [19]. CoSAI (Coalition for Secure AI, участники — Google, Microsoft, OpenAI, Anthropic, IBM) зафиксировала реальные инциденты 2025 года: coding assistant, который сделал бэкдор; модель, запустившая reverse shell при загрузке; интеграция с агентом, давшая атакующему доступ к 700+ Salesforce-окружениям [20].
Kilo Code CVE-2025-11445 показал новый вектор: атакующий встраивает инструкции в README или комментарии в коде, AI-ассистент читает их при анализе репозитория и выполняет — коммитит и пушит бэкдоренный код без участия пользователя [20]. Это прямое следствие того, что markdown стал injection-вектором для AI.
Проверка провенанса AI-моделей становится частью supply chain risk. NullifAI-атака 2025 года продемонстрировала обход PickleScan через намеренно повреждённые pickle-файлы — scanner выдавал ошибки вместо обнаружения угрозы, и reverse shells выполнялись при десериализации [20].
Заключение: подготовиться сейчас — это и есть конкурентное преимущество
Security questionnaire по AI-кодингу — не бюрократическая нагрузка. Это сигнал зрелости вашей команды. Компании, которые смогут чётко ответить на эти вопросы с документацией, будут выигрывать enterprise-сделки у тех, кто отвечает расплывчато или скрывает использование AI.
Минимальный стек, который нужно иметь и описать: AI usage policy (письменная, актуальная), SAST + SCA в CI/CD как обязательные гейты, secret scanning, процесс верификации зависимостей, логи review для аудитора.
Если вы хотите дополнить этот стек слоем контроля, который даёт команде понятный сигнал именно в момент merge и релиза — посмотрите на HighVibe. Это не про замену существующих инструментов, а про закрытие пробела, который остаётся между автоматизированным сканированием и человеческим решением.
Источники
[1] Shared Assessments — "SIG 2024 Update: AI Risk Domain" — https://sharedassessments.org/sig/
[2] OWASP GenAI Security Project — "OWASP Top 10 for LLM Applications 2025" — https://genai.owasp.org/llmrisk/llm01-prompt-injection/
[3] Vanta — "Introducing Vanta's AI Security Assessment" — https://www.vanta.com/resources/introducing-vantas-ai-security-assessment
[4] Glacis — "AI Security Questionnaire: Research-Backed Template with 80+ Questions" — https://www.glacis.io/guide-ai-security-questionnaire
[5] SoftwareSeni — "AI-Generated Code Security Risks: Why Vulnerabilities Increase 2.74x" — https://www.softwareseni.com/ai-generated-code-security-risks-why-vulnerabilities-increase-2-74x-and-how-to-prevent-them/
[6] SoftwareSeni — "Security Risks in AI-Generated Code and How to Mitigate Them" — https://www.softwareseni.com/security-risks-in-ai-generated-code-and-how-to-mitigate-them/
[7] SQ Magazine — "AI Coding Security Vulnerability Statistics 2026" — https://sqmagazine.co.uk/ai-coding-security-vulnerability-statistics/
[8] Growexx — "AI-Generated Code Security Risks: How It Aligns with OWASP Top 10" — https://www.growexx.com/blog/ai-generated-code-owasp-top-10/
[9] Paperclipped — "AI-Generated Code Vulnerabilities 2026: Security Data & Statistics" — https://www.paperclipped.de/en/blog/ai-generated-code-security-vulnerabilities/
[10] BleepingComputer — "AI-hallucinated code dependencies become new supply chain risk" — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/
[11] ActiveState — "Is AI-Generated Code Poisoning Your Software Supply Chain?" — https://www.activestate.com/blog/is-ai-generated-code-poisoning-your-software-supply-chain/
[12] Snyk — "Slopsquatting: New AI Hallucination Threats & Mitigation Strategies" — https://snyk.io/articles/slopsquatting-mitigation-strategies/
[13] Atlas Systems — "AI Vendor Risk Assessment Questionnaire for Compliance" — https://www.atlassystems.com/blog/ai-vendor-risk-questionnaire
[14] CodeAnt — "GitHub AI Code Review Tools Built for SOC 2 Audits" — https://www.codeant.ai/blogs/github-ai-code-review-tools-soc2-compliance
[15] NIST — "AI Risk Management Framework" — https://www.nist.gov/itl/ai-risk-management-framework
[16] Diligent — "NIST AI Risk Management Framework: A simple guide to smarter AI governance" — https://www.diligent.com/resources/blog/nist-ai-risk-management-framework
[17] Augment Code — "AI Coding Tools SOC2 Compliance: Enterprise Security Guide" — https://www.augmentcode.com/tools/ai-coding-tools-soc2-compliance-enterprise-security-guide
[18] Penligent — "How to Use AI for SOC 2 and ISO 27001 Compliance While Reducing Costs" — https://www.penligent.ai/hackinglabs/how-to-use-ai-for-soc-2-and-iso-27001-compliance-while-reducing-costs/
[19] Cloud Security Alliance Labs — "NIST AI Risk Management Framework: Agentic Profile" — https://labs.cloudsecurityalliance.org/agentic/agentic-nist-ai-rmf-profile-v1/
[20] Coalition for Secure AI (CoSAI) — "Addressing what's next in securing enterprise AI" — https://www.coalitionforsecureai.org/addressing-whats-next-in-securing-enterprise-ai/