症状：リリース候補のIPAにattestationが付いていても、それだけでは配布可否を決められません。
最速の対処：GitHub Artifact Attestationsで構築元と成果物のダイジェストを検証し、テスト・Appleの署名・配布承認は別の門番として確認してください。

企業のiOS CI、ソフトウェアサプライチェーン、リリース工程を担当し、受け入れ基準を整えたい方向けです。
CI担当者は構築経路を、安全担当者は証明の範囲を、リリース担当者は成果物の照合手順を確認できます。

まず受け入れ対象を分ける

GitHub Artifact Attestationsは、構築成果物の出所を示し、消費するソフトウェアの出所を検証するための仕組みです。証明の検証に成功しても、コードが安全であること、テストに合格したこと、Appleの署名や公証が有効であることまでは保証されません。GitHubの機能説明でも、主な役割は成果物のprovenance（来歴）の作成と検証として説明されています。

受け入れ判定では、異なる確認結果をひとつの「合格」にまとめないでください。少なくとも、構築元、対象ファイル、ワークフローの信頼性、テスト結果、Appleの署名、リリース承認をそれぞれ記録します。

選択肢・確認項目 確認できること 単独では確認できないこと 受け入れ判断
Artifact Attestations 証明対象と構築元の情報、想定したリポジトリやワークフローとの整合性 コードの安全性、テスト合格、Appleの署名 信頼する構築経路と一致した場合に、来歴確認の証拠として採用
CIテスト記録 実行したテストとその結果 証明対象のファイルが配布対象と同一か 対象コミットと実行結果を照合
Appleの署名確認 Appleの署名・配布関連要件に関する状態 GitHub上の構築元や承認済みワークフロー 配布用ファイルを別途検証
リリース承認 組織内の公開判断と責任者 構築元やファイルの同一性 来歴・テスト・署名の記録を確認して承認

注意：attestationの存在を「社内で承認済みのビルド」と読み替えないでください。信頼するリポジトリとワークフローは組織側で定義します。

第一段階：リポジトリとコミットを照合する

最初に確認するのは、証明が指す構築元と、リリース申請で指定したコードの版が一致していることです。リポジトリ名だけでは不十分です。実際に使ったコミットと、リリースフローが承認したコード版を照合します。

GitHub公式の検証手順に沿って、検証対象のファイルとリポジトリを明示します。GitHub CLIを使う場合、基本形は次のとおりです。

gh attestation verify ./path/to/artifact -R OWNER/REPOSITORY

OWNER/REPOSITORYは実際の対象リポジトリに置き換えます。検証結果から、証明の出所がリリース対象のリポジトリと一致するか確認してください。必要に応じて、再利用可能なワークフローの検証に関するGitHubの説明も参照し、想定している検証条件を組み立てます。

第二段階：配布するファイルのダイジェストを合わせる

検証の対象は、「同じアプリの別ファイル」ではなく、配布に回す実ファイルである必要があります。Xcodeでアーカイブを作成した後、書き出しや再パッケージ化を行った場合、処理前後のファイルを同一の検証対象として扱わないでください。

チーム内で、attestationをどの段階のファイルに付けるか決めます。たとえば、アーカイブを作った時点のファイルを対象にするのか、配布用に書き出したIPAを対象にするのかをCIの記録に残します。検証では、attestationに結び付いたダイジェストと、実際にアップロードまたは引き渡すファイルのダイジェストが一致することを確認します。

Appleのアーカイブと書き出しの説明を踏まえ、アーカイブ、エクスポート、配布の各段階を取り違えないようにしてください。ファイルを書き換えた後も以前の証明がそのまま配布物を表す、と仮定してはいけません。

リリース時の確認記録には、検証したファイルの識別情報と、構築に使ったコミットを一緒に残します。後から別のIPAを検証済みファイルと取り違えないためです。

第三段階：ワークフローの信頼性と利用条件を確認する

証明の出所が正しいリポジトリでも、その実行経路が社内で承認されたものとは限りません。ワークフローのファイル位置、トリガー、リポジトリの場所、実行条件を確認し、チームで許可した構築経路に当てはまるか審査します。

「証明が有効」と「そのワークフローを信頼する」は別の判断です。信頼するワークフローの一覧は、組織の変更管理やリリース方針に合わせて定義してください。設定変更や手動実行を許可する範囲も、公開フローと照らして確認します。

GitHub Actionsで証明を生成する前に、リポジトリの可視性や組織プランなど、対象リポジトリが現在の利用条件を満たすか確認します。資格や利用条件は公式資料を参照し、GitHubのセキュリティ機能に関する案内で対象リポジトリごとに確認してください。ひとつのリポジトリで生成に成功したことを、組織内のすべてのリポジトリで利用できる根拠にはしないでください。

検証をREST APIで組み込む場合も、検証対象とAPIの扱いを実装前に確かめます。GitHub REST APIのattestation資料を確認し、APIから取得できた証明を、署名やポリシーの検証まで完了した証拠として扱わないようにします。必要な検証処理を消費側で実行し、その結果を保存してください。

iOSリリースの実データで判定する

たとえば、リリース担当者が配布用IPAを受け取った後、CIがアーカイブ段階の別ファイルに付けたattestationだけを検証していたとします。構築元の確認が成功しても、検証したファイルと配布対象の一致は立証できません。この場合は、配布対象ファイルを検証する工程を追加するか、どのファイルが証明の対象か分かるように工程と記録を改めます。

導入時は、実際のiOSリリース経路で以下を順に実施します。

  1. 本番と同じリポジトリ、ブランチ、ビルド経路で対象タスクを選びます。
  2. ビルドで使ったコミットとワークフローの場所・起動条件を記録します。
  3. attestationの対象ファイルと、配布予定のファイルを明示します。
  4. gh attestation verifyで対象を検証し、構築元が承認済みの経路か確認します。
  5. ダイジェストの一致を確かめ、ファイルの書き出しや再パッケージ化の有無を記録します。
  6. CIテスト、Appleの署名確認、リリース承認を別の証拠として照合します。
  7. 検証失敗時の停止、担当者への通知、例外承認の条件を決めてからリリース経路へ組み込みます。

Appleのコード署名は、構築元のattestationとは別に確認します。Appleのコード署名サービスに関する資料を参照してください。また、公証はmacOSソフトウェアの配布に関するプロセスです。Appleの公証手順を確認し、iOSアプリの署名確認やGitHubの来歴証明の代替として扱わないでください。

よくある判断のずれをFAQで確認する

GitHub Artifact Attestationsで構築元を確認するには、何を照合すればよいですか？
検証対象のファイルを指定してgh attestation verifyを実行し、出力されたリポジトリやワークフローの情報を、リリース経路の記録と照合します。検証が成功しただけで放行せず、組織が承認したワークフローかも確認してください。

iOS CIの成果物に付くattestationは、何を証明しますか？
成果物に結び付いた構築元の情報を検証するための証拠です。コードが安全であること、テストが成功したこと、Appleの配布要件を満たすことまでは示しません。それぞれ別の検査として記録します。

attestationが今リリースするIPAと同じファイルを指すか、どう確認しますか？
証明を付けたファイルと配布対象を明らかにし、検証時にダイジェストを照合します。アーカイブからの書き出しや再パッケージ化がある場合は、処理後のファイルを検証対象にするか、証明対象との関係を記録してください。

Artifact Attestationsの検証でAppleの署名や公証も確認できますか？
確認できません。attestationは構築元の来歴に関する仕組みです。iOSアプリの署名と配布確認はAppleの手順で別途行い、macOS向けの公証も対象ソフトウェアに応じて独立して扱います。

運用に組み込むときの停止条件を決める

証明の取得・検証、ダイジェスト照合、テスト、署名確認のどれかが失敗したときに、誰が公開を止め、誰が例外を承認するかを事前に定めます。証明がない成果物を許容する場合も、例外理由、対象リリース、承認者を記録してください。

検証の証拠は、attestationの出力だけに限定しません。対象ファイル、コミット、ワークフロー情報、テスト結果、署名確認、例外処理をひと続きのリリース記録として保管します。証明の有効性と、社内ポリシー上の信頼判断を分けておけば、検証成功を過剰に解釈せずに済みます。

Mac CIを含むリリース経路を別に受け入れる

Artifact Attestationsは、構築元の来歴を示す仕組みであり、CIを実行するMacのアクセス権、分離、運用可用性まで認定するものではありません。Mac上でビルドする必要がある場合は、ランナーの権限や実行環境を別の受け入れ対象として評価してください。

既存のMacを専有すると、稼働状況の監視、保守、容量の確保が自社側に残ります。一般的なクラウド実行環境だけで済ませる構成では、iOSのMac固有工程をそのまま担えない場合があります。公開対象が少なく、Macを常時必要としないチームなら、購入前に必要な実行時間や同時実行数を見積もり、Mac CIの実行環境を検討するためのMACCOME案内も比較対象にできます。Mac miniの運用を検討する場合は、Mac miniの利用案内で提供条件を確認し、証明機能とホスト環境の機能を混同しないでください。

リリース頻度が高く、一定のMac容量を継続して使い、物理機器や専用接続が必要なら、自社保有も候補になります。一方、短期の検証や変動するCI負荷であれば、必要な期間だけMacを使う選択肢を比べる余地があります。Macを必要とする工程の実行環境を追加したい場合に限り、MACCOMEのリモートMacについて、実際のアクセス方法や受け渡し条件を確認してから判断してください。