CI/CD как цифровое доказательство: журналы сборки и развёртывания

Журналы CI/CD могут подтвердить, какой коммит был собран, какие проверки выполнялись, какой программный артефакт получен и когда он был развёрнут. Для суда важен не отдельный снимок интерфейса, а проверяемая цепочка от исходного кода до рабочей версии программы.

Что такое CI/CD и почему его данные становятся доказательствами

CI/CD - это автоматизированный процесс проверки, сборки и доставки программы. После изменения исходного кода система запускает задания, выполняет тесты, формирует пакет или контейнер и передаёт его в тестовую либо производственную среду.

В споре между заказчиком и разработчиком эти события помогают восстановить фактическую историю проекта. По ним можно исследовать, существовала ли спорная версия на определённую дату, из какого кода она собрана, кто запустил процесс и какой результат был опубликован.

Когда нужна экспертиза журналов сборки

• подрядчик заявляет о готовности функции, но заказчик отрицает её передачу;
• рабочая программа отличается от переданного исходного кода;
• необходимо установить дату создания или публикации версии;
• после релиза возникла уязвимость, потеря данных или нарушение работы;
• стороны спорят об авторстве изменений и объёме выполненных работ;
• нужно определить, какой сотрудник или сервис запустил развёртывание;
• исследуется возможная подмена пакета, зависимости или контейнера.

Какие данные сохраняет конвейер

Как связать коммит с рабочей версией программы

Надёжная связь строится по нескольким независимым признакам. Идентификатор коммита сопоставляют с событием запуска, конфигурацией задания и журналом сборки. Затем проверяют имя, версию и контрольную сумму созданного артефакта, запись в реестре и событие развёртывания.

Если приложение показывает номер версии, его также сопоставляют с содержимым пакета, метаданными и серверными журналами. Одного совпадающего названия недостаточно: файл можно переименовать, а тег репозитория - перенести.

Почему снимка экрана из CI/CD недостаточно

Снимок показывает лишь отображение страницы в конкретный момент. Он не содержит полного журнала, технических заголовков, связей между объектами и сведений о способе получения. Изображение можно обрезать или изменить, а часть интерфейса может формироваться динамически.

Предпочтителен штатный экспорт, дополненный исходными файлами, контрольными суммами и описанием процедуры получения. Если доступ к системе ещё сохранён, целесообразно зафиксировать навигацию между репозиторием, запуском, артефактом и развёртыванием.

Что проверить в конфигурации GitHub Actions и других систем

1. Триггер запуска. Какое событие активировало процесс: push, запрос на слияние, тег, расписание или ручная команда.
2. Версии внешних компонентов. Использовались ли неизменяемые ссылки или теги, содержание которых могло измениться.
3. Права токена. Могло ли задание изменять код, выпускать пакеты и обращаться к производственной среде.
4. Защиту окружений. Требовалось ли согласование перед развёртыванием и кто его выполнил.
5. Секреты. Не раскрывались ли токены в журналах и какие внешние системы были доступны.
6. Происхождение исполнителя. Использовался облачный или собственный runner и можно ли проверить его состояние.
7. Хранение результатов. Как долго доступны журналы, артефакты и сведения о действиях пользователей.

Как сохранить данные без изменения исходной картины

До активных действий определяют объём и способ фиксации. Простое повторное выполнение задания создаст новые события и может перезаписать артефакты. Поэтому сначала сохраняют существующие сведения, а экспериментальную сборку проводят отдельно.

• отключите автоматическое удаление значимых журналов и пакетов;
• экспортируйте данные штатными средствами платформы;
• сохраните исходные форматы и сопроводительные метаданные;
• рассчитайте контрольные суммы полученных файлов;
• зафиксируйте учётную запись, время и последовательность действий;
• не публикуйте в отчёте действующие секреты и персональные данные;
• работайте с копией репозитория и отдельной тестовой средой.

Какие ограничения нужно учитывать

Запись об успешной сборке не доказывает, что программа работала без ошибок. Успешное развёртывание также не подтверждает, что весь трафик был немедленно направлен на новую версию. Между артефактом и работающим экземпляром могли находиться кэш, балансировщик, оркестратор и ручные операции администратора.

Облачная платформа хранит только предусмотренный ею набор данных и может удалять старые журналы. Собственный runner способен использовать локальные файлы, не отражённые в репозитории. Переменные и секреты часто скрываются, поэтому воспроизводимость требует отдельной проверки.

Какие вопросы поставить перед экспертом

• какой версии исходного кода соответствует представленный артефакт;
• какие этапы и команды использовались при его создании;
• имеются ли признаки изменения журнала, пакета или конфигурации;
• можно ли воспроизвести сборку из зафиксированного коммита;
• какая версия была развёрнута в указанной среде и когда;
• какие учётные записи участвовали в запуске и согласовании;
• могли ли внешние зависимости изменить результат без изменения репозитория.

Какие материалы передать на исследование

Подготовьте копию репозитория с историей, файлы конфигурации CI/CD, экспорт журналов, артефакты и их контрольные суммы, данные реестра пакетов, сведения о среде и документацию проекта. Полезны также договор, техническое задание, акты, переписка и точный перечень спорных версий и дат.

Исследование CI/CD обычно проводится вместе с экспертизой исходного кода и истории Git, экспертизой программного обеспечения и, при наличии инцидента, аудитом информационной безопасности. Для проектов, созданных с применением генеративных инструментов, используйте также чек-лист аудита после разработки с ИИ.