Swift 6.4 SwiftPM : intégrer une SBOM au CI macOS ? 2026

Le 15 septembre 2026, Swift 6.4 a été publié avec une fonction de génération de SBOM intégrée à SwiftPM, selon les notes de version officielles de Swift.

Symptôme : une compilation macOS réussit, mais la liste de composants n’est pas reliée à ses dépendances réellement résolues.
Solution rapide : pour documenter un build précis, privilégiez la génération liée à swift build, puis archivez la SBOM avec les résultats du travail CI ; réservez swift package generate-sbom au graphe du paquet.

SwiftPM peut produire une SBOM aux formats SPDX ou CycloneDX. Ce fichier décrit des composants et leurs relations ; il ne remplace ni l’analyse de vulnérabilités ni une vérification de conformité.

Cet article s’adresse aux responsables de paquets Swift qui publient un inventaire de dépendances, aux ingénieurs CI qui construisent pour macOS et aux responsables de publication ou de sécurité qui doivent contrôler le périmètre et la conservation des fichiers.

Jalon : choisir ce que la SBOM doit décrire

Avant de lancer une commande, formulez la question à laquelle le fichier devra répondre. Une SBOM destinée à décrire un paquet publié n’a pas nécessairement le même périmètre qu’une SBOM destinée à accompagner une application compilée pour une plateforme précise. Si l’objectif est d’attester les composants pris en compte par un build, la génération au cours de la construction est le point de départ le plus pertinent.

La proposition officielle SE-0509 sur les SBOM dans SwiftPM distingue les graphes employés par les deux chemins. La commande indépendante travaille à partir du graphe des dépendances du paquet. La génération associée à la construction peut s’appuyer sur le graphe de dépendances SwiftBuild utilisé pour le build. Il ne faut donc pas présumer que deux SBOM produites de ces façons seront identiques.

Pour une bibliothèque distribuée, une vue du paquet entier peut être utile pour décrire ses dépendances déclarées. Pour une application construite par le CI, une vue associée à l’invocation de compilation offre un lien plus direct avec la configuration exécutée. Dans les deux cas, notez le produit ou le paquet concerné, la plateforme et la révision du code à laquelle le fichier se rapporte.

Le format dépend ensuite de la chaîne de réception. SPDX et CycloneDX sont des formats pris en charge par SwiftPM selon SE-0509 ; les détails propres à chaque format restent à valider avec l’outil qui consommera le fichier. Les références officielles décrivent les spécifications SPDX et la spécification CycloneDX.

Le choix du format ne détermine pas à lui seul la portée du document. Une SBOM CycloneDX issue du graphe du paquet reste une description de ce graphe ; le format ne la transforme pas en inventaire exhaustif de tout ce qui a été effectivement utilisé à l’exécution.

À retenir : fixez le périmètre avant de choisir le format. Un fichier valide mais produit à partir du mauvais graphe peut être techniquement lisible tout en étant inadapté à votre question d’audit.

Jalon : vérifier l’environnement et l’état du projet

La génération doit être reproductible dans le contexte du build auquel la SBOM sera associée. Commencez par vérifier le binaire réellement utilisé par le travail CI, plutôt que de vous fier à la version installée sur une machine de développement. Swift 6.4.1 a été annoncé le 13 octobre 2026 ; la publication officielle de Swift 6.4.1 permet de distinguer cette version de Swift 6.4. Consignez la version exacte exécutée, car une étiquette générique telle que « Swift 6 » ne suffit pas à reproduire les options disponibles.

Sur l’agent macOS, vérifiez le chemin de l’exécutable Swift, son numéro de version et le répertoire courant. La documentation officielle d’installation de Swift sur macOS décrit les outils disponibles et leur installation. Si plusieurs toolchains sont présentes, faites en sorte que la commande de construction et celle de génération de SBOM utilisent le même environnement.

Vérifiez également que le travail se trouve à la racine attendue du paquet ou dans le répertoire du projet prévu par votre pipeline. Une commande lancée depuis un sous-répertoire inattendu peut analyser un autre paquet ou échouer à retrouver la configuration attendue. La documentation Swift Package Manager est la référence pour les éléments de description du paquet.

L’état de résolution mérite une attention particulière. La SBOM ne doit pas être produite à partir d’un état de dépendances différent de celui qui a servi à compiler le code. Conservez le fichier de résolution utilisé par le projet et vérifiez que le pipeline n’effectue pas, entre la compilation et la génération indépendante, une nouvelle résolution susceptible de modifier le graphe. Gardez la révision du dépôt et l’identifiant du travail avec les fichiers archivés.

Au lieu d’ajouter immédiatement des options supposées, interrogez l’aide du SwiftPM installé. Les options disponibles et leur combinaison doivent être vérifiées pour la toolchain cible : les exemples copiés d’une version différente ne constituent pas une preuve que le même appel fonctionne dans votre environnement.

Jalon : choisir entre génération intégrée et commande indépendante

Le choix pratique porte moins sur le nom de la commande que sur le graphe qu’elle décrit. La génération liée à la construction est à privilégier lorsque l’inventaire doit correspondre au travail de compilation ; la commande indépendante convient lorsque l’objectif est de décrire le paquet sans exécuter ce build.

Le document officiel SwiftBuild de SwiftPM décrit le contexte de construction. Pour une génération intégrée, examinez l’aide de swift build et la documentation SwiftPM correspondant au binaire utilisé. Pour la génération indépendante, examinez swift package generate-sbom --help dans le même environnement.

La forme exacte des options de format et de sortie doit venir de cette documentation locale. Si le pipeline fixe un format, vérifiez que la version utilisée accepte bien la valeur choisie et que le fichier se trouve à l’emplacement attendu. Cette précaution évite de publier un exemple de commande erroné ou de chercher un artefact qui n’a jamais été écrit à l’endroit supposé.

La différence compte aussi pour les dépendances conditionnelles. Un graphe de paquet peut représenter des dépendances décrites par le paquet, tandis que le graphe de construction reflète la configuration évaluée lors de l’invocation. Pour savoir ce qui figure dans la SBOM, comparez les entrées au fichier de résolution et à la plateforme ciblée. Ne concluez pas à une omission ou à une couverture complète à partir du seul nom du format.

FAQ : génération et périmètre

Comment produire une SBOM SPDX ou CycloneDX avec SwiftPM 6.4 ?
Swift 6.4 ajoute la génération de SBOM à SwiftPM. Pour obtenir une liste rattachée au graphe de compilation, activez la génération dans la commande de construction en suivant les options exposées par le binaire installé. Pour décrire le graphe des dépendances du paquet indépendamment d’une compilation, utilisez la sous-commande swift package generate-sbom. Vérifiez le format et le chemin de sortie dans l’aide et la documentation de cette version.

Quelle différence entre swift package generate-sbom et une SBOM générée pendant la compilation ?
La commande indépendante décrit le graphe des dépendances du paquet. La génération liée à swift build peut s’appuyer sur le graphe utilisé par SwiftBuild pour cette compilation. Les deux fichiers ne répondent donc pas forcément à la même question : le premier documente le paquet, tandis que le second vise davantage les composants pris en compte par une construction donnée.

Une SBOM SwiftPM inclut-elle toutes les dépendances conditionnelles ?
Le résultat dépend du graphe choisi. La sous-commande indépendante utilise le graphe des dépendances du paquet, alors qu’une génération depuis la compilation peut refléter le graphe de construction évalué pour cette invocation. Des conditions liées à la plateforme ou à la configuration peuvent donc conduire à des périmètres différents. Comparez le fichier à la résolution réellement utilisée et documentez la plateforme et les paramètres de compilation.

Jalon : intégrer la production et l’archivage au CI macOS

Une étape de génération n’est utile que si son résultat survit à la fin du travail CI et peut être relié à la compilation correspondante. Organisez le pipeline autour d’une séquence explicite : préparer le projet, construire, produire la SBOM dans le périmètre choisi, puis archiver ensemble les sorties utiles.

• Vérifiez le répertoire de travail, la version de Swift et l’état de résolution avant la compilation.
• Lancez swift build avec les options de génération de SBOM confirmées par l’aide de la toolchain, si l’inventaire doit correspondre à cette construction.
• Utilisez swift package generate-sbom lorsque vous souhaitez une description du graphe du paquet indépendamment du build ; contrôlez alors que l’état de dépendances n’a pas changé.
• Repérez le fichier réellement produit et vérifiez son format et son emplacement. Ne supposez pas un nom de fichier ou un répertoire sans confirmation dans la documentation.
• Copiez ou déplacez la SBOM vers le répertoire d’artefacts prévu par votre pipeline, sans supprimer le résultat original avant d’avoir confirmé la réussite de cette opération.
• Archivez le fichier avec le résultat de compilation, le fichier de résolution conservé par le projet, les journaux utiles et l’identifiant du travail.

La politique d’échec doit être définie avec l’équipe de publication. Si l’inventaire est une pièce exigée pour livrer un artefact, une génération ou un archivage en échec peut justifier l’arrêt du travail. Si le fichier est produit à titre informatif, le pipeline peut conserver le build tout en signalant clairement que la SBOM manque. Évitez toutefois un statut global vert lorsque le contrôle attendu n’a pas été exécuté.

La proposition SE-0509 décrit le comportement associé à la génération et aux échecs ; avant de définir une règle de blocage, vérifiez le comportement indiqué dans la proposition et reproduisez-le avec la version SwiftPM réellement employée. La documentation changeant au fil des versions, il est plus sûr de tester l’appel exact du pipeline que de déduire le résultat d’un exemple ancien.

Pour une configuration qui publie plusieurs produits ou construit plusieurs plateformes, produisez et identifiez les fichiers de manière à éviter toute confusion entre eux. Le nom de l’artefact doit permettre de retrouver le produit, la plateforme et le travail correspondant, sans faire croire qu’une SBOM unique couvre toutes les variantes si ce n’est pas le cas. Le test d’archivage doit aussi confirmer que le fichier est téléchargeable depuis le stockage d’artefacts après la fin du travail CI.

Point de contrôle : une SBOM créée sur l’agent mais absente de l’archive n’est pas un livrable conservé. Vérifiez le résultat après l’étape de transfert, et pas seulement dans le répertoire de travail temporaire.

Jalon : contrôler le contenu avant livraison

La vérification doit porter à la fois sur la forme et sur le périmètre. Ouvrez le fichier avec un lecteur adapté au format choisi, puis contrôlez que le document est lisible et qu’il contient les informations attendues par le destinataire. Vérifiez ensuite que ses composants correspondent au graphe de dépendances associé au paquet ou au build : le choix du graphe reste déterminant, même lorsque le fichier est correctement formé.

Comparez les composants de la SBOM aux dépendances résolues dans le travail. Si une dépendance conditionnelle apparaît seulement dans certaines configurations, notez quelle plateforme et quels paramètres ont été utilisés pour la compilation. Si le même paquet est construit dans plusieurs configurations, comparez les résultats plutôt que de traiter un fichier comme universel. Cette démarche permet de repérer un écart de périmètre sans attribuer automatiquement cet écart à un défaut de SwiftPM.

Un contrôle de conservation complète cette validation. Depuis l’archive finale, vérifiez que le fichier est présent, que son nom et son format correspondent au travail et que les informations permettant de le relier à la révision du code sont conservées. Si la SBOM est destinée à un audit, documentez également la commande et la version de l’outil utilisées. La proposition SE-0509 fournit le cadre officiel pour interpréter la portée des deux modes de génération.

La limite à communiquer est simple : une SBOM est un inventaire, pas une analyse de vulnérabilités. Elle ne prouve pas, à elle seule, qu’un paquet est exempt de vulnérabilités, que ses licences sont conformes ou qu’un audit particulier est satisfait. Ces conclusions nécessitent des contrôles distincts, définis selon les règles applicables au projet et les données réellement présentes dans la SBOM.

Avant de considérer l’intégration terminée, utilisez cette liste de validation dans le travail CI :

• [ ] La version de Swift utilisée est enregistrée et correspond à celle attendue pour le pipeline.
• [ ] Le répertoire courant désigne bien le paquet ou le projet visé.
• [ ] Le choix entre graphe du paquet et graphe de construction correspond à l’usage prévu.
• [ ] Le format et les options de génération ont été confirmés dans la documentation de la toolchain exécutée.
• [ ] Le fichier produit a été ouvert et son contenu comparé au graphe de dépendances retenu.
• [ ] La SBOM figure dans l’archive finale avec les éléments permettant de l’associer au build.
• [ ] La règle de blocage ou de signalement en cas d’échec est explicite.
• [ ] Les documents de livraison ne présentent pas l’inventaire comme une preuve de sécurité ou de conformité complète.

Mise à jour et choix de l’environnement macOS

Dernière mise à jour : 26 octobre 2026. Les informations de version et de comportement ont été vérifiées à partir de la publication Swift 6.4, de l’annonce Swift 6.4.1, de SE-0509 et des documents SwiftPM cités dans l’article. Avant de mettre à jour un pipeline, confirmez les options de génération avec la documentation correspondant à l’outil réellement installé et exécutez un test de production et d’archivage.

Une machine macOS locale reste adaptée lorsque l’équipe a besoin d’un accès physique, d’une configuration matérielle permanente ou d’une charge soutenue et prévisible. En revanche, l’achat mobilise un budget matériel, la machine doit être entretenue et une équipe dispersée doit organiser son accès distant. Un hôte distant évite ces contraintes d’acquisition, mais dépend de la qualité du réseau et ne remplace pas un accès direct aux interfaces physiques.

Pour valider un pipeline ponctuel, tester une version Swift ou maintenir un environnement macOS accessible à distance sans acheter une machine, la location peut donc être plus souple qu’un achat immédiat. NowMini propose un accès à un Mac distant ; les modalités de connexion sont présentées sur la page de connexion de NowMini. Pour comparer les usages avant de choisir un environnement, consultez aussi les guides NowMini sur les environnements Mac distants. Le bon choix dépend de la durée du besoin, des exigences matérielles et de la nécessité de conserver un agent CI disponible en continu.

Questions fréquentes