Comment vérifier les artefacts de build iOS de GitHub Actions ? Liste de contrôle entreprise 2026

Pour un artefact iOS destiné à la production, liez la preuve de provenance au fichier réellement livré, puis vérifiez le dépôt, le workflow, le commit et la signature Apple : aucun de ces contrôles ne remplace les autres. Cette méthode convient aux équipes capables de relier chaque publication à un workflow autorisé et de conserver les preuves de validation.

Responsables sécurité : vous devez définir les règles de provenance et les motifs de refus.
Responsables plateforme : vous devez produire des preuves vérifiables depuis GitHub Actions et le nœud Mac.
Responsables de publication iOS : vous devez relier l’archive, l’export, la signature et le fichier effectivement distribué.

La première décision consiste à préciser quel fichier fait foi. Une compilation de test, une archive Xcode intermédiaire et un paquet remis aux utilisateurs n’ont pas la même fonction. La preuve doit porter sur l’artefact de livraison, ou sur une transformation clairement documentée qui permet de relier l’objet attesté à cet artefact. Une preuve valide pour une archive antérieure ne suffit donc pas à établir l’origine d’un fichier modifié ensuite.

Nous recommandons d’établir une chaîne explicite entre le dépôt, le commit, l’exécution du workflow, l’artefact produit, les contrôles de signature et l’approbation de publication. Chaque transition doit avoir un responsable et une trace consultable. Si une étape produit un nouveau fichier — export, assemblage, reconditionnement ou signature — le processus doit préciser quel objet est désormais soumis à validation.

La documentation de GitHub sur les attestations d’artefacts décrit leur usage comme preuves de provenance associées à un artefact. Ces attestations documentent notamment le contexte de production et le sujet concerné ; elles ne certifient pas que le code est sans vulnérabilité ni que le produit respecte les exigences de l’entreprise. Cette limite doit figurer dans la politique de publication, et pas seulement dans la documentation technique.

Que peut-on vérifier avec une preuve de provenance générée par GitHub Actions ?
Elle permet de confronter l’identité du dépôt, le commit et le contexte du workflow aux règles définies par l’organisation, puis d’examiner à quel sujet la preuve se rapporte. Elle ne démontre pas à elle seule que les dépendances sont sûres, que les tests couvrent les risques métier ou que la signature Apple est valide. Nous traitons donc la provenance comme une pièce de la décision, et non comme un verdict de sécurité.

Pour séparer les usages, définissez des politiques distinctes pour les builds de validation et les publications de production. Les premiers peuvent être utiles aux essais internes, mais ne doivent pas hériter automatiquement du statut d’un paquet approuvé pour diffusion. Le nom du fichier ou sa présence parmi les artefacts d’un workflow ne constitue pas une preuve suffisante de son statut.

Le responsable de la plateforme doit rendre la génération reproductible et limiter les droits du workflow au besoin réel. Le guide GitHub consacré à la génération et à la vérification des attestations documente les permissions nécessaires, les conditions d’utilisation et les étapes de configuration. Dans le fichier de workflow, les permissions dédiées comprennent id-token: write et attestations: write ; les accès au contenu du dépôt doivent rester limités à ce qu’exige le job. La documentation officielle décrit les autorisations et leur rôle.

Une configuration permissive à l’échelle de tout le workflow augmente la portée d’une compromission éventuelle. Nous préférons accorder les autorisations au job qui produit la preuve, plutôt que d’en faire des droits implicites disponibles à chaque étape. Il faut aussi vérifier quelles actions et quels outils peuvent lire ou modifier les artefacts avant leur attestation. La preuve ne résout pas un problème de confiance si un processus non maîtrisé peut remplacer le fichier avant que celui-ci soit désigné comme sujet.

Quelles conditions de plan faut-il vérifier pour un dépôt privé ?
L’accès à la fonctionnalité dépend du type de dépôt et du plan GitHub associé. La documentation officielle précise les conditions applicables aux dépôts publics et privés ; avant le déploiement, l’administrateur doit vérifier la règle correspondant au plan réellement utilisé, plutôt que de déduire la disponibilité depuis un test mené dans un dépôt public. Les droits d’accès à l’API d’attestations sont également décrits dans la référence de l’API GitHub. Si le plan ne permet pas le flux attendu, le résultat n’est pas « preuve vérifiée » : il faut choisir une méthode approuvée par l’organisation ou différer la mise en production.

L’équipe doit ensuite décider comment gérer les workflows réutilisables. GitHub présente des recommandations pour renforcer la sécurité des workflows qui génèrent des preuves, notamment concernant la confiance accordée aux actions réutilisées. Les recommandations GitHub sur les workflows réutilisables et les attestations sont à examiner avant d’autoriser un modèle partagé à produire des preuves utilisées pour des publications sensibles.

À chaque modification du workflow, la plateforme conserve la version de la définition exécutée, le lien vers son exécution et l’identité du fichier attesté. Un nom de workflow stable, pris isolément, ne prouve pas que son contenu était autorisé au moment de la compilation. La règle de contrôle doit tenir compte de la provenance réelle de l’exécution et des changements approuvés.

Le responsable sécurité transforme les informations de provenance en critères d’admission. Une attestation ne décide pas à votre place si un commit est approuvé : l’organisation doit préciser quels dépôts, branches, contextes d’exécution et workflows peuvent produire des artefacts de production. La vérification doit interroger ces règles, et non se limiter à constater qu’une preuve existe.

Nous conseillons de définir une liste de résultats bloquants avant l’activation de la chaîne. Un dépôt inattendu, un commit qui ne correspond pas à la révision approuvée, un workflow non autorisé ou une preuve absente doit entraîner un refus ou une procédure d’exception consignée. Un écart ne doit pas être contourné par une approbation informelle dans un canal de discussion.

Pour éviter que l’équipe confonde intégrité de provenance et innocuité, associez le contrôle à des revues distinctes : analyse des dépendances, tests pertinents, examen du code et validation des changements à privilèges. La provenance décrit le chemin de production déclaré et vérifiable. Elle ne prouve pas que les dépendances n’ont pas de vulnérabilité, que le code ne contient pas de comportement malveillant ou que les secrets de signature ont été protégés pendant toutes les opérations.

Comment confirmer que le paquet iOS correspond au bon dépôt et au bon commit ?
Comparez les identifiants figurant dans la preuve aux sources de vérité internes : dépôt attendu, révision autorisée, workflow approuvé et demande de publication correspondante. Reliez ensuite cette vérification à l’empreinte de l’artefact qui sera remis. Si la preuve référence une archive alors que le fichier publié est un export différent, exigez une relation vérifiable entre les deux objets ou refusez le paquet. Un intitulé de version identique ne démontre pas cette correspondance.

Les équipes qui publient depuis plusieurs branches doivent également préciser les contextes de déclenchement autorisés. Un workflow déclenché depuis une branche de travail n’a pas nécessairement le même niveau d’approbation qu’un workflow de publication contrôlé. La politique doit décrire les circonstances qui permettent une mise en production et l’identité de la personne ou du groupe habilité à lever une exception.

Pour la publication iOS, la preuve GitHub et la validation Apple couvrent des questions différentes. La première porte sur l’origine déclarée du fichier et son processus de production. La seconde concerne notamment la signature du logiciel et le chemin de distribution prévu. Les documents Apple sur la distribution avec Xcode décrivent les processus d’archivage et de distribution ; la chaîne interne doit conserver les résultats correspondant à la méthode de livraison choisie.

La preuve de provenance peut-elle remplacer la vérification de la signature Apple ?
Non. Vérifiez séparément la signature avec les contrôles prévus pour le mode de distribution, puis associez le résultat au fichier final. Les documents Apple relatifs au format de signature de code expliquent les éléments de signature à prendre en compte. Une attestation de provenance ne prouve pas qu’une signature est valide, et une signature valide n’établit pas à elle seule que le fichier provient du commit approuvé.

Le responsable de publication doit préserver le lien entre l’archive Xcode, le processus d’export, la signature et le fichier transmis au canal de distribution. Les instructions Apple pour distribuer une app sur des appareils enregistrés distinguent elles aussi les opérations d’archivage et d’export de la distribution. Si le paquet est modifié après l’attestation ou la vérification de signature, les contrôles doivent être repris sur le nouvel objet, ou le processus doit fournir une preuve de transformation admise par la politique.

Pour une livraison d’entreprise, le dossier doit permettre à un réviseur de répondre clairement à ces questions : quel fichier a été signé, quelle identité de signature a été vérifiée, quel profil ou mode de distribution s’applique, et le fichier transmis est-il bien celui qui a passé ces contrôles ? Si l’un de ces liens ne peut pas être établi, l’équipe ne doit pas convertir l’incertitude en approbation.

Le responsable d’audit ne devrait pas devoir reconstituer la publication à partir de souvenirs ou de journaux dispersés. Pour chaque mise en production, rassemblez les éléments utiles dans un dossier rattaché à la demande de changement :

• L’identifiant du dépôt, le commit approuvé et la référence de la demande de publication.
• La preuve de provenance et l’identification exacte de l’artefact auquel elle se rapporte.
• Le lien vers l’exécution du workflow, sa définition et les résultats de vérification.
• La version exportée, l’identité de signature attendue et le résultat des contrôles Apple.
• Les éléments qui relient l’objet vérifié au fichier effectivement remis.
• La décision d’approbation, ses responsables et le traitement documenté des écarts.

Lors d’un contrôle ponctuel, demandez à une personne qui n’a pas exécuté la publication de remonter du fichier livré jusqu’au commit et à l’approbation. Si elle ne peut pas retrouver la preuve, distinguer l’archive de l’export ou expliquer une exception, le dossier n’est pas exploitable pour l’audit. Cette revue teste la qualité du processus sans confondre la disponibilité de journaux avec une traçabilité démontrée.

Pour décider de l’admission d’un nœud Mac à la production, examinez également les identités autorisées à lancer le travail, l’accès aux secrets de signature, la séparation entre compilation et signature et la conservation des traces après incident. Nous ne recommandons pas de valider un nœud uniquement parce qu’un workflow réussit sur un cas nominal. Le test doit suivre le chemin réellement emprunté par une publication et confirmer que les preuves restent disponibles après une interruption ou une reprise.

Liste de contrôle de décision avant toute publication

Cochez chaque point à partir des traces conservées, et non d’une déclaration orale. Une case non cochée bloque la publication si elle concerne l’identité de l’artefact, la provenance ou la signature.

• [ ] Le fichier soumis à la livraison est identifié sans ambiguïté et distingué des builds de test.
• [ ] La preuve de provenance référence le fichier final, ou une transformation documentée relie l’objet attesté au fichier livré.
• [ ] Le dépôt et le commit correspondent à la révision approuvée pour cette publication.
• [ ] Le workflow et son contexte de déclenchement sont autorisés par la politique de production.
• [ ] Les permissions du job qui génère la preuve sont limitées au besoin et conformes aux exigences du plan utilisé.
• [ ] La signature Apple a été vérifiée séparément et le résultat concerne le même fichier que celui transmis.
• [ ] L’approbation, les éventuelles exceptions et les responsables sont consignés dans le dossier de publication.
• [ ] Une personne indépendante peut reconstituer le lien entre paquet livré, preuves, source et décision.

Appliquez ensuite les conditions de décision suivantes :

• Si toutes les cases sont cochées et que les éléments concordent, autorisez la publication et archivez le dossier.
• Si la provenance est correcte mais que la signature ou le lien avec le fichier livré manque, suspendez la livraison jusqu’à validation du responsable iOS.
• Si le dépôt, le commit ou le workflow ne respecte pas la règle, refusez l’artefact et faites examiner l’écart par la sécurité et la plateforme.
• Si le plan utilisé ne permet pas de produire ou de vérifier la preuve attendue, ne déduisez pas une conformité implicite : adoptez une méthode approuvée ou différez l’admission du flux.
• Si l’équipe ne peut pas maintenir la traçabilité après une modification du paquet, gardez le processus en préproduction et corrigez la chaîne avant d’augmenter son périmètre.

Cette décision attribue à chaque fonction un droit de refus circonscrit : la plateforme répond de la configuration et de la preuve, la sécurité des règles d’admission, la publication de la signature et de l’objet distribué, et l’audit de la capacité à reconstituer le dossier. Le but n’est pas d’ajouter une validation sans responsable, mais de rendre les désaccords visibles avant qu’un paquet ne quitte le circuit approuvé.

Une chaîne de publication rigoureuse dépend enfin du nœud Mac qui exécute les tâches sensibles. Une machine achetée par l’entreprise offre un contrôle physique utile, mais implique immobilisation du capital, maintenance locale et continuité à organiser en cas de panne. Un environnement distant déjà exploité par l’équipe peut réduire ces obligations matérielles, mais il faut alors contrôler avec la même attention les accès, l’isolation des secrets et la conservation des preuves. Nous présentons les modalités d’accès à un Mac distant sur la page de JEXCLOUD et les options de mise à disposition sur la page de commande.

Si votre équipe doit tester une chaîne de signature, absorber une charge temporaire ou évaluer un nœud de publication avant un achat, la location d’un Mac par JEXCLOUD peut offrir un environnement distant sans acquisition immédiate d’une machine. Elle ne remplace ni la politique de signature ni votre audit : vérifiez d’abord que les accès et les traces répondent à vos exigences. À l’inverse, pour une charge durablement élevée, une dépendance à des interfaces physiques particulières ou une exigence de maîtrise matérielle stricte, l’achat et l’exploitation internes peuvent être plus adaptés. Le choix doit suivre vos contraintes opérationnelles, tandis que chaque livraison reste soumise à la même chaîne de preuves.