Как доказать клиенту, что код, написанный с помощью ИИ, проверен

Доверие — это не утверждение. Это процесс с артефактами

Почему вопрос вообще возник

Ещё три года назад вопрос "кто написал этот код — человек или ИИ?" не был проблемой для клиентов. Сейчас — это одна из первых тем на приёмке.

По данным опроса Checkmarx среди CISO, AppSec-менеджеров и разработчиков, почти 70% респондентов оценивают, что более 40% кода в их организации уже генерируется с помощью ИИ [1]. Stack Overflow Developer Survey 2025 фиксирует, что 84% разработчиков используют или планируют использовать AI-инструменты [2]. Использование выросло. Доверие — нет: за год доля разработчиков, которые доверяют AI-инструментам, упала с 40% до 29% [2].

Опрос Sonar 2026 года с выборкой почти в 50 000 инженеров показал ещё жёстче: 96% разработчиков не доверяют AI-генерируемому коду без ручного вмешательства [3]. И это внутри команд разработки. Что говорить о клиенте, который не видит ни одного PR, ни одного отчёта сканера, ни одной строки истории ревью?

Проблема не в том, что AI пишет плохой код. Проблема в том, что AI пишет уверенно выглядящий код, который может содержать системные уязвимости — и это не видно без инструментальной проверки. Veracode в 2025 году протестировала более 100 LLM на 80 задачах по четырём языкам программирования и четырём типам уязвимостей. Результат: только 55% AI-генерированного кода оказались безопасными [4]. По данным Checkmarx, AI генерирует небезопасный код с XSS в 86% случаев и небезопасный код с log injection — в 88% [5].

Апиро в 2025 году проанализировал Fortune-50 компании и выявил, что репозитории со значительным объёмом AI-кода демонстрируют на 322% больше путей эскалации привилегий и на 153% больше архитектурных дефектов, чем репозитории с кодом, написанным людьми [5].

Это не повод отказаться от AI-ассистентов. Это повод выстроить контроль, который можно показать клиенту.

Почему клиент спрашивает

Клиент редко задаёт вопрос "вы проверили код?" из праздного любопытства. За этим вопросом стоит несколько конкретных страхов.

Первый — страх уязвимостей в production. Клиент читает новости об инцидентах и понимает, что supply chain атаки случаются именно там, где никто не ожидал.

Второй — регуляторный риск. Если организация работает в финансовом, медицинском или государственном секторе, за небезопасный код наступает ответственность. SOC 2, ISO 27001, PCI DSS — все эти стандарты требуют доказательной базы, а не устных заверений.

Третий — технический долг. Клиент не хочет принимать кодовую базу, которая "работает, но не проверена" — это означает скрытый долг, который придётся гасить позже.

Четвёртый — потеря контроля. По данным опроса ProjectDiscovery среди 200 специалистов по безопасности из Северной Америки и Западной Европы, 57% заявили, что для доверия AI-инструментам им нужен полный audit trail выполненных действий [6]. Показать работу — это не бюрократия. Это базовое условие доверия.

Почему "мы проверили" — не аргумент

Устное заверение ничего не доказывает. "Мы провели код-ревью" без артефактов — это то же самое, что "мы проверили данные" без логов. Клиент не может это верифицировать, а вы не можете это защитить при любом постфактумном разборе инцидента.

При этом поверхностная проверка создаёт специфическую опасность — иллюзию безопасности. AI-код выглядит уверенно: правильный синтаксис, понятная структура, нет очевидных ошибок. Именно поэтому 61% разработчиков в опросе Sonar согласились с тем, что AI часто производит код, который выглядит правильным, но не является надёжным [7]. Быстрый взгляд на такой код не поможет — нужна инструментальная проверка с фиксированным результатом.

Конкретный сценарий: AI-инструмент предложил зависимость, которой не существует. Разработчик установил её. Пакет с таким же именем уже был зарегистрирован злоумышленником — это атака типа slopsquatting. Исследование трёх университетов на выборке в 576 000 сэмплов кода показало: в 20% случаев LLM рекомендовали пакеты, которых нет ни в одном публичном реестре [8]. Причём 43% этих "галлюцинируемых" имён пакетов повторялись при повторных запросах — то есть атакующий может заранее предсказать, какое имя зарегистрировать [9]. Инструментальная проверка SCA поймала бы это. Ручной просмотр — вряд ли.

Что именно нужно доказать

Прежде чем выстраивать процесс, полезно разложить, что конкретно клиент хочет увидеть. Это четыре вещи.

1. Что каждое изменение в коде было проверено перед merge — автоматически и вручную.
2. Что зависимости реальны, не содержат известных CVE и не являются hallucinated packages.
3. Что в коде нет секретов, небезопасных конфигураций, высококритичных уязвимостей — или что они были найдены и исправлены.
4. Что всё вышеперечисленное зафиксировано в виде артефактов, к которым можно вернуться.

Это и есть доказательная база. Всё остальное — способы её собрать.

Слой первый: SAST на уровне pull request

SAST (Static Application Security Testing) — это анализ исходного кода без его запуска. Ключевой принцип: запускать не вручную и не после релиза, а автоматически при каждом открытии или обновлении PR [10].

Как это выглядит в практике: GitHub Actions, GitLab CI, Jenkins или любой другой CI/CD триггер запускает сканирование при каждом пуше в ветку. Результаты появляются прямо в интерфейсе PR — как инлайн-комментарии к конкретным строкам кода. Merge заблокирован, пока критические или высококритичные уязвимости не исправлены [10].

Инструменты — Semgrep CE, SonarQube, CodeQL, Checkmarx — работают именно так [10, 11]. SonarQube использует концепцию quality gate: если PR не проходит порог по метрикам безопасности, слияние не происходит автоматически [11].

Что даёт клиенту: экспорт отчёта SAST по конкретному релизу или по набору PR за период. В этом отчёте — что было найдено, что исправлено, что принято как acceptable risk с обоснованием.

Важный нюанс: SAST видит код, но не видит выполнение. Он не скажет вам, какой endpoint вызывает какую функцию в рантайме. Поэтому SAST — необходимый, но не достаточный слой.

Слой второй: SCA и проверка зависимостей

Software Composition Analysis (SCA) решает другую задачу: анализирует все внешние зависимости и сравнивает их с базами данных известных уязвимостей (CVE, NVD, GitHub Advisory Database).

Особая актуальность для AI-кода — именно здесь. AI-ассистенты часто предлагают устаревшие библиотеки или, как описано выше, несуществующие пакеты. SCA нужно запускать на каждом PR, который затрагивает файлы зависимостей (package.json, requirements.txt, go.sum, Cargo.toml и т.д.) [12].

Базовый чек-лист для SCA:

• все зависимости присутствуют в публичных реестрах (npm, PyPI, crates.io и др.);
• версии зафиксированы (pinned) в lock-файлах, а не указаны через диапазон;
• нет зависимостей с известными CVE критического или высокого уровня;
• проверены транзитивные зависимости — не только прямые;
• лицензии совместимы с требованиями клиента.

Что даёт клиенту: SCA-отчёт по релизу с перечнем всех зависимостей, их версий, найденных CVE и статусов исправлений. Это одновременно является основой для SBOM.

Слой третий: SBOM как инструмент прозрачности

SBOM (Software Bill of Materials) — машиночитаемый реестр всех компонентов программного обеспечения: зависимостей, библиотек, версий, источников. CISA определяет SBOM как фундамент прозрачности software supply chain [13].

Стандарты для SBOM — SPDX (проект Linux Foundation) и CycloneDX (OWASP). Оба поддерживаются большинством современных инструментов генерации.

SBOM генерируется как часть CI/CD pipeline и привязывается к конкретному build ID, коммиту и тегу релиза [14]. Это даёт возможность:

• при обнаружении новой уязвимости (например, аналог Log4Shell) немедленно проверить, затронуты ли конкретные версии в конкретных релизах;
• передать клиенту документ, описывающий состав кода на момент сдачи;
• при необходимости пройти аудит или подтвердить compliance с требованиями SOC 2, ISO 27001 или отраслевыми стандартами.

Хранить SBOM нужно в системе контроля версий рядом с кодом, с привязкой к конкретному релизу — так же, как хранится исходный код [14]. Клиент получает файл SBOM вместе с релизом или по запросу.

Академическое сообщество уже работает над концепцией AI-BOM — расширенного варианта SBOM, который включает документацию алгоритмов, методов сбора данных, фреймворков и лицензионной информации для AI-компонентов [15]. Это ещё не массовая практика, но направление обозначено.

Слой четвёртый: secrets scanning и проверка конфигураций

AI-инструменты склонны к специфическому классу ошибок: hardcoded credentials, debug-флаги оставленные в production-конфигурации, слишком широкий CORS, default secrets вместо сгенерированных. Это не злой умысел — это особенность того, на каком коде обучены модели.

Secrets scanning должен быть встроен в pre-commit hook и/или в CI/CD pipeline. Инструменты — gitleaks, truffleHog, GitHub Secret Scanning. Они ищут паттерны ключей API, токенов, паролей, private keys в diff изменений до того, как они попадут в репозиторий.

Чек-лист для проверки конфигураций:

• нет хардкодированных секретов в коде, конфигах, .env-файлах в репозитории;
• CORS настроен на конкретные домены, а не *;
• debug-режим отключён для production build;
• нет default credentials в конфигурационных файлах;
• Infrastructure-as-Code (Terraform, CloudFormation, Kubernetes manifests) прошёл IaC-анализ.

IaC-файлы и CI/CD-конфиги — зоны особого риска: их читают хуже всего, а AI часто генерирует их с небезопасными дефолтами.

Слой пятый: ревью PR с историей

Автоматические инструменты не заменяют ревью — они освобождают время ревьюера для задач, которые автоматика не решает: архитектурные решения, бизнес-логика, контекст системы. Но само ревью должно оставлять артефакты.

Практика: каждый PR должен иметь как минимум одного approved ревьюера. Комментарии, вопросы, запросы на изменение — всё это фиксируется в истории PR. Клиент может видеть, что не только инструменты проверяли код, но и живой специалист.

Для AI-кода ревью имеет специфику. По данным Apiiro 2025, AI-код содержит на 322% больше путей эскалации привилегий [5] — то есть ревьюер должен уделять особое внимание логике доступов. AI часто генерирует код, который работает в изоляции, но не учитывает системные ограничения: rate limits upstream-сервисов, границы транзакций, контекст многопользовательской среды [5].

Для команд с высоким темпом: ревью можно организовать по принципу "автоматика закрывает механику, человек закрывает смысл". Инструменты проверяют синтаксические уязвимости, зависимости, секреты. Ревьюер фокусируется на логике, архитектуре и контексте.

Слой шестой: релизный gate

Перед каждым релизом нужна финальная проверка — не "всё ли хорошо?", а "есть ли что-то, что блокирует выпуск прямо сейчас?". Это принципиально другой вопрос.

Инструмент контроля здесь — release gate: автоматическая проверка, которая агрегирует результаты SAST, SCA, secrets scan и блокирует деплой при наличии критических открытых находок. Это не длинный отчёт — это короткий ответ "можно/нельзя" с обоснованием.

Релизный gate должен отвечать на конкретные вопросы:

• нет ли открытых критических уязвимостей в SAST-отчёте?
• нет ли зависимостей с незакрытыми критическими CVE?
• нет ли секретов, которые попали в репозиторий?
• прошёл ли PR code review с хотя бы одним approval?

Если gate пройден — релиз идёт. Если нет — останавливается с указанием конкретной причины. Это фиксируется в истории CI/CD и может быть показано клиенту.

Именно здесь помогает ## HighVibe — инструмент, который анализирует конкретное изменение в коде, конфигурации и зависимостях, а не весь репозиторий целиком. Он объясняет проблему простым языком и отвечает на вопрос "можно ли безопасно принять именно это изменение сейчас?" — без длинного отчёта, который никто не дочитает перед релизом [highvibe.dev].

Что показывать клиенту: минимальный пакет артефактов

По итогам работы клиент должен получить не декларацию, а документацию. Вот минимальный набор.

1. SAST-отчёт по релизу — перечень найденных уязвимостей, их статусы (исправлено / принято с обоснованием / не применимо), инструмент и версия базы правил.

1. SCA-отчёт по зависимостям — список компонентов, их версии, найденные CVE, статусы.

1. SBOM в формате SPDX или CycloneDX — машиночитаемый файл, привязанный к конкретному build и тегу релиза.

1. История PR с approval — ссылки на merge request'ы с видимой историей ревью (комментарии, запросы изменений, approval'ы).

1. История прохождения release gate — лог CI/CD с результатом финальной проверки перед деплоем.

Это пять документов. Их наличие переводит разговор из "вы сказали, что проверили" в "мы видим, что было проверено, как, когда и что было найдено".

Типичные ошибки при попытке доказать проверку

Ошибка первая: сканирование только перед релизом. Если SAST запускается раз в релиз, а не на каждом PR, клиент может получить сводный отчёт, но в нём будет невозможно отследить, на каком этапе была найдена уязвимость и как она была устранена. Кроме того, задолго до релиза накопленные риски сложнее исправить.

Ошибка вторая: отчёт без статусов. Отчёт с 40 находками без указания статуса каждой из них — это не доказательство проверки, это демонстрация неуправляемого хаоса. Клиент хочет видеть, что каждая находка имеет ответ.

Ошибка третья: только автоматика без ревью. Автоматические инструменты не видят бизнес-логику, архитектурные решения, контекст данных. Ревью подтверждает, что человек принял ответственность за merge.

Ошибка четвёртая: один инструмент для всего. SAST не видит зависимости. SCA не видит код. Ни тот ни другой не ищет секреты. Нужен стек, а не один инструмент.

Ошибка пятая: ложные срабатывания без ответа. Если клиент видит в отчёте 200 "warnings", из которых 195 — false positive, но нет объяснения этому, он не понимает, насколько серьёзна ситуация. Каждый false positive должен быть помечен как suppressed с обоснованием.

Как выстроить процесс постепенно

Не нужно внедрять всё сразу. Разумная последовательность для команды, которая начинает.

Шаг первый. Подключить secrets scanning как pre-commit hook. Это бесплатно, работает за день и предотвращает самый прямолинейный тип инцидента.

Шаг второй. Добавить SCA на уровень PR для файлов зависимостей. Snyk, Dependabot или аналоги — большинство уже встроены в GitHub/GitLab.

Шаг третий. Добавить SAST на PR. Semgrep CE или CodeQL — open source, настраиваются за несколько часов.

Шаг четвёртый. Настроить quality gate: блокировать merge при критических находках.

Шаг пятый. Генерировать SBOM как часть build pipeline и архивировать его рядом с релизом.

Шаг шестой. Сформировать шаблон отчёта для клиента: что включать, в каком формате, с какой периодичностью.

Будущее: куда движется рынок

OX Security и другие поставщики уже работают над концепцией "живого SBOM" — динамически обновляемого реестра зависимостей, который отслеживает изменения в реальном времени и немедленно алертит при появлении новой CVE в уже задеплоенных компонентах [16].

Snyk в мае 2025 года запустил AI Trust Platform, отдельно адресующий безопасность AI-генерируемого кода, agentic workflow security и AI supply chain protection [17]. Это рыночный сигнал: проблема AI-кода признана отдельным сегментом, а не подмножеством обычного AppSec.

Google DORA Report 2025 зафиксировал корреляцию AI-adoption с ростом нестабильности кода — около 10% — и констатировал, что 30% разработчиков практически не доверяют AI-генерируемому коду [18]. Это создаёт давление на рынок инструментов верификации — спрос будет расти.

Отдельная тенденция: клиенты в регулируемых отраслях начинают включать требования к AI-проверке в SOW и контракты. Это означает, что через 1-2 года пакет артефактов верификации AI-кода станет стандартным требованием приёмки, а не опцией.

Заключение: безопасность как аргумент, а не бремя

Клиент спрашивает про проверку AI-кода не из формализма. Он спрашивает потому, что видит реальные инциденты и понимает: скорость разработки выросла, а инструменты контроля за ней не успели.

Ответ — это не слова. Это артефакты: SAST-отчёт на PR, SCA по зависимостям, SBOM к релизу, история ревью, лог release gate. Команда, которая выстраивает этот процесс, не только отвечает на вопрос клиента — она получает конкурентное преимущество. Потому что большинство команд всё ещё отвечают устно.

AI уже пишет код. Вопрос не в том, использовать ли его. Вопрос в том, кто контролирует, что из этого кода попадает в production — и может ли это доказать.

Источники

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

[2] Stack Overflow — "Mind the gap: Closing the AI trust gap for developers" — https://stackoverflow.blog/2026/02/18/closing-the-developer-ai-trust-gap/

[3] The New Stack / Sonar — "96% of developers don't trust AI code: Here's a step toward the fix" — https://thenewstack.io/agentic-ai-verification-impact/

[4] Veracode — "AI-Generated Code Security Risks: What Developers Must Know" — https://www.veracode.com/blog/ai-generated-code-security-risks/

[5] Shift Asia — "How to Review AI-Generated Code: The Complete Developers Guide" — https://shiftasia.com/column/how-to-review-ai-generated-code-the-complete-developers-guide/

[6] ProjectDiscovery — "2026 AI Coding Impact Report" — https://www.prnewswire.com/news-releases/projectdiscoverys-2026-ai-coding-impact-report-reveals-ai-generated-code-is-outpacing-security-teams-ability-to-keep-up-302749706.html

[7] IT Pro / Sonar — "Almost half of developers don't check AI-generated code" — https://www.itpro.com/software/development/software-developers-not-checking-ai-generated-code-verification-debt

[8] Bleeping Computer — "AI-hallucinated code dependencies become new supply chain risk" — https://www.bleepingcomputer.com/news/security/ai-hallucinated-code-dependencies-become-new-supply-chain-risk/

[9] ActiveState — "Is AI-Generated Code Poisoning Your Software Supply Chain?" — https://www.activestate.com/blog/is-ai-generated-code-poisoning-your-software-supply-chain/

[10] Wiz — "What Is SAST? How Static Application Security Testing Works" — https://www.wiz.io/academy/application-security/static-application-security-testing-sast

[11] Sonar — "SAST Tool: Static Application Security Testing Software Solution" — https://www.sonarsource.com/solutions/security/sast/

[12] Panto AI / Medium — "Why SCA Should Be Part of Code Review Checks" — https://medium.com/@pantoai/why-sca-should-be-part-of-code-review-checks-20bf7d1c4db3

[13] CISA — "Software Bill of Materials (SBOM)" — https://www.cisa.gov/sbom

[14] Cycode — "Software Bill of Materials (SBOM): Enhancing Transparency and Security in Supply Chains" — https://cycode.com/blog/software-bill-of-materials/

[15] arXiv — "Implementing AI Bill of Materials (AI BOM) with SPDX 3.0" — https://arxiv.org/abs/2504.16743

[16] OX Security — "Top 5 SBOM Tools 2025" — https://www.ox.security/blog/sbom-tools/

[17] TrueFoundry — "Best AI Code Security Tools for Enterprise in 2026" — https://www.truefoundry.com/blog/best-ai-code-security

[18] VentureBeat — "43% of AI-generated code changes need debugging in production, survey finds" — https://venturebeat.com/technology/43-of-ai-generated-code-changes-need-debugging-in-production-survey-finds