Conclusion rapide

Symptôme → une attestation est présente pour votre build iOS, mais l’équipe ne sait pas si elle valide le fichier livré ni le workflow utilisé.
Résolution la plus rapide → vérifiez la provenance et le condensat du fichier final avec gh attestation verify, puis contrôlez séparément les tests, la signature Apple et l’autorisation de publication.

La documentation GitHub décrit deux opérations à distinguer : générer une attestation et la vérifier sur l’artefact consommé (fonctionnement officiel des attestations). Ce nombre d’opérations ne constitue pas une garantie de sécurité complète. Une preuve de provenance peut aider à établir d’où vient un build ; elle ne prouve pas que le code est sûr, que les tests ont réussi ni que la signature ou la notarisation Apple est valide.

Qui devrait lire cette checklist ?
Les responsables CI d’entreprise qui doivent vérifier les artefacts iOS avant livraison.
Les responsables de sécurité de la chaîne logicielle qui définissent les sources de build approuvées.
Les ingénieurs de publication qui doivent relier provenance, tests, signature et archive.

Identité du dépôt et du commit

Commencez par déterminer quelle identité la preuve doit confirmer. Une attestation n’est utile à votre décision que si son dépôt et le commit associé correspondent au code approuvé pour cette publication. Comparez ces éléments à la révision effectivement sélectionnée par votre processus de livraison, et non à la branche par défaut ou à une exécution similaire.

Pour chaque build candidat, conservez une référence claire vers :

  • le dépôt attendu et son propriétaire ;
  • le commit exact utilisé pour compiler ;
  • le fichier destiné à être distribué ;
  • l’exécution du workflow qui a produit ce fichier.

La commande gh attestation verify permet de vérifier une attestation pour un artefact ; consultez la documentation officielle de vérification pour appliquer les options correspondant à votre contexte. Dans votre procédure, définissez explicitement le dépôt attendu plutôt que de considérer toute preuve techniquement valide comme acceptable.

Un résultat positif signifie que la vérification a établi les relations prévues par le mécanisme et les options utilisées. Il ne répond pas à votre question interne : « Avons-nous approuvé ce dépôt, ce commit et ce chemin de publication ? » C’est à votre politique de dire quels dépôts, branches, déclencheurs et workflows sont autorisés pour une livraison.

Condensat du fichier livré

La seconde mesure critique est le condensat du fichier. Il relie la preuve à un artefact précis, pas à une intention de livrer « la même application ». Comparez le fichier que votre équipe s’apprête à publier à celui qui a été associé à l’attestation. Le nom du fichier, le numéro de version ou le fait qu’il provienne du même build ne suffit pas à établir cette correspondance.

Ce contrôle est particulièrement important dans un flux iOS. Une archive peut être exportée après sa création, puis copiée vers un dépôt de diffusion ou un service de livraison. Si une étape transforme le fichier, l’attestation créée pour l’étape antérieure ne doit pas être présentée comme une preuve du fichier transformé sans vérification adaptée.

Avant d’accepter un artefact, répondez à ces questions :

  • Sur quel fichier exact l’attestation a-t-elle été générée ?
  • Le fichier remis au distributeur est-il identique à celui qui a été vérifié ?
  • Une exportation, une recompression ou un autre traitement a-t-il créé un nouvel artefact ?
  • L’identifiant de version et le condensat sont-ils enregistrés ensemble dans les éléments de livraison ?

La documentation Apple distingue l’archive Xcode et les opérations d’exportation dans son guide de distribution d’une application aux appareils enregistrés. Utilisez cette distinction pour définir le point de contrôle de votre chaîne : si la preuve concerne l’archive, contrôlez l’archive ; si le fichier distribué est un export distinct, vérifiez le fichier distribué selon la procédure retenue.

Point de vigilance : ne déduisez jamais la correspondance entre une archive et un export de leur seul nom. Votre dossier de publication doit indiquer quel fichier est couvert par chaque preuve et à quelle étape il a été créé.

Identité du workflow et règle de confiance

Une attestation doit aussi être reliée au workflow qui a produit l’artefact. Examinez le chemin du fichier de workflow, le dépôt où il réside et le mode de déclenchement de l’exécution. Une exécution lancée pour une demande de modification, une compilation de branche et un flux de publication ne représentent pas nécessairement le même niveau d’approbation.

Établissez une règle interne lisible. Par exemple, vous pouvez exiger que les artefacts distribués soient produits par un workflow de publication approuvé, depuis un dépôt autorisé et à partir d’un commit ayant franchi les contrôles de revue de votre organisation. Cette règle est la vôtre : GitHub peut fournir des éléments de provenance vérifiables, mais votre entreprise définit quels workflows sont dignes de confiance.

Lorsque votre conception s’appuie sur des workflows réutilisables, vérifiez la configuration et l’identité attendue au lieu de vous fier au seul intitulé affiché dans l’interface. GitHub documente des méthodes pour vérifier des attestations issues de workflows réutilisables. Reprenez les critères proposés par la documentation, puis comparez-les à vos propres références de dépôt et de workflow.

Une pratique utile consiste à enregistrer dans le compte rendu de publication le résultat de vérification et la décision d’acceptation. Si le workflow a changé, si son emplacement a été déplacé ou si son mode de déclenchement a évolué, réévaluez la règle avant d’autoriser la livraison suivante.

Éligibilité du dépôt et couverture réelle

Ne supposez pas que chaque dépôt de l’organisation peut produire et vérifier des attestations dans les mêmes conditions. Les fonctions disponibles peuvent dépendre du type de dépôt et des conditions applicables à l’offre ou à la configuration de l’organisation. Vérifiez la documentation GitHub sur les fonctions de sécurité et leur disponibilité pour votre cas précis.

L’acceptation doit tester séparément trois points : la génération de la preuve, son accès par le processus de contrôle et sa vérification au point de consommation. Un build réussi dans un dépôt pilote ne démontre pas que tous les dépôts de l’entreprise sont couverts, ni que les permissions et réglages sont identiques dans les dépôts privés et publics.

Dans votre inventaire, notez au minimum :

  • les dépôts pour lesquels la génération est activée ;
  • les types de workflows qui produisent des artefacts concernés ;
  • les équipes ou rôles autorisés à modifier ces workflows ;
  • les contrôles aval qui consomment l’attestation ;
  • les dépôts ou environnements qui restent hors périmètre.

Si une vérification doit se faire sans accès réseau au service, examinez les conditions et les limites du guide officiel de vérification hors ligne. Ne présentez pas le mode hors ligne comme équivalent à un contrôle distant sans valider les données, la provenance de la preuve et la procédure réellement employée.

Comparaison des décisions d’acceptation

Choisissez le niveau d’acceptation d’après le rôle du fichier et les conséquences d’une erreur. Ce tableau compare les choix de contrôle ; il ne remplace pas la politique de sécurité de votre entreprise.

Option Vérifications retenues Décision adaptée
Contrôle de provenance seul Dépôt, commit, workflow et condensat Utile pour établir l’origine déclarée ; insuffisant pour autoriser à lui seul une mise en production
Provenance avec contrôles CI Vérification de l’attestation et consultation des résultats de tests et de compilation À retenir lorsque l’équipe doit relier l’origine aux résultats du build sans confondre leurs rôles
Porte de publication complète Provenance, condensat du fichier livré, résultats de tests, signature, approbation et traçabilité À retenir pour les livraisons contrôlées, selon le niveau de risque et les exigences internes

Pour mettre ce choix en œuvre, appliquez une séquence opérable :

  • Sélectionnez un build iOS réel destiné à la distribution, pas seulement un exemple de compilation.
  • Identifiez le commit et le workflow qui doivent être considérés comme approuvés.
  • Générez l’attestation sur l’artefact défini dans votre procédure.
  • Vérifiez la preuve avec gh attestation verify et contrôlez l’identité du dépôt, du commit et du workflow.
  • Comparez le condensat à celui du fichier qui sera effectivement transmis.
  • Rassemblez séparément les résultats de test, la vérification de signature et l’approbation de publication.
  • Testez un cas d’échec : fichier différent, identité non approuvée ou preuve indisponible. Vérifiez que le blocage et son responsable sont explicites.

GitHub propose également une API REST pour les attestations de dépôts. Si un outil interne consomme les résultats via cette API, ajoutez à vos essais le cas où l’identité ou le fichier ne correspond pas aux critères attendus. Ne confondez pas le succès d’un appel d’API avec une décision de mise en production : cette dernière doit appliquer votre politique.

Résultats séparés des tests et de la signature

Une attestation de provenance répond principalement à une question d’origine : quel artefact est relié à quelles informations de compilation ? Elle ne prouve pas que le code ne contient pas de comportement malveillant, que les tests se sont exécutés correctement ou que leur couverture est suffisante. Elle ne valide pas non plus la signature Apple.

Traitez ces conclusions comme des contrôles indépendants. Le dossier de livraison doit pouvoir montrer le résultat de vérification de provenance, les rapports de tests, l’état de signature et l’autorisation de diffusion, sans les fusionner dans un statut unique qui masquerait les échecs. Pour les règles liées à la signature, appuyez-vous sur la documentation Apple relative aux services de signature de code.

La notarisation est également une étape distincte. La documentation fournie par Apple sur la notarisation des logiciels macOS avant distribution porte sur les logiciels macOS. Ne l’utilisez pas pour prétendre qu’une attestation prouve la notarisation d’une application iOS. Les exigences de signature et de distribution doivent être vérifiées selon le type de logiciel et le parcours de publication concerné.

Une façon robuste de présenter le statut à l’équipe de publication consiste à conserver des résultats nommés séparément : « provenance vérifiée », « tests acceptés », « signature vérifiée » et « publication autorisée ». Si l’un manque, le système ne doit pas afficher une acceptation globale ambiguë.

Questions fréquentes

Que vérifie concrètement gh attestation verify ?

La commande sert à vérifier la preuve associée à un artefact selon les options et les identités que vous lui demandez de contrôler. Votre procédure doit préciser le dépôt et le workflow attendus, puis traiter le résultat comme un élément de la décision. Une vérification réussie n’établit pas à elle seule que votre organisation fait confiance à cette source.

Une attestation suffit-elle à prouver qu’un build iOS a réussi ses tests ?

Non. Elle ne remplace pas les résultats de tests. Conservez les rapports et statuts de test comme éléments distincts, liés au commit et à l’exécution concernés. Si les tests échouent ou n’ont pas été exécutés, une provenance vérifiable ne rend pas l’artefact acceptable : la règle de publication doit bloquer ou demander une exception formellement approuvée.

Comment traiter un fichier exporté après la génération de la preuve ?

Déterminez d’abord si l’export est un nouvel artefact par rapport au fichier attesté. Comparez le condensat du fichier final à celui que la preuve couvre. Si la transformation change le fichier, ne supposez pas que la preuve initiale décrit aussi le résultat : définissez le point de génération de preuve voulu et vérifiez le fichier réellement livré.

L’attestation confirme-t-elle la signature ou la notarisation Apple ?

Non. Elle est destinée à la provenance du build. Vérifiez séparément la signature selon les règles Apple applicables à votre distribution. La notarisation évoquée par la documentation Apple concerne les logiciels macOS ; ne l’assimilez ni à une preuve de provenance ni à une validation automatique de la signature d’une application iOS.

Mise en production sur un Mac CI

Validez le dispositif sur un flux réellement utilisé par votre équipe : même dépôt, même workflow de publication, même type d’archive et mêmes étapes d’export que pour une livraison normale. Consignez le commit, le workflow identifié, le fichier contrôlé et son condensat. Faites ensuite échouer volontairement au moins un contrôle dans un environnement de test, afin de vérifier que l’artefact n’est pas autorisé par défaut et que le responsable de la revue sait quoi examiner.

L’attestation ne certifie pas l’environnement Mac qui a exécuté le build. Elle ne constitue ni une preuve de conformité du runner, ni une validation de ses accès, ni une garantie de séparation entre équipes. Si votre chaîne dépend d’un Mac dédié ou partagé, contrôlez indépendamment les comptes, les secrets, les permissions, l’isolation des tâches et la capacité de reprise. Une preuve valide ne corrige pas un runner dont les accès sont trop larges.

Dans un scénario créatif — par exemple une application iOS qui accompagne un outil audio ou vidéo — la cadence de livraison peut varier entre les builds d’aperçu et les versions distribuées. Définissez donc les artefacts concernés par l’obligation de vérification au lieu de traiter indistinctement chaque export de travail et chaque archive de publication. Cette règle réduit les ambiguïtés sans prétendre que l’attestation remplace les validations produit.

Si votre équipe compare un runner hébergé par elle-même à un Mac distant, vérifiez d’abord la charge réelle, les besoins d’accès physique et les règles internes sur les données. Vous pouvez consulter les informations de Mac mini distant proposées par MACCOME pour évaluer si un Mac hébergé correspond à votre étape de compilation. Ne déduisez pas de cette option que les attestations sont générées ou vérifiées automatiquement : ces contrôles restent à configurer et à accepter dans votre propre chaîne.

La solution en place peut entraîner des contraintes concrètes : achat de matériel immobilisé, maintenance et renouvellement à votre charge, ou capacité qui reste inutilisée entre deux pics de compilation. Un Mac distant peut éviter de posséder une machine pour un besoin temporaire ou variable, mais il ne convient pas nécessairement à une charge lourde et continue, à un besoin d’interface physique ou à une politique qui impose la maîtrise locale du matériel. Lorsque le build iOS exige réellement un hôte Mac et que vous souhaitez tester une capacité sans engager immédiatement un achat, comparez les conditions d’accès et de livraison de MACCOME à vos exigences d’isolation et d’exploitation, puis appliquez la même checklist d’acceptation à votre runner.