Swift 6.4 SwiftPM SBOM in macOS CI integrieren? 2026

Symptom: Die macOS-Pipeline baut ein Swift-Projekt, aber eine nachvollziehbare Komponentenliste fehlt im ausgelieferten Build-Artefakt.

Schnellster Weg: Swift 6.4 unterstützt SPDX- und CycloneDX-SBOMs. Soll die Liste zum tatsächlichen Build gehören, prüfen Sie zuerst swift build --enable-sbom; für eine reine Paket-Abhängigkeitsübersicht kommt swift package generate-sbom infrage. Archivieren Sie die erzeugte Datei zusammen mit dem Build und behandeln Sie sie nicht als Schwachstellenscan oder Compliance-Nachweis.

Dieser Leitfaden richtet sich an Swift-Paketverantwortliche, die eine Komponentenliste für ein Paket oder Produkt erstellen und weitergeben müssen.
Apple-Plattform-CI-Teams erhalten einen Ablauf für Erzeugung, Prüfung und Aufbewahrung des SBOM-Artefakts.
Verantwortliche für Sicherheit oder Release können damit den Umfang und die Aussagegrenzen der Liste kontrollieren.

Stand: 26.10.2026. Swift 6.4 wurde laut offizieller Release-Mitteilung vom 15.09.2026 veröffentlicht; die Ankündigung von Swift 6.4.1 vom 13.10.2026 dokumentiert ein nachfolgendes Update. Die folgenden Befehle und Abgrenzungen beziehen sich auf die offizielle SwiftPM-Dokumentation und SE-0509. Prüfen Sie die Hilfe Ihrer installierten Toolchain vor dem Einbau in eine produktive Pipeline.

Meilenstein: Aussage und Umfang der SwiftPM-SBOM festlegen

Eine SBOM ist eine maschinenlesbare Komponentenliste. Sie kann Abhängigkeiten eines Swift-Pakets oder den für einen Build ermittelten Komponentenbestand dokumentieren. Sie führt jedoch nicht automatisch eine Sicherheitsanalyse aus: Aus einem Eintrag folgt weder, dass eine Komponente verwundbar ist, noch, dass sie frei von bekannten Schwachstellen ist. Ebenso ist die Datei allein kein Beleg für Lizenzkonformität oder die Erfüllung einer bestimmten Audit-Vorgabe. Der Umfang und das Format der Liste sind in SE-0509 beschrieben.

Legen Sie vor dem Ändern der Pipeline fest, welche Frage die SBOM beantworten soll:

• Paket: Welche Abhängigkeiten gehören zur Paketdefinition und zum aufgelösten Paketgraphen?
• Produkt: Welche Komponenten stehen im Zusammenhang mit einem bestimmten Produkt?
• Konkreter Build: Welche Abhängigkeiten waren für genau diesen ausgeführten Build relevant?

Die Unterscheidung ist entscheidend. Ein Paket kann mehrere Produkte und Ziele enthalten. Eine pauschale Paketliste kann daher Komponenten umfassen, die beim konkreten Build nicht verwendet wurden. Umgekehrt sollte eine Build-SBOM mit dem zugehörigen Quellstand, den Build-Parametern und dem aufgelösten Abhängigkeitsstand abgelegt werden. Nur so lässt sich später beurteilen, auf welchen Lauf sich die Liste bezieht.

Wie erzeugt SwiftPM mit Swift 6.4 eine SPDX- oder CycloneDX-SBOM?
Wählen Sie zunächst die Erzeugungsart und danach das Format. Die offiziellen Unterlagen nennen SPDX und CycloneDX als unterstützte Formate. Die SPDX-Spezifikationsübersicht und die CycloneDX-Spezifikationen beschreiben die jeweiligen Standards. Welche Ausgabeform und Dateiendung Ihre Toolchain erzeugt, sollte aus der installierten Befehlszeilenhilfe beziehungsweise dem erzeugten Artefakt hervorgehen, nicht aus einem geratenen Dateinamen.

Meilenstein: Toolchain und reproduzierbaren Projektzustand prüfen

Bevor die CI einen SBOM-Schritt ausführt, muss sie dieselbe Swift-Toolchain verwenden wie der zugehörige Build. Ein abweichender SwiftPM-Stand kann das verfügbare Kommando, akzeptierte Optionen oder das erzeugte Ergebnis verändern. Prüfen Sie die installierte Version unmittelbar in der Pipeline und dokumentieren Sie sie im Build-Protokoll. Für die Installation auf macOS verweist die offizielle Swift-Installationsseite auf die verfügbaren Toolchain-Wege.

Arbeiten Sie außerdem im Verzeichnis, in dem SwiftPM das richtige Paket findet. In einem Repository mit mehreren Paketen oder Unterprojekten kann ein korrekt ausgeführter Befehl sonst eine andere Paketdefinition lesen als der eigentliche Build. Der Schritt sollte deshalb das Arbeitsverzeichnis explizit setzen oder vor der Erzeugung den Paketpfad im Protokoll festhalten.

Bewahren Sie den zur Pipeline gehörenden Abhängigkeitsstand auf. Bei SwiftPM ist insbesondere zu prüfen, ob die projektspezifische Package.resolved vorhanden ist, wie sie im Build verwendet wird und ob sie zum erfassten Commit gehört. Auch die verwendeten Build-Optionen und die ausgewählte Konfiguration gehören zur Rückverfolgbarkeit. Die SwiftPM-Dokumentation zur Paketbeschreibung erläutert, wie Paket- und Zieldefinitionen aufgebaut sind.

Wenn ein Projekt die Abhängigkeiten nicht reproduzierbar auflöst, beheben Sie diesen Zustand vor der SBOM-Integration. Eine erzeugte Datei ist sonst zwar vorhanden, kann aber möglicherweise nicht mit dem später geprüften Build abgeglichen werden.

Meilenstein: Erzeugungsweg und Abhängigkeitsgraph auswählen

SwiftPM stellt laut SE-0509 zwei Wege bereit: die SBOM-Erzeugung im Build-Aufruf und ein eigenständiges Paketkommando. Der wesentliche Unterschied ist nicht bloß die Schreibweise des Befehls, sondern der verwendete Abhängigkeitsgraph. Die Build-Variante kann den SwiftBuild-Kontext heranziehen; das separate Kommando bezieht sich auf den Paketabhängigkeitsgraphen. Deshalb sollten Sie den Weg anhand der gewünschten Aussage wählen und nicht allein danach, welcher Aufruf einfacher in ein Skript passt.

Die Beispiele orientieren sich an den Aufrufen in SE-0509. Prüfen Sie swift build --help und swift package generate-sbom --help mit der tatsächlich eingesetzten Toolchain, bevor Sie Optionen oder Ausgabeorte fest in ein CI-Skript übernehmen. Die SwiftPM-Dokumentation zum SwiftBuild-Kommando hilft dabei, den Build-Aufruf im Kontext von SwiftPM einzuordnen.

Worin unterscheiden sich das SBOM-Paketkommando und die Erzeugung während des Builds?
Das eigenständige Kommando dient der Abbildung des Paketabhängigkeitsgraphen. Die SBOM-Erzeugung im Build-Aufruf ist die passendere Kandidatin, wenn die Komponentenliste den ausgeführten Build beschreiben soll, weil sie im SwiftBuild-Kontext entsteht. Trotzdem ist auch eine Build-SBOM kein Beweis dafür, dass jede aufgeführte Komponente tatsächlich in einem ausgelieferten Binärprodukt landet. Prüfen Sie die erzeugten Einträge und halten Sie den Scope im Artefaktkontext fest.

Bei bedingten Abhängigkeiten kommt es auf den ausgewählten Graphen und die konkrete Build-Konfiguration an. Paketdefinitionen können Abhängigkeiten an Bedingungen wie Plattformen oder Build-Kontexte knüpfen. Eine Paketübersicht und eine Liste für einen konkreten macOS-Build können deshalb unterschiedliche Aussagebereiche haben. Kontrollieren Sie, ob eine Abhängigkeit nur deklariert, für die aktuelle Plattform aufgelöst oder im betreffenden Build-Kontext verwendet wird. Die SBOM ersetzt diese Prüfung nicht.

Meilenstein: SBOM-Erzeugung an den macOS-CI-Lauf binden

Führen Sie die Erzeugung in demselben Job aus, der den maßgeblichen Build erstellt, oder verknüpfen Sie die beiden Jobs über eine unveränderliche Build-Kennung und denselben Quell- und Abhängigkeitsstand. Ein später separat gestarteter SBOM-Job kann sonst einen anderen Zustand auflösen als der ursprüngliche Build.

Ein plattformneutrales Muster für den Ablauf sieht so aus:

set -euo pipefail

# Im Paketverzeichnis starten und den verwendeten Stand protokollieren.
swift --version
git rev-parse HEAD

# Für eine buildbezogene SBOM den Build-Aufruf verwenden.
swift build --enable-sbom --sbom-format cyclonedx

# SBOM_SOURCE auf den von der installierten Toolchain dokumentierten
# Ausgabeort setzen und in den CI-Artefaktordner übernehmen.
mkdir -p "$CI_ARTIFACTS/sbom"
test -s "$SBOM_SOURCE"
cp "$SBOM_SOURCE" "$CI_ARTIFACTS/sbom/"

SBOM_SOURCE ist hier absichtlich kein fest eingetragener Pfad. Ermitteln Sie den Ausgabeort anhand der Hilfe Ihrer SwiftPM-Version und einer kontrollierten Testausführung. So wird vermieden, dass die Pipeline eine Datei mit einem angenommenen Namen sucht oder versehentlich eine ältere SBOM aus einem vorherigen Lauf archiviert. Löschen Sie vor der Erzeugung alte Ausgabedateien oder verwenden Sie einen frischen Arbeitsbereich, damit der Test auf das aktuelle Ergebnis zeigt.

Wenn nur der Paketgraph benötigt wird, kann der eigenständige Aufruf an die Stelle des Build-Aufrufs treten. Die Ausgabe muss danach auf dieselbe Weise in das Artefaktverzeichnis übernommen werden. Erzeugen Sie nicht unbemerkt beide Varianten und veröffentlichen Sie anschließend eine davon ohne Kennzeichnung: Wenn beide Listen im Release landen, müssen ihre unterschiedlichen Graphen und Verwendungszwecke erkennbar sein.

Die Fehlerbehandlung gehört zur Release-Entscheidung. SE-0509 beschreibt das Verhalten der SBOM-Erzeugung im jeweiligen Kommando; bei einem fehlgeschlagenen Erzeugungsschritt darf die Pipeline nicht so tun, als läge ein gültiges Artefakt vor. Für ein Release, dessen Lieferumfang eine SBOM voraussetzt, sollte ein fehlgeschlagener Aufruf die Auslieferung stoppen. Wird die Liste zunächst nur informativ erzeugt, kann ein Team eine nicht blockierende Behandlung erwägen, muss den fehlenden Nachweis aber sichtbar melden und darf ihn nicht als erfolgreich archivierte SBOM darstellen.

Meilenstein: Artefaktumfang und Liefergrenze abnehmen

Nach dem ersten erfolgreichen Lauf prüfen Sie nicht nur, ob eine Datei existiert. Validieren Sie, dass sie lesbar ist, das erwartete Format verwendet und den vorgesehenen Paket- oder Build-Umfang abbildet. Eine Dateiendung allein beweist weder gültige Syntax noch den passenden Inhalt. Nutzen Sie, sofern vorhanden, einen Validator für das Zielformat und bewahren Sie dessen Ergebnis zusammen mit dem Pipeline-Protokoll auf.

Wie wird die SwiftPM-SBOM als macOS-CI-Build-Artefakt aufbewahrt?
Legen Sie die erzeugte Datei in den Artefaktbereich des Jobs und archivieren Sie sie mit dem zugehörigen Build. Der Artefaktname oder die Metadaten sollten mindestens eine eindeutige Build-Zuordnung ermöglichen; Commit, Toolchain-Version und verwendete Erzeugungsart gehören in das Protokoll oder eine begleitende Datei. Die konkrete Upload-Konfiguration hängt vom verwendeten CI-System ab. Dieser Leitfaden legt daher keine plattformspezifischen Schlüssel oder nicht verifizierten Konfigurationsoptionen fest.

Die Abnahme sollte folgende Fragen beantworten:

• Entspricht das tatsächliche Dateiformat der Vorgabe für die nachgelagerte Verarbeitung?
• Enthält die SBOM das erwartete Paket oder Produkt?
• Sind die Einträge mit dem aufgelösten SwiftPM-Abhängigkeitsstand plausibel?
• Ist erkennbar, ob die Liste aus dem Build-Aufruf oder aus dem Paketkommando stammt?
• Kann das archivierte Artefakt eindeutig dem Quellstand und CI-Lauf zugeordnet werden?
• Ist bei bedingten Abhängigkeiten dokumentiert, welche Plattform und Build-Konfiguration zugrunde lagen?

Eine vorhandene SBOM beantwortet nicht automatisch, ob eine Abhängigkeit sicher, lizenzrechtlich zulässig oder für einen bestimmten Audit ausreichend dokumentiert ist. Für diese Entscheidungen müssen Sie die Anforderungen Ihres Projekts und die tatsächlichen Einträge gesondert prüfen.

Enthält eine von SwiftPM erzeugte SBOM bedingte Abhängigkeiten?
Das lässt sich nicht pauschal mit „alle“ oder „keine“ beantworten. Der Umfang hängt davon ab, ob das Paketkommando den Paketgraphen oder der Build-Aufruf den SwiftBuild-Kontext abbildet, sowie von der konkreten Paketdefinition und Ausführung. Vergleichen Sie die Liste mit den aufgelösten Abhängigkeiten für den Zielkontext. Wenn eine bedingte Abhängigkeit für die Freigabe wichtig ist, dokumentieren Sie die Plattform- und Build-Bedingungen, statt ihre Einbeziehung allein aus dem Vorhandensein oder Fehlen eines Eintrags abzuleiten.

Abnahme-Checkliste für den ersten CI-Lauf

• [ ] Die in der CI installierte Swift-Toolchain ist protokolliert und unterstützt die verwendete SBOM-Funktion.
• [ ] Der Schritt startet im vorgesehenen Paketverzeichnis und liest den erwarteten Projektstand.
• [ ] Package.resolved und Commit lassen sich dem Build zuordnen, sofern das Projekt diese Datei verwendet.
• [ ] Die gewählte Erzeugungsart passt zur gewünschten Aussage: Paketgraph oder Build-Kontext.
• [ ] Das gewünschte Format ist in der installierten Befehlszeilenhilfe bestätigt.
• [ ] Der tatsächliche Ausgabeort wurde durch einen Testlauf festgestellt und nicht geraten.
• [ ] Die SBOM wird aus dem aktuellen Job übernommen; alte Ausgabedateien können nicht als neues Ergebnis erscheinen.
• [ ] Das Artefakt ist lesbar, dem Build zugeordnet und mit dem vorgesehenen Aufbewahrungsweg archiviert.
• [ ] Fehler bei einer für das Release erforderlichen Erzeugung verhindern eine irreführende Erfolgsmeldung.
• [ ] Die Lieferdokumentation behauptet weder einen Schwachstellenscan noch eine vollständige Compliance-Prüfung, wenn diese Arbeiten nicht separat erfolgt sind.

Nächster Schritt: passende macOS-Umgebung für wiederkehrende Builds

Wenn die Pipeline verlässlich eine passende Swift-Toolchain benötigt, vergleichen Sie zunächst den Aufwand einer eigenen Mac-Hardware mit einer zeitweise genutzten macOS-Umgebung. Ein selbst betriebener Mac bietet direkte Kontrolle über Hardware, Anschlüsse und lokale Abläufe, bindet aber Kapital und erfordert eigene Wartung. Ein allgemeiner Linux-Build-Host kann macOS-spezifische Werkzeuge nicht ersetzen. Eine gemietete Mac-Umgebung vermeidet den Hardwarekauf, setzt jedoch eine stabile Netzwerkverbindung und eine Prüfung von Zugriffsrechten, Datenhaltung und Aufbewahrung voraus. Für Anforderungen an Datenschutz und DSGVO sollten Sie insbesondere klären, wo Quellcode und Build-Artefakte verarbeitet und gespeichert werden.

Eine wiederkehrende SBOM-Pipeline braucht nicht zwingend eine dauerhaft angeschaffte Maschine. Wenn eine zeitweise macOS-Umgebung für Toolchain-Prüfungen oder CI-Tests genügt, kann NowMini als Alternative zum Kauf geprüft werden. Beginnen Sie mit den Mac- und CI-Leitfäden von NowMini, um den Betriebsablauf einzuordnen; konkrete Fragen zur verfügbaren Umgebung lassen sich über die Kontaktseite von NowMini klären. Bei dauerhaft hoher Auslastung oder benötigten physischen Schnittstellen kann ein eigener Mac weiterhin die zweckmäßigere Wahl sein.