AI-кодинг требует контроля до коммита

Опыт Relay Network: риски AI-разработки лучше ловить не после PR, а в IDE и pre-commit, пока контекст ещё у разработчика.

2026-05-29 GIGATAP Team #security
#software supply chain#AI coding#open source security

AI-кодинг требует контроля до коммита

Опыт внедрения AI-кодинга в Relay Network полезен тем, что изменения в безопасности не оформили как очередную памятку с правилами. Их встроили в рабочий процесс: разрешённые AI-инструменты, подсказки по безопасности прямо во время разработки и pre-commit-проверки до того, как код попадёт в pull request.

Источник — клиентская история Snyk, и читать её стоит с учётом этого контекста. Но деталей достаточно, чтобы вывод был полезен для security operations. Главное здесь не в том, что один вендорский инструмент решает риски AI-кодинга. Главное — AI-помощники меняют точку появления риска. Если код генерируется быстрее, слабые зависимости и небезопасные шаблоны тоже появляются быстрее. Контроли, которые срабатывают только в CI или на ревью pull request, могут оказаться слишком поздними для того, как разработчики теперь работают.

Relay Network решила сдвинуть безопасность ближе к моменту создания кода.

Что изменилось#

Relay Network — софтверная компания из Раднора, штат Пенсильвания. Она строит B2C-коммуникационную платформу для предприятий из регулируемых отраслей. По данным Snyk, компания и раньше относилась к безопасности как к части инженерной работы, а не как к отдельной функции финального ревью. Brendan Putek, Director of DevOps, руководит группой platform engineering, которая отвечает за безопасность, developer enablement, CI/CD, облачные операции и site reliability engineering. Esaie Batoula, Security Engineer, занимается инструментами, паттернами и автоматизацией, которые помогают разработчикам самим исправлять найденные проблемы.

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

Relay Network рано стандартизировалась на GitHub Copilot: он подходил к их GitHub-среде и давал разработчикам одобренный enterprise AI-инструмент. Последнее не косметика. Во многих компаниях первая проблема безопасности с AI — не модель, а несанкционированное использование. Если у разработчиков нет удобного внутреннего пути, они могут вставлять код или контекст в неуправляемые потребительские сервисы. Так появляется риск для приватности и аудита ещё до того, как сгенерированный код вообще попал в коммит.

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

После этого Relay встроила Snyk в процесс AI-assisted coding. Раньше разработчики часто видели security findings уже после открытия pull request. К этому моменту работа психологически считалась «готовой», контекст начинал теряться, а вопросы по безопасности возвращались к Batoula. Snyk цитирует его описание знакомого сценария: проверка безопасности падает в PR, разработчик хочет доставить изменение, а security приходится объяснять проблему и способ исправления.

Компания хотела получать findings раньше. Благодаря интеграции Snyk с GitHub Copilot разработчики могли видеть security feedback во время генерации или редактирования кода и применять исправления до коммита.

Почему это важно для цепочки поставки ПО#

Это история про software supply chain, хотя здесь нет драматичного взлома package registry.

Большинство сбоев в цепочке поставки выглядят не как кино. Это мелкие решения о доверии, повторённые в масштабе: какой пакет попадает в кодовую базу, какую сгенерированную функцию принимают, чей maintainer access считают безопасным, какое предупреждение откладывают «на потом». AI-инструменты для кода меняют объём и темп этих решений.

Gate на pull request всё ещё полезен. Но одного его мало. Чем позже появляется finding, тем дороже он становится — и социально, и операционно. Разработчик уже переключился. Ревьюер теперь блокирует доставку. Security превращается в отдел, который говорит «нет» после того, как работа вроде бы закончена.

Модель Relay Network пытается развернуть это наоборот. Security prompt появляется, пока код ещё у разработчика под рукой. В этом практическая ценность идеи «secure at inception», если убрать из неё лозунг. Это не обещание, что все баги исчезнут. Это утверждение про правильный момент и контекст.

Источник также говорит, что Relay Network расширила workflow кастомными pre-commit hooks. Batoula взял hooks Snyk за основу и добавил проверки под процесс Relay, чтобы сканировать новый код до коммита. Цель — ловить проблемы до PR review, а не через несколько дней в CI.

Этот паттерн полезен и вне конкретного набора инструментов:

  • дать разработчикам разрешённого AI-помощника вместо надежды, что shadow AI не появится;
  • размещать security feedback в IDE, ассистенте или commit path, пока контекст свежий;
  • оставить CI и PR checks как backstop, а не как первый значимый контроль;
  • настраивать hooks под локальные workflows, а не полагаться только на правила по умолчанию;
  • измерять, стало ли меньше вопросов и эскалаций, а не только факт запуска сканов.

Источник сообщает, что до изменений Batoula получал от пяти до десяти вопросов в день от разработчиков по security findings. Там же сказано, что Relay сократила исторический backlog и поддерживала ноль critical и ноль high-severity issues во всей кодовой базе. Это заявления из вендорской customer story, а не независимо проверенные результаты аудита. Но они показывают операционный сигнал, который стоит отслеживать: меньше поздних сюрпризов, меньше передач между разработкой и security, меньше нерешённых high-priority рисков.

Что проверить перед копированием модели#

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

Командам, которые думают о похожей схеме, стоит начать с реального пути разработки. Где разработчики создают код? Где они принимают AI-подсказки? Где появляются новые зависимости? Где secrets, customer data или regulated data могут попасть в prompts или logs? Контроль, который промахивается мимо этих моментов, будет создавать отчёты, но не менять поведение.

Для AI-кодинга и безопасности open source стоит проверить как минимум четыре зоны.

Первая — покрытие разрешёнными инструментами. Если GitHub Copilot, другой ассистент или внутренняя модель разрешены, нужно определить, что туда можно отправлять. Policy должна покрывать source code, customer data, credentials, logs и proprietary context. Разрешённый инструмент снижает shadow AI только если он доступен, удобен и явно предпочтителен.

Вторая — работа с зависимостями. AI может уверенно предложить пакеты, которые разработчик ещё не оценивал. Любое добавление зависимости, сгенерированное AI, стоит считать событием цепочки поставки. Проверяйте репутацию package registry, активность поддержки, лицензионные ограничения, известные уязвимости и наличие trusted publishing или похожих provenance controls там, где это уместно.

Третья — доступ maintainers и автоматизации. Безопасный coding assistant не исправит слабые права в репозитории. Проверьте, кто может публиковать пакеты, merge-ить код, обходить checks, rotate tokens или approve workflows. AI может ускорить производство кода, но слишком широкие права maintainers всё равно определяют blast radius.

Четвёртая — enforcement на commit и PR. Pre-commit hooks полезны, потому что ловят проблемы рано, но сами по себе они не security boundary. Разработчики могут ошибочно настроить или обойти локальные hooks. Server-side checks, protected branches, CI policy и review requirements всё ещё нужны. Более сильная модель — слоистая: local feedback для скорости, central enforcement для уверенности.

Для команд, которые уже занимаются software supply chain, это совпадает с более широким направлением экосистемы: security artifacts должны работать, а не украшать процесс. SBOMs, vulnerability scans, provenance signals и test coverage имеют смысл только тогда, когда влияют на решения. GigaTap уже писал об этом операционном повороте в материале про April signal OpenSSF и в тексте о том, что test coverage пакета важен, когда становится реальным условием релиза, а не значком.

Related reading:

Чего не стоит обещать#

Этот источник не доказывает, что AI-generated code безопасен. Он не доказывает, что Snyk вместе с GitHub Copilot устраняет уязвимые зависимости. В нём недостаточно деталей, чтобы сравнивать false positives, false negatives, scan coverage или точность exploitability scoring.

Он также не закрывает вопрос приватности в AI-разработке. Стандартизация на enterprise assistant может снизить неуправляемое использование, но командам всё равно нужны ясные правила: какой код и какие данные можно отправлять в AI systems. Это вопрос security operations, юридический вопрос и часто вопрос доверия клиентов.

Более сильное и полезное утверждение уже: Relay Network отнеслась к AI-кодингу как к изменению инженерного workflow, а не как к новинке, которую можно обработать постфактум на ревью. Компания поставила security feedback рядом с моментом создания кода, добавила pre-commit checks и оставила ответственность за исправление у разработчика, пока контекст ещё свежий.

Именно это стоит копировать. Не лозунг. Место контроля.