CI/CD для кода, написанного с ИИ
CI/CD означает непрерывную интеграцию и непрерывную поставку (continuous integration, continuous delivery): это автоматический конвейер, который собирает код, проверяет его и доставляет на среды. Для ИИ-разработки конвейер важнее, чем раньше, по простой причине: когда кода становится больше, а пишет его частично машина, масштабируется только автоматическая проверка. Ревью людьми так масштабироваться не может.
Вы отвечаете за конвейер, через который пойдёт всё больше кода, написанного машиной. В этом блоке показано, где ИИ встраивается в CI/CD, где ему нужно меньше всего свободы и какие проверки становятся обязательными.
CI/CD
CI/CD означает непрерывную интеграцию и непрерывную поставку (continuous integration, continuous delivery): это автоматический конвейер, который собирает код, проверяет его и доставляет на среды. Для ИИ-разработки конвейер важнее, чем раньше, по простой причине: когда кода становится больше, а пишет его частично машина, масштабируется только автоматическая проверка. Ревью людьми так масштабироваться не может.
У ИИ в непрерывной интеграции 2 применения. В первом ИИ помогает писать и чинить сам конвейер: конфигурации сборки, скрипты, описания шагов. Это типовая, хорошо документированная работа с предсказуемой отдачей. Во втором ИИ встраивается в конвейер как ещё один проверяющий: делает автоматический первый проход ревью, проверяет соответствие стандартам, объясняет причины падения сборки.
Главный принцип: любой код, сгенерированный ИИ, должен проходить ровно те же проверки, что и человеческий, без исключений и ускоренных путей. Соблазн «это же простая правка от агента, пропустим» опасен. DORA фиксирует рост нестабильности поставки вместе с ростом использования ИИ, а ускоренные пути проверки, по моему опыту, – одна из её причин.
Поставка относится к зоне, где автономии ИИ должно быть меньше всего: у деплоя на продуктивную среду высокая цена ошибки и ограниченная обратимость. ИИ здесь уместен как помощник, который готовит описание релиза, проверяет чек-лист и предупреждает о рисках изменения. Решение о выкатке принимает и выполняет человек или детерминированная автоматика, агенту его доверять нельзя.
Для корпорации это ещё и требование аудита: должно быть однозначно зафиксировано, кто нажал кнопку.
Инфраструктура как код (Infrastructure as Code, IaC) означает описание серверов, сетей и сервисов в виде конфигурационных файлов, которые применяются автоматически. ИИ хорошо генерирует такие описания: синтаксис строгий, примеров в открытом доступе много, результат проверяется применением на тестовой среде.
Риск здесь особый: ошибка в инфраструктурном коде может удалить данные или открыть доступ наружу. Поэтому для сгенерированных изменений инфраструктуры обязательны план (что именно изменится) до применения и ревью человеком с правами на эту инфраструктуру. Удобно, что основные инструменты показывают такой план штатно.
SAST (Static Application Security Testing) означает автоматический поиск уязвимостей в исходном коде без его запуска. Для ИИ-кода это обязательный шаг по такой причине: модель обучена на открытом коде, где небезопасные шаблоны встречаются часто, поэтому она их воспроизводит. Типичные находки: жёстко зашитые секреты, небезопасная обработка ввода, устаревшие криптографические функции.
Кроме обычного SAST, нужна проверка на вещи, специфичные для ИИ: не попали ли в код секреты из промпта, не добавил ли агент зависимость, которой нет в разрешённом списке. О лицензионной чистоте зависимостей – в блоке 12.
DAST (Dynamic Application Security Testing) означает проверку работающего приложения на уязвимости снаружи, как это делал бы атакующий. Для ИИ-разработки это второй рубеж после SAST: часть уязвимостей проявляется только в работе.
ИИ здесь помогает в 2 ролях: генерирует сценарии атак для проверки (на основе OWASP Top 10 – списка главных рисков веб-приложений от открытого проекта по безопасности OWASP – и специфики вашего приложения; если в приложении есть модель, ещё и OWASP Top 10 для LLM-приложений) и объясняет найденные уязвимости инженерам, которые не специализируются на безопасности. Это снижает нагрузку на ИБ при условии, что ИБ согласовала такой подход.
Линтером называют инструмент, который проверяет код на соответствие стандартам оформления и находит типовые ошибки. С ИИ линтер важнее, чем кажется: модель видит в файлах контекста ваши правила, получает от линтера конкретные ошибки и исправляет их сама, поэтому этот цикл можно замкнуть автоматически.
Совет: вложитесь в настройку линтера под ваши стандарты до внедрения ИИ. Это дешёвое изменение, которое разом поднимает качество всего сгенерированного кода.
ПримерПроверки в конвейере для кода с ИИ
Так выглядит список проверок для пул-реквеста в банке Даниила после внедрения. Обратите внимание: первые 8 проверок были и до ИИ, новые только 3 последние. Для пул-реквеста от агента и от человека список одинаковый.
| Шаг | Проверка | Блокирует слияние | Время |
|---|---|---|---|
| 1 | Сборка | Да | 4 мин |
| 2 | Линтер по стандартам компании | Да | 1 мин |
| 3 | Модульные тесты, покрытие изменённых строк не ниже 70% | Да | 6 мин |
| 4 | SAST, критичные и высокие находки | Да | 5 мин |
| 5 | Проверка зависимостей на известные уязвимости | Да | 2 мин |
| 6 | Интеграционные тесты | Да | 15 мин |
| 7 | Ревью человеком, для платёжных модулей – 2 людьми | Да | до 1 рабочего дня |
| 8 | DAST на тестовой среде, еженочно | Нет, отчёт в ИБ | 40 мин |
| 9 | Поиск секретов и фрагментов промптов в коде | Да | 1 мин |
| 10 | Новая зависимость только из разрешённого списка, лицензия из белого списка | Да | 1 мин |
| 11 | В описании пул-реквеста есть отметка об использовании ИИ и ссылка на спецификацию | Да | мгновенно |
Деплой на продуктивную среду в этом конвейере запускает человек с правами на релиз, его имя попадает в журнал аудита. Агент готовит описание релиза и список рисков, но кнопки у него нет. Время прохождения автоматических шагов – около 35 минут, и это важная цифра: если число пул-реквестов удвоится, конвейер должен выдержать, поэтому его пропускную способность стоит посчитать до пилота.
все 11 проверок, включая аудит того, кто нажал кнопку деплоя, и обязательный DAST. Конвейер часто работает в собственной инфраструктуре, поэтому его пропускную способность нужно считать заранее.
достаточно 6 проверок – сборка, линтер, тесты, бесплатный SAST, поиск секретов, проверка зависимостей – всё это есть в стандартных сборках GitHub Actions или GitLab CI за 1 день настройки. Деплой по кнопке с подтверждением человека сохраняется и здесь: это защита не от регулятора, а от агента, который «просто поправил конфиг».
Что говорят коллеги
Даниил и Мария о том, сколько свободы давать ИИ в конвейере.
С поставкой согласен без оговорок: аудит у нас давно требует знать, кто нажал кнопку, поэтому агент в этой цепочке не пройдёт ни одну проверку. С инфраструктурой как код я осторожнее, чем блок. План и ревью нужны, но в банке за генерацией инфраструктуры для продуктивных сред следит ещё и регулятор, поэтому в первый год я оставлю ИИ только тестовые среды. SAST у нас уже есть, добавлю туда проверку зависимостей по разрешённому списку.
Самым ценным в блоке считаю совет о линтере. Мы настроили его под свои стандарты уже после внедрения и полгода разбирали в ревью то, что ловилось бы автоматически. Второй урок касается ускоренных путей. У нас был отдельный быстрый маршрут для мелких правок от агента, откуда как раз пришли 2 самых неприятных инцидента года. Мы его закрыли: теперь проверки одни для всех.
Обсуждение:
Главное из блока: когда кода больше и часть его пишет машина, масштабируется только автоматическая проверка, поэтому ИИ-код проходит те же проверки, что и человеческий, без ускоренных путей. Решение о выкатке остаётся за человеком или детерминированной автоматикой, а линтер стоит настроить до внедрения. Дальше, в блоке 10, показано, что ИИ меняет после выкатки: инциденты, мониторинг, журналы.
Дальше блок 10 «Сопровождение и метрики»: Сопровождением называют всё, что начинается после выкатки: инциденты, мониторинг, журналы, трассировка.