После изменения политики хранения GitHub Actions: как хранить доказательства аудита Mac CI? 2026

Какие свидетельства затрагивает политика хранения GitHub Actions

С 1 октября 2026 года политика хранения GitHub Actions распространяется на проверки, запуски рабочих процессов и статусы коммитов. В объявлении GitHub также указано, что охватываются соответствующие проверки и статусы, созданные сторонними интеграциями. Следовательно, обзор только настроек артефактов или только встроенных запусков оставляет пробелы в аудиторском покрытии (объявление о расширении области хранения).

Главная задача — не считать весь след сборки одним «результатом CI». В GitHub отдельно представлены объекты проверок, статусы коммитов, сведения о запусках, журналы и файлы, загруженные как артефакты. Наличие записи с результатом проверки не подтверждает доступность журнала. Доступный журнал, в свою очередь, не гарантирует сохранность IPA, тестового отчёта или символов отладки.

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

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

Наконец, файл, который доступен для скачивания сейчас, не обязательно будет доступен в течение всего периода, требуемого внутренним аудитом. Документация GitHub описывает рабочие артефакты как файлы, связанные с запусками рабочих процессов; это отдельный класс от записей проверок и статусов (описание артефактов рабочих процессов). Поэтому перед выводом «всё хранится» уточните, какой именно объект проверяли.

Покрытие, прослеживаемость и применимость срока

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

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

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

Настройки хранения тоже нужно проверять по иерархии. Документация GitHub описывает настройки организации и возможность установить верхнее ограничение для хранения артефактов и журналов; репозиторий не должен рассматриваться как независимый от вышестоящей политики уровень (документация по настройке хранения в организации). Поэтому зафиксируйте одновременно эффективное значение, уровень, на котором оно задано, и наличие административного ограничения.

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

Порядок внедрения и проверки архива Mac CI

Шаг первый: зафиксируйте конфигурацию и владельцев

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

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

Шаг второй: постройте цепочку от выпуска к источникам

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

Для первичной сверки доступны команды GitHub CLI. Подставьте фактические значения владельца, репозитория и коммита; команды получают проверки и статусы отдельно:

gh api repos/OWNER/REPO/commits/COMMIT_SHA/check-runs
gh api repos/OWNER/REPO/commits/COMMIT_SHA/status

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

Пример структуры индекса, который команда может адаптировать под собственное хранилище:

repository: OWNER/REPO
commit: COMMIT_SHA
workflow_run: RUN_ID
release: RELEASE_ID
checks_export: archive/path/checks.json
statuses_export: archive/path/statuses.json
logs_archive: archive/path/logs/
build_artifacts: archive/path/artifacts/

Это иллюстрация структуры, а не схема, которую GitHub автоматически создаёт. Значения должны поступать из проверяемых записей, а путь вести к реально сохранённым объектам. Не используйте один только release как ключ поиска, если он не позволяет восстановить коммит и запуск, из которых получен результат.

Шаг третий: разделите выгрузку записей, журналов и файлов

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

В Mac CI к артефактам могут относиться архив приложения, тестовые результаты и символы отладки. Это не означает, что каждое хранилище должно получать все файлы без разбора: установите классы данных, права доступа, необходимую связь с выпуском и правила удаления, принятые в компании. Для каждого типа зафиксируйте ответственную команду и место, где проверяющий получит файл.

Не ограничивайтесь автоматизацией экспорта. Документация GitHub отдельно описывает удаление артефактов запуска; следовательно, в регламенте должны быть определены допустимые действия, владелец решения и порядок проверки того, что необходимые файлы уже сохранены (описание удаления артефактов рабочего процесса). Операция удаления и архивирование — разные процессы, даже если их выполняет одна команда.

Шаг четвёртый: установите, какой период покрывает каждый слой

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

При этом не делайте вывод, что увеличение срока автоматически восстановит старые записи или файлы. Сначала установите, что сохранилось сейчас, а затем измените политику для будущего покрытия. Уже удалённые данные потребуют другой доступной копии, если она была заранее создана; настройка хранения не служит механизмом восстановления (объявление GitHub).

Шаг пятый: проведите восстановление по идентификатору

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

Результат испытания оформите отдельной записью: что искали, по какому ключу, какие объекты нашли, кто проверил содержимое, какие права использовались и какие несоответствия обнаружены. Запись «экспорт завершился без ошибки» не подтверждает, что архив можно найти и восстановить после удаления исходного объекта с платформы.

Шаг шестой: разделите согласование, выполнение и контроль доступа

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

Доступ к архиву выдавайте по назначению. Проверяющему могут потребоваться данные запуска, но не секреты подписания приложения; оператору экспорта может понадобиться более широкий доступ, однако эти полномочия следует документировать и пересматривать по внутренней процедуре. Не копируйте секреты CI в архив ради полноты: свидетельство о результате и средство, которым подписывался выпуск, — разные категории данных.

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

Как подтвердить, что аудит действительно готов

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

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

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

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

Частые вопросы

Что может быть удалено после изменения политики хранения?

С 1 октября 2026 года политика распространяется на проверки, запуски рабочих процессов и статусы коммитов, в том числе связанные записи сторонних интеграций (официальное объявление). Журналы и артефакты следует проверять отдельно: наличие одного объекта не подтверждает, что остальные сохраняются или доступны.

Как оставить статусы и запуски в доказательной цепочке?

Сохраняйте сведения о проверках и статусах отдельно и связывайте их с коммитом, репозиторием, запуском и выпуском. Используйте API проверок и API статусов, затем помещайте экспорт в контролируемое хранилище с индексом. Отдельно проверьте журналы и файлы сборки: статус результата не заменяет их сохранение.

Восстановятся ли удалённые записи после увеличения срока хранения?

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

Как отдельно хранить журналы Mac CI, статусы и артефакты?

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

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