Risk acceptance для AI-generated кода: когда можно принять риск, а когда нужен hard block

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

Почему risk acceptance для AI-кода — отдельная тема

Прежде чем отвечать на вопрос «когда можно принять риск», важно понять, почему это вообще встало отдельной проблемой.

Традиционный процесс risk acceptance в AppSec предполагал, что разработчик понимает код, который он написал. Он принял архитектурное решение осознанно, может объяснить компромисс и нести за него ответственность. AI-ассистент этого не делает.

LLM — это prediction engine, а не security expert. Когда вы просите его написать функцию, он оптимизирует под функциональность и синтаксическую корректность, но не под вашу threat model, ваш compliance-контекст и ваши внутренние стандарты. Это не недостаток конкретной модели — это системное свойство класса инструментов. Veracode в 2025 году протестировала более 100 LLM на четырёх языках (Java, JavaScript, Python, C#) и получила 45% failure rate по secure coding benchmarks, при этом более крупные модели не показали значимого улучшения по security-метрикам [1].

Исследование Apiiro на Fortune 50 enterprises зафиксировало к июню 2025 года: AI-генерируемый код добавлял более 10 000 новых security findings в месяц — это в 10 раз больше, чем в декабре 2024 года. Архитектурные дефекты выросли на 153%, пути для privilege escalation — на 322% [2].

Команда Georgetown CSET в ноябре 2024 года выявила ещё одну системную проблему: модели почти никогда не обучаются с security как benchmark — они обучаются на функциональных тестах вроде HumanEval. Это означает, что безопасность не является частью optimization target [3].

Вывод, который следует из этих данных: каждый AI-generated pull request требует иного подхода к review, чем PR от человека, который сознательно принял архитектурное решение. И это напрямую влияет на то, как организовывать risk acceptance.

Что такое risk acceptance применительно к AI-коду

Risk acceptance в классическом понимании (NIST SP 800-30, ISO 27001) — это решение принять остаточный риск, который находится в пределах risk appetite и risk tolerance организации [4]. NIST определяет acceptable risk как «уровень остаточного риска, который укладывается в задокументированный risk appetite организации» [5].

В контексте AI-кода risk acceptance — это формализованное решение: «мы видим этот security finding в PR, оцениваем его severity, контекст и компенсирующие контролы — и принимаем осознанное решение о том, блокируем ли merge или принимаем риск с задокументированным обоснованием».

Ключевое отличие от классического понимания — скорость. Когда AI генерирует код, PR появляются в десятки раз быстрее. Это означает, что либо у вас есть автоматизированная policy, либо вы принимаете риски вслепую.

Три возможных исхода review finding

1. Риск принят (accepted): finding зафиксирован, обоснование задокументировано, владелец назначен, срок пересмотра установлен.
2. Риск принят с условием (conditional accept): merge разрешён при выполнении компенсирующих мер — например, мониторинг, additional review в следующем спринте, ограничение scope деплоя.
3. Hard block: merge заблокирован до устранения finding. Без исключений, без waiver-процесса.

Проблема большинства команд в том, что у них нет явного разграничения между этими тремя состояниями. Всё решается «на глаз» — и при объёмах AI-генерируемого кода это перестаёт работать.

Матрица: что блокировать жёстко, а что можно принять

Приведём операциональную классификацию, основанную на типах находок и их характеристиках.

Категория 1. Всегда hard block

Следующие классы находок должны блокировать merge без исключений — независимо от давления по срокам, «срочности» фичи или размера изменения.

Секреты и credentials в коде или в git history. Hardcoded API keys, токены, пароли, private keys, connection strings — это категория с нулевой толерантностью. Причина: секрет, попавший в git history, живёт там вечно. Ротировать его сложнее, чем не допустить. Apiiro зафиксировал 40% рост secrets exposure в AI-генерируемом коде по сравнению с human-written [2]. Реальный контекст: волна атак Mini Shai-Hulud в мае 2026 года, скомпрометировавшая пакеты TanStack, Mistral, LiteLLM, именно использовала hardcoded paths к credentials как основной вектор [6][7].

Уязвимости класса CVSS Critical (9.0+) без компенсирующих контролов. SQL Injection, Remote Code Execution, незащищённый endpoint с доступом к sensitive data без аутентификации — всё, что при эксплуатации даёт attacker прямой control. CSA приводит пример: AI-ассистент, получив запрос «eval(expression)», генерирует однострочное решение, которое открывает дверь для RCE — потому что он оптимизирует под решение задачи, а не под безопасность [8].

Незащищённые authentication и authorization компоненты. AI-генерируемый IDOR (Insecure Direct Object Reference) — классический пример: endpoint @app.get("/orders/{order_id}") без проверки владельца позволяет любому авторизованному пользователю читать чужие ордера простой подменой ID [9]. Это OWASP API Top 10 #1, и в code review он практически невидим без явного анализа логики доступа.

Криптографические failures в критичных компонентах. CWE-327 (использование сломанного/слабого алгоритма). Veracode показывает 14% failure rate по этой категории [1] — на первый взгляд немного, но в компонентах, отвечающих за шифрование данных пользователей или токенов сессий, один такой дефект критичен.

Изменения в CI/CD pipeline файлах и GitHub Actions без security review. Отдельная, часто недооцениваемая категория. Trail of Bits в августе 2025 года продемонстрировал, что attacker может разместить невидимые инструкции в HTML bug report на GitHub, которые будут выполнены AI-агентом в pipeline [10]. Это означает: каждый AI-generated .github/workflows/*.yml, Dockerfile, Makefile с новыми командами требует обязательного human review с security-фокусом.

Галлюцинированные или не верифицированные зависимости. AI-ассистенты систематически предлагают пакеты, которые могут не существовать или существовать под похожим именем с malicious content. Sophisticated attackers мониторят галлюцинированные package names и регистрируют их на npm/PyPI с malicious payload [11]. Это supply chain attack vector, обходящий все традиционные perimeter defenses.

Категория 2. Soft block / conditional accept

Это нахождения с высоким риском, которые при наличии конкретных компенсирующих мер могут быть приняты — но только с явным документированием и назначением owner.

CVSS High (7.0–8.9) в компонентах без прямого внешнего доступа. Если уязвимость находится во внутреннем сервисе за несколькими слоями аутентификации, risk контекстуально иной, чем в публичном API. Это не означает «игнорировать» — это означает: «принять с условием устранения в следующем спринте и с фиксацией в risk register».

XSS (CWE-80) в административных интерфейсах с ограниченным доступом. Veracode показывает 86% failure rate по XSS — это один из самых высоких показателей [1]. Контекст важен: XSS в публичном форме — hard block. XSS в admin panel, доступной только внутренним пользователям с MFA — conditional accept с обязательным устранением.

Использование устаревших, но ещё не EoL зависимостей. AI часто предлагает не самые свежие версии библиотек. Если зависимость имеет CVEs Medium или Low и не является транзитивной для чего-то критичного — conditional accept с заведением задачи на upgrade.

Отсутствие input validation в non-critical endpoint. Без внешнего доступа и без связи с sensitive data — conditional accept с явным TODO и тестом на validation в acceptance criteria следующего PR.

Категория 3. Accept с документированием

Стилистические и quality-related находки без security implications. Высокая цикломатическая сложность, дублирование кода, non-idiomatic patterns — не требуют блокировки, но требуют фиксации в tech debt registry.

CVSS Low (0.1–3.9) без признаков exploitability в текущем контексте. Принять с задокументированным обоснованием и сроком переоценки.

Конфигурационные предупреждения в dev/test окружениях. Debug-флаги, расширенные CORS в staging — требуют проверки, что они не переедут в production через IaC, но сами по себе не блокируют merge в dev branch.

Как строить policy gate: от wishful thinking к enforcement

Ключевая проблема, которую фиксируют практики: policy существует на бумаге, но не работает как gate. Codebridge прямо формулирует это: «governance only holds when required checks are mandatory and non-bypassable before merge» [12].

Шаг 1. Классифицировать репозитории по risk tier

Не все репозитории одинаковы. Критичность зависит от:

1. Данные: обрабатывает ли репозиторий PII, платёжные данные, медицинские записи?
2. Доступность: публичный API или только внутренний сервис?
3. Привилегии: что может сделать код — читать данные или изменять конфигурацию, управлять доступом?
4. Blast radius: если этот компонент скомпрометирован, что ещё будет затронуто?

Для каждого tier устанавливаются разные пороги hard block и разный набор обязательных gate-проверок.

Шаг 2. Перевести policy в code

Policy-as-code — не опция, а требование. Речь идёт о конфигурации реальных CI/CD gates с конкретными severity thresholds. Пример из практики (Datadog PR Gates): gate блокирует PR только на новые findings, введённые конкретным PR, а не на уже существующие в репозитории — это критически важно для adoption, потому что иначе разработчики будут обходить gate из-за noise [13].

Минимальный набор gates для репозитория с AI-generated кодом:

1. SAST (Semgrep, CodeQL, SonarCloud) — блокировать на Critical и High.
2. Secrets scanning — блокировать на любой verified secret.
3. SCA / dependency check — блокировать на CVSS 7.0+ в прямых зависимостях; предупреждать о транзитивных.
4. Package verification — проверять существование пакета в официальном registry до установки.
5. IaC scanning — для изменений в .yml/.tf/.dockerfile.

Шаг 3. Определить waiver-процесс только для категории 2

Hard block-категории не должны иметь waiver. Это может звучать жёстко, но именно поэтому это работает: если исключение возможно всегда, давление по срокам всегда будет побеждать.

Для conditional accept нужен явный процесс: кто принимает решение (не разработчик сам на себя), что документируется (JIRA ticket с обоснованием, severity, компенсирующие меры, срок устранения), кто получает уведомление (AppSec lead или security owner).

Шаг 4. Отдельно — human review для высокорисковых категорий

Исследование IEEE-ISTAS 2025 на 400 code samples показало, что каждые 5 итераций LLM-feedback без human review увеличивают количество critical vulnerabilities на 37,6% [14]. Это означает: для AI-intensive PR необходимо ограничивать число последовательных LLM-only iterations и вводить mandatory human review checkpoint.

SoftwareSeni рекомендует запретить AI-generated код для конкретных компонентов: authentication systems, authorization frameworks, cryptographic implementations, payment processing, secrets management [2]. Это разумная позиция для команд с высоким риск-профилем.

Специфика supply chain: отдельный risk tier

Supply chain в контексте AI-кодинга заслуживает отдельного обсуждения, потому что здесь классический risk acceptance не работает.

В мае 2026 года атака Mini Shai-Hulud скомпрометировала сотни пакетов в npm и PyPI — включая TanStack (220+ миллионов downloads/month), Mistral AI SDK, LiteLLM [6][7][15]. Malware целенаправленно искал credentials в 100+ hardcoded paths — SSH keys, AWS/GCP/Azure IAM, GitHub tokens, npm tokens, CI/CD secrets.

Что делает эту атаку релевантной для темы AI-кода:

1. AI-агенты и vibe coding провоцируют быструю установку зависимостей без ревью — именно так срабатывает pip install с malicious версией.
2. Галлюцинированные package names создают attack surface: attackers регистрируют hallucinated names с malicious payload [11].
3. CI/CD pipeline — основная цель: payload проверяет наличие GITHUB_ACTIONS environment variable и активируется именно там [16].

Практические выводы для supply chain risk policy:

1. Quarantine period для новых пакетов: внутренний proxy (Verdaccio, Nexus) с карантином 7+ дней для новых версий.
2. npm audit signatures как CI gate (npm 9.5+).
3. Behavioral scanning (Socket.dev, Phylum) — не только CVE matching, но и анализ install scripts, network calls, filesystem access.
4. Проверка существования пакета до установки — отдельный gate для hallucinated packages.
5. Ротация credentials при любом подозрении на компрометацию зависимости.

Как выглядит работающий decision framework в PR review

Сформулируем decision tree, который можно использовать при оценке AI-generated PR.

Вопрос 1. Есть ли в PR секреты, credentials или hardcoded tokens?

— Да → Hard block. Без исключений.

Вопрос 2. Есть ли новые зависимости? Они верифицированы?

— Неверифицированные или новые без проверки на malicious payload → Hard block до верификации через SCA + behavioral scan.

Вопрос 3. Изменены ли CI/CD файлы, GitHub Actions, Dockerfile, IaC?

— Да → Обязательный human review с security-фокусом. Без approval security owner — block.

Вопрос 4. Есть ли SAST-находки CVSS Critical или High?

— Critical → Hard block. — High: уточнить контекст. Публичный endpoint, sensitive data, authentication/authorization logic → Hard block. Внутренний сервис с компенсирующими контролами → Conditional accept с документированием.

Вопрос 5. Затронуты ли authentication, authorization, cryptography, payment?

— Да → Обязательный security review независимо от CVSS score. AI-генерируемый код в этих компонентах имеет наивысший inherent risk.

Вопрос 6. Какой risk tier у репозитория?

— Tier 1 (critical data/access) → Более строгие пороги для conditional accept, меньше waivers. — Tier 3 (internal tools, low sensitivity) → Более широкое использование conditional accept.

Ошибки, которые убивают risk acceptance process

Ошибка 1. Policy без enforcement. Любой gate, который можно обойти аргументом «срочно» или просто игнорировать без последствий — не gate. «Если нельзя обойти, это действительно gate» [12].

Ошибка 2. CVSS как единственный критерий. CVSS показывает severity уязвимости in vacuum. OWASP Risk Rating добавляет business context: likelihood, impact на ваши активы, компенсирующие контролы [17]. Комбинируйте оба подхода: CVSS для быстрой классификации, OWASP для принятия решений по High и Critical.

Ошибка 3. Слишком много noise. Gate, который генерирует сотни предупреждений — это gate, который разработчики будут обходить. Принцип Datadog PR Gates: блокировать только на новые findings, введённые конкретным PR [13]. Это важно для adoption.

Ошибка 4. Считать, что более умные модели решат проблему. Veracode прямо фиксирует: процент secure code generation остался практически неизменным даже при значительном росте параметров моделей [1]. Нельзя просто подождать, пока AI «научится» писать безопасный код. Нужны wrapper systems.

Ошибка 5. Не разделять AI-генерируемые PR как отдельный класс. Legit Security в 2025 году нашли, что в среднем 17% репозиториев в организации имеют сочетание: разработчики используют GenAI tools AND отсутствует branch protection или code review [18]. Это «токсичная комбинация».

Ошибка 6. Не учитывать итеративную деградацию. Каждые 5 LLM-итераций без human review увеличивают critical vulnerabilities на 37,6% [14]. Risk acceptance decision нужно переоценивать при каждом значительном AI-refactoring, а не только при первом review.

Регуляторный и compliance контекст

Risk acceptance для AI-кода всё активнее входит в compliance scope.

NIST AI RMF 1.0 (2023) и Generative AI Profile (NIST AI 600-1, 2024) прямо рекомендуют организациям «устанавливать и регулярно пересматривать конкретные критерии, при которых AI-системы должны быть деактивированы в соответствии с установленными risk tolerances» [19]. NIST SP 800-218A (SSDF Community Profile для Generative AI, 2024) требует review всего кода — как human-written, так и AI-generated — для обнаружения, оценки и устранения уязвимостей [20].

SOC 2 Type II требует 6–12 месяцев evidence. Это означает: документация о том, кто что проверял, почему принял risk, какие gates сработали — это не бюрократия, это audit requirement. Templating risk acceptance documentation сейчас, а не накануне аудита — прагматичная позиция [2].

В ЕС Cyber Resilience Act (CRA), вступающий в силу в полном объёме в 2027 году, затрагивает products with digital elements и требует документированных vulnerability handling процессов [21]. AI EU Act добавляет требования к high-risk AI systems.

Практический чек-лист: что проверить до merge AI-generated PR

Уровень 1. Автоматизированный (обязательный, CI gate)

1. Нет ли новых secrets или hardcoded credentials (git-secrets, detect-secrets, Gitleaks)?
2. Прошли ли все новые зависимости SCA check с CVSS <7.0 для прямых зависимостей?
3. Прошёл ли SAST с отсутствием новых Critical-находок?
4. Верифицированы ли пакеты через behavioral scan (Socket.dev или аналог)?
5. Нет ли изменений в CI/CD файлах без security approval?

Уровень 2. Human review (для High и conditional accept)

1. Логика аутентификации и авторизации проверена вручную?
2. Все новые endpoints имеют input validation и output encoding?
3. Зависимости, предложенные AI, существуют в официальном registry под указанным именем?
4. Нет ли архитектурных паттернов с неоправданно широкими привилегиями?
5. Для компонентов с PII или payment data — выполнен ли дополнительный security review?

Уровень 3. Документирование (для conditional accept)

1. Зафиксировано ли обоснование принятия риска с severity, контекстом и компенсирующими мерами?
2. Назначен ли owner и установлен ли срок устранения?
3. Создан ли ticket для remediation в следующем спринте?
4. Уведомлён ли AppSec/security owner?

Роль HighVibe в этом процессе

Одна из практических сложностей risk acceptance — это скорость. AI-ассистенты генерируют код быстро, PR появляются в потоке, и к моменту review у разработчика уже нет контекста конкретного изменения в голове. Длинный security отчёт не помогает — нужен короткий ответ: что именно блокирует этот PR, почему это критично, и что конкретно нужно исправить.

HighVibe работает как слой контроля до merge и релиза: анализирует конкретное изменение в коде, конфигурациях и зависимостях, объясняет найденный риск на понятном языке и предлагает следующий шаг. Это не замена SAST, SCA или AppSec-программы — это дополнительный сигнал, сфокусированный именно на том, можно ли безопасно принять это изменение сейчас.

Будущее: куда движется risk acceptance для AI-кода

Несколько трендов, которые уже формируют область в 2025–2026 году и будут влиять на неё дальше.

Agentic AI меняет масштаб. Если сейчас речь идёт о ревью AI-suggested кода, в agentic сценарии AI самостоятельно открывает PR, изменяет зависимости и пушит изменения в CI/CD. OX Security отмечает: традиционные SDLC-контролы предполагают, что разработчик понимает изменение, которое ревьюит, — agentic AI ломает это предположение на каждом уровне [22].

Supply chain attacks становятся более таргетированными. Атаки 2025–2026 года (TeamPCP, Shai-Hulud) показали: threat actors систематически атакуют именно AI toolchain — LiteLLM, mistralai SDK, TanStack. Риск «я использую популярный AI-пакет» теперь принципиально отличается от риска «я использую популярный web framework».

Regulatory pressure нарастает. NIST SP 800-53 Release 5.2.0 (август 2025) включил новые controls, специфически адресующие AI-generated code в software supply chain [23]. Организации, работающие с federal procurement или стремящиеся к SOC 2 / ISO 27001, будут испытывать всё больше pressure на documentation и enforcement.

Идентификация AI-generated кода станет обязательной. Пока в репозитории нельзя надёжно определить, какой код написан AI, а какой человеком — это ограничивает возможности для дифференцированного risk management. Инструменты трекинга AI-provenance (например, PR labels, commit metadata) станут частью baseline governance.

Заключение: три принципа работающего risk acceptance

Первый — policy without enforcement is wishful thinking. Пока git push с hardcoded API key можно смержить после трёх кликов «ignore», никакой policy нет. Gates должны быть non-bypassable для категории hard block.

Второй — «работает» и «безопасно для merge» — это разные вопросы, и AI не отвечает на второй. Проверка на функциональность не заменяет security review. AI-генерируемый код может пройти все unit tests и одновременно содержать IDOR, hardcoded secret или галлюцинированный пакет с malicious payload.

Третий — risk acceptance — это не форма для отмазки. Это формализованный процесс с owner, обоснованием, компенсирующими мерами и сроком. Без этого «принять риск» превращается в «не заметить риск» — с той разницей, что при инциденте первое можно защитить перед аудитом, а второе — нет.

Команды, которые выиграют в горизонте 2025–2027 года — те, кто встроят security verification непосредственно в AI-assisted workflow: не как дополнительный процесс после разработки, а как неотъемлемую часть того, что значит «смержить PR».

Источники

[1] Veracode — "Secure AI Code Generation: From Policy to Practice" — https://www.veracode.com/blog/secure-ai-code-generation-in-practice/

[2] 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/

[3] CSET Georgetown — "Cybersecurity Risks of AI-Generated Code" — https://cset.georgetown.edu/publication/cybersecurity-risks-of-ai-generated-code/

[4] ISMS.online — "Risk Acceptance" — https://www.isms.online/glossary/risk-acceptance/

[5] NIST CSRC — "Acceptable Risk" — https://csrc.nist.gov/glossary/term/acceptable_risk

[6] Cybernews — "Hundreds of NPM packages compromised in a new supply chain attack" — https://cybernews.com/security/npm-packages-with-millions-downloads-compromised/

[7] Tom's Hardware — "Compromised Mistral AI and TanStack packages may have exposed credentials in Mini Shai Hulud campaign" — https://www.tomshardware.com/tech-industry/cyber-security/compromised-mistral-ai-and-tanstack-packages

[8] Cloud Security Alliance — "Understanding Security Risks in AI-Generated Code" — https://cloudsecurityalliance.org/blog/2025/07/09/understanding-security-risks-in-ai-generated-code

[9] DEV Community — "AI-Generated Code Is Merging Into Your Main Branch. Are You Sure It's Safe?" — https://dev.to/vorsken/ai-generated-code-is-merging-into-your-main-branch-are-you-sure-its-safe-14kp

[10] War on the Rocks — "Your Defense Code Is Already AI-Generated. Now What?" — https://warontherocks.com/2026/03/your-defense-code-is-already-ai-generated-now-what

[11] Veracode — "Why Securing AI Code Generation is Critical for AppSec" — https://www.veracode.com/blog/securing-ai-code-generation-appsec/

[12] Codebridge — "How to Ship Secure AI-Generated Code: A Governance Model for Reviews, Sandboxing, Policies, and CI Gates" — https://www.codebridge.tech/articles/how-to-ship-ai-generated-code-securely-a-governance-model-for-reviews-sandboxing-policies-and-ci-gates

[13] Datadog — "PR Gates" — https://docs.datadoghq.com/pr_gates/

[14] IEEE-ISTAS 2025 — "Security Degradation in Iterative AI Code Generation: A Systematic Analysis" — https://arxiv.org/html/2506.11022v2

[15] GitGuardian — "Three Supply Chain Campaigns Hit npm, PyPI, and Docker Hub in 48 Hours" — https://blog.gitguardian.com/three-supply-chain-campaigns-hit-npm-pypi-and-docker-hub-in-48-hours/

[16] Trend Micro — "Inside the LiteLLM Supply Chain Compromise" — https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html

[17] Practical DevSecOps — "OWASP Risk Rating Methodology vs CVSS" — https://www.practical-devsecops.com/owasp-risk-rating-methodology-vs-cvss/

[18] Security Boulevard / Legit Security — "4 New AppSec Requirements in the Age of AI" — https://securityboulevard.com/2025/11/4-new-appsec-requirements-in-the-age-of-ai/

[19] WilmerHale — "NIST Issues New AI Risk Mitigation Guidelines and Software" — https://www.wilmerhale.com/en/insights/blogs/wilmerhale-privacy-and-cybersecurity-law/20240808-nist-issues-new-ai-risk-mitigation-guidelines-and-software

[20] NIST CSRC — "NIST Publishes SP 800-218A: Secure Software Development Practices for Generative AI" — https://csrc.nist.gov/news/2024/nist-publishes-sp-800-218a

[21] OWASP OT Top 10 — "Standards and Regulations" — https://ot.owasp.org/v/2025/background-ot/related-standards/

[22] OX Security — "Secure SDLC in the Age of AI: From Static Checks to Active Risk Control" — https://www.ox.security/blog/secure-sdlc/

[23] NIST CSRC — "NIST Risk Management Framework" — https://csrc.nist.gov/projects/risk-management