Симптом: attestation для сборки есть, но непонятно, можно ли выпускать файл.
Быстрое решение: проверьте источник, утверждённый workflow и хеш именно передаваемого артефакта; тесты и подпись Apple принимайте отдельно.

Этот порядок подходит, если ваша команда выпускает iOS-приложение через GitHub Actions и должна зафиксировать проверяемое происхождение сборки. Он не заменяет внутреннюю оценку рисков и не устанавливает, каким workflow ваша организация обязана доверять.

Кому пригодится:
Руководителю CI — чтобы встроить проверку происхождения в приёмку iOS-артефактов.
Специалисту по безопасности цепочки поставок — чтобы определить границы доказательства.
Инженеру выпуска — чтобы связать источник, результат проверки и файл, уходящий на публикацию.

Разделите происхождение и качество сборки

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

Не сводите в один статус четыре разных решения:

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

Если команда записывает всё это как «проверено», позже будет трудно понять, какой именно контроль сработал. Храните результаты раздельно, даже если они сходятся в одном решении о выпуске.

Для iOS-проекта важно также не смешивать разные файлы. Архив, экспортированный IPA и файл, переданный в следующий этап, могут быть разными объектами. Apple отдельно описывает этапы архивации и экспорта приложения в руководстве по распространению на зарегистрированные устройства. Ваша политика должна указывать, на каком именно объекте создаётся attestation и какой объект проверяется перед передачей.

Сверьте метрики приёмки до запуска проверки

Сначала определите, что считается допустимым результатом. Настройте критерии для конкретного репозитория и выпуска, а не для «любого workflow, который завершился успешно». Официальная документация GitHub поясняет проверку аттестаций; организационный список доверенных источников и workflow при этом остаётся вашей политикой.

Вариант решения Что проверяется Когда подходит
Принять происхождение Источник, идентичность workflow и соответствие хеша проверяемому файлу Все ожидаемые поля совпали с утверждённым путём сборки
Остановить выпуск Источник неизвестен, workflow не одобрен или подтверждение отсутствует Нельзя доказать, что файл прошёл ожидаемый процесс
Отправить на разбор Доказательство есть, но файл преобразовывали или цепочка передачи неясна Нужны повторная проверка и решение ответственного
Разрешить только следующий контроль Происхождение подтверждено, но другие ворота ещё не пройдены Тесты, подпись или выпускная проверка выполняются отдельно

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

Проверьте готовность репозитория и потребителя

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

Затем разделите испытание на независимые части:

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

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

Зафиксируйте личность источника и рабочего процесса

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

Для каждого выпуска сверяйте:

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

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

Для потребительской проверки используйте документированный инструмент gh attestation verify и зафиксируйте контекст, в котором его вызвали. Начните с конкретного файла и ожидаемого репозитория; сверяйте ответ команды с вашими правилами, а не только с кодом завершения. В документации GitHub по REST API аттестаций отдельно описаны ограничения и условия работы с доказательствами через API. Если проверка выполняется в среде с ограниченным доступом к сети, изучите официальное руководство по автономной проверке и заранее определите, как доставляются необходимые данные.

Проведите проверку по файлу, а не по названию сборки

Главный риск на этом этапе — проверить один объект, а выпустить другой. Для приёмки идентифицируйте артефакт по криптографическому хешу, например SHA-256, и сравните значение с тем, к которому привязано доказательство. Имя файла и номер задания помогают человеку ориентироваться, но не заменяют сравнение содержимого.

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

В процедуре должны быть указаны:

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

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

Сценарий для выпуска iOS-приложения

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

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

Устройте сквозное испытание перед допуском в выпуск

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

  • Выберите задачу. Возьмите тип сборки, который действительно используется для выпуска приложения. Запишите репозиторий, ревизию и ожидаемый конечный файл.
  • Проверьте условия репозитория. Сверьте применимость функции с актуальными требованиями GitHub для данного проекта и организации. Зафиксируйте результат, чтобы не распространять его на непроверенные репозитории.
  • Проведите сборку. Выполните утверждённый workflow и убедитесь, что доказательство создаётся для ожидаемого артефакта. Запишите, какой запуск и какая ревизия кода относятся к файлу.
  • Проверьте происхождение. Выполните gh attestation verify для файла на согласованной границе передачи. Сопоставьте источник и идентичность workflow со списком, утверждённым вашей организацией.
  • Сверьте содержимое. Сравните хеш файла с данными, привязанными к подтверждению. Если файл менялся после создания attestation, повторите процедуру для итогового объекта или отправьте его на разбор.
  • Проверьте остальные ворота. Отдельно подтвердите тесты, внутренние проверки, подпись и выпускное одобрение. Сохраните ссылки на результаты рядом, но не объединяйте их смысл в один статус.
  • Испытайте отказ. Проверьте, что происходит при отсутствующем доказательстве, неизвестном workflow и несовпадении хеша. Система должна задержать релиз и назначить ответственного за разбор.

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

Ответьте на вопросы перед включением в политику релиза

Как проверить происхождение файла через GitHub Artifact Attestations?

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

Что доказывает attestation в iOS CI?

Она помогает связать артефакт с доказательством происхождения и проверить сведения об источнике сборки. Она не является отчётом о тестировании и не заменяет анализ кода или внутреннее одобрение. Для iOS-приложения сохраняйте отдельные результаты тестов и проверки подписи, чтобы каждый статус отвечал на конкретный вопрос.

Как удостовериться, что подтверждение относится к файлу для выпуска?

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

Заменяет ли Artifact Attestations подпись или нотариальную проверку Apple?

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

Закрепите результаты и определите границы Mac-среды

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

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

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

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