Für die Unternehmens-CI sollte das SBOM zunächst in einer isolierten Pipeline während des Builds erzeugt und zusammen mit dem konkreten Build-Artefakt archiviert werden. Swift 6.4 unterstützt laut Swift.org die SBOM-Erzeugung mit SwiftPM in den Formaten SPDX und CycloneDX. Erst wenn Inhalt, Erzeugung und Zuordnung zum Produkt geprüft sind, sollte das Verfahren schrittweise in die produktive Auslieferung übernommen werden.
Für Sicherheits- und Compliance-Verantwortliche: Der Leitfaden hilft, eine Software-Stückliste als überprüfbaren Liefernachweis einzuführen.
Für CI-Plattformteams: Er zeigt, welche Eingaben und Belege bei der Integration in eine macOS-Build-Pipeline nötig sind.
Für iOS- und macOS-Verantwortliche: Er grenzt die SwiftPM-Abhängigkeiten von der vollständigen Abhängigkeitslage des ausgelieferten Produkts ab.
Zuletzt aktualisiert am 07.10.2026. Die Funktionsangaben wurden anhand der Swift-6.4-Veröffentlichungsnotizen, der SwiftPM-Dokumentation und der Implementierungsbeschreibung zu SE-0509 geprüft. Die Abnahme muss zusätzlich mit den tatsächlichen CI-Aufzeichnungen des Unternehmens belegt werden.
[ SECTION_01 ] Vor dem Pilot: Nachweisumfang und Zuständigkeiten festlegen
Ein SBOM ist eine Software-Stückliste. Es kann Komponenten und Beziehungen sichtbar machen. Es ist aber für sich allein weder ein vollständiger Sicherheitsnachweis noch der Beweis, dass jede im ausgelieferten Produkt enthaltene Komponente erfasst wurde. Für die Abnahme zählt daher nicht nur, ob eine Datei erzeugt wird. Entscheidend ist, auf welches Paket oder Produkt sie sich bezieht, aus welchem Zustand sie stammt und wie sie mit dem Build verbunden ist.
Vor dem ersten Pipeline-Lauf sollte das Team den Nachweiszweck schriftlich festhalten:
- Soll die Stückliste ein SwiftPM-Paket, ein ausführbares Produkt oder ein konkretes Release-Artefakt beschreiben?
- Ist SPDX, CycloneDX oder eine Ausgabe in beiden Formaten erforderlich?
- Welche Komponenten liegen außerhalb des SwiftPM-Erfassungsbereichs, etwa über andere Build-Werkzeuge oder manuell eingebundene Dateien?
- Welche Person oder Rolle prüft Format, Vollständigkeit und Ablage?
- Welche Stelle darf einen fehlerhaften SBOM-Lauf freigeben oder muss den Release stoppen?
Die Formate sind nicht bloß Dateiendungen. Sie werden in Organisationen häufig von unterschiedlichen Sicherheits- und Compliance-Prozessen erwartet. Legen Sie deshalb vor der Implementierung fest, welches Format das Zielsystem tatsächlich verarbeitet. Swift.org bestätigt die Unterstützung von SPDX und CycloneDX für SwiftPM in Swift 6.4; die Formatwahl ersetzt jedoch nicht die Prüfung, welche Pakete und Beziehungen der erzeugte Inhalt abbildet. Die Funktion ist in SE-0509, der Implementierungsbeschreibung für SBOMs über SwiftPM, beschrieben.
Eingaben und Verantwortliche
Das Anwendungsteam liefert den Quellstand, die Paketmanifest-Dateien und die Information, welche Produkte tatsächlich ausgeliefert werden. Das CI-Plattformteam dokumentiert Toolchain-Auswahl, Build-Aufruf, Arbeitsverzeichnis und Ablageort. Das Sicherheits- oder Compliance-Team definiert Format, Mindestprüfungen und Freigaberegeln.
Diese Aufteilung verhindert einen häufigen Interpretationsfehler: Ein erfolgreicher CI-Job zeigt zunächst nur, dass ein Prozess ohne gemeldeten Fehler endete. Er beweist nicht automatisch, dass die erzeugte Stückliste das veröffentlichte Produkt vollständig beschreibt. Die SwiftPM-Dokumentation erläutert den Paket- und Build-Kontext; die produktbezogene Abnahme bleibt eine Aufgabe des Unternehmens.
[ SECTION_02 ] Inventur vor der Änderung: Toolchain, Abhängigkeiten und Produkte
Erfassen Sie zuerst den Ist-Zustand, bevor Sie eine SBOM-Option in die produktive Pipeline aufnehmen. Notieren Sie, welche Swift-Toolchain der Job verwendet, wie SwiftPM aufgerufen wird und ob die Paketauflösung durch eine eingecheckte Package.resolved-Datei festgelegt ist. Halten Sie außerdem fest, welche Build-Produkte in den Release gelangen.
Prüfen Sie anschließend, ob alle relevanten Abhängigkeiten tatsächlich durch SwiftPM beschrieben werden. Ein SBOM aus SwiftPM kann keine Abdeckung für Komponenten belegen, die außerhalb dieses Paketkontexts eingebunden werden. Dazu können beispielsweise separate Build-Schritte, vorgefertigte Binärdateien oder von anderen Werkzeugen verwaltete Abhängigkeiten gehören. Das sind keine Fehler der SBOM-Datei; es sind Grenzen des erfassten Umfangs, die in der Dokumentation sichtbar bleiben müssen.
Die Dokumentation zu SwiftPM-Abhängigkeiten hilft bei der Einordnung deklarierter Pakete. Für die Abnahme reicht es aber nicht, nur die Manifest-Datei zu prüfen. Vergleichen Sie die deklarierte Paketlage mit dem tatsächlich verwendeten Build-Ablauf. Halten Sie nicht von SwiftPM erfasste Komponenten separat fest oder definieren Sie einen zusätzlichen Erfassungsweg.
Erstellen Sie als Ausgangsnachweis eine kompakte Bestandsaufnahme mit den Eingaben, dem zuständigen Team und dem erwarteten Ergebnis. Dazu gehören der verwendete Quellstand, die Paketauflösung, die erzeugten Produkte und die vorgesehenen SBOM-Formate. Wird eine dieser Angaben während des Piloten verändert, muss die Änderung in der Build-Aufzeichnung nachvollziehbar bleiben.
[ SECTION_03 ] Während des Piloten: SBOM-Erzeugungsweg auswählen
Swift 6.4 stellt über SwiftPM einen Weg zur SBOM-Erzeugung während des Builds und eine separate Paketaktion bereit. Der passende Weg hängt davon ab, welche Aussage die Pipeline nachweisen soll. Die Veröffentlichung beschreibt die Funktion; SE-0509 erläutert die Erzeugungswege und deren Zusammenhang mit Paket- beziehungsweise Build-Informationen. Prüfen Sie die Optionen der tatsächlich eingesetzten Toolchain, statt Parameter aus einer anderen Version ungeprüft zu übernehmen.
| Erzeugungsweg | Was die Pipeline damit prüft | Zentrale Abnahmebedingung |
|---|---|---|
SBOM im Rahmen von swift build |
Die Stückliste entsteht im Build-Kontext und kann mit dessen Abhängigkeitsinformationen verknüpft werden. | SBOM und Produkt müssen aus demselben dokumentierten Build-Lauf stammen. |
Separate Aktion swift package generate-sbom |
SwiftPM erzeugt die Stückliste aus dem Paketkontext, ohne dass die Generierung selbst der Build-Aufruf ist. | Paketauflösung und Build-Zustand müssen nachweislich mit dem späteren Produkt übereinstimmen. |
Die Tabelle beschreibt den betrieblichen Unterschied, nicht eine Garantie für die Vollständigkeit eines bestimmten Projekts. Für die konkrete CLI-Syntax sind die Hilfeausgabe und die Dokumentation der installierten SwiftPM-Version maßgeblich. SE-0509 beschreibt beide Wege; die Veröffentlichungsnotizen ordnen die Funktion Swift 6.4 zu. Wenn die Pipeline zusätzliche Build-Optionen oder Wrapper verwendet, muss das Team separat testen, ob diese den SBOM-Schritt beeinflussen.
Wie erzeugt Swift 6.4 ein SBOM während des CI-Builds?
Für einen Build-Pfad wird die SBOM-Erzeugung in denselben Job wie der Build aufgenommen. Der Job sollte den Quellstand auschecken, die vorgesehene Abhängigkeitsauflösung verwenden, das Produkt erstellen und die SBOM in einem festgelegten Ausgabeverzeichnis ablegen. Die konkrete Option ist mit der Hilfe der eingesetzten Toolchain zu bestätigen. Das vermeidet, dass ein Beispiel für eine andere SwiftPM-Version als gültige Pipeline-Syntax behandelt wird.
Der Vorteil dieses Weges ist die direkte Verbindung zum Build-Lauf. Die Auswertung bleibt trotzdem erforderlich: Ermitteln Sie, ob die Datei zum erwarteten Produkt gehört, ob sie im gewählten Format lesbar ist und ob ihre Paketbeziehungen den erwarteten Inhalt wiedergeben. Bei mehreren Produkten darf nicht angenommen werden, dass eine einzelne Datei ohne weitere Prüfung jedes Produkt beschreibt.
Wie unterscheidet sich die separate SwiftPM-Erzeugung?
Die separate Aktion swift package generate-sbom kann sinnvoll sein, wenn die Organisation eine Paketstückliste unabhängig vom regulären Build benötigt. Sie sollte jedoch nicht ohne Nachweis als SBOM des später ausgelieferten Produkts bezeichnet werden. Zwischen Generierung und Build können sich Arbeitsverzeichnis, aufgelöste Abhängigkeiten oder Eingaben ändern.
Führen Sie die separate Erzeugung daher nur in einem kontrollierten Job aus. Der Job muss die verwendete Paketauflösung protokollieren und vor dem Build erneut prüfen oder anderweitig belegen, dass der Paketgraph unverändert ist. Stimmen die Eingaben nicht überein, ist die Datei kein belastbarer Beleg für das nachfolgende Artefakt. Die Swift-PackageDescription-Dokumentation bietet Kontext zu Paketbeschreibungen, ersetzt aber nicht den Vergleich mit dem konkreten Build-Zustand.
Eine erfolgreiche Generierung ist ein technisches Ergebnis, keine automatische Release-Freigabe. Bei fehlender Zuordnung, unerwarteten Paketen oder nicht lesbarer Ausgabe sollte die Pipeline den Fall sichtbar melden und nach der festgelegten Regel stoppen oder in einen ausdrücklich nicht freigegebenen Status überführen.
[ SECTION_04 ] Im isolierten CI-Job: Eingaben fixieren und Fehlerverhalten testen
Aktivieren Sie die Funktion zuerst in einem isolierten CI-Job oder einem nicht produktiven Zweig. Halten Sie dabei die Toolchain-Auswahl und den Zustand der Abhängigkeiten fest. Ein Pilot ist nur aussagekräftig, wenn sich ein Fehler auf eine konkrete Änderung zurückführen lässt und nicht gleichzeitig mehrere unkontrollierte Eingaben variieren.
Gehen Sie in einer nachvollziehbaren Reihenfolge vor:
- Erfassen Sie Quellstand, Toolchain-Auswahl, Paketmanifest-Dateien und Zustand der Paketauflösung.
- Ergänzen Sie den gewählten SBOM-Schritt und legen Sie den Ausgabepfad ausdrücklich fest.
- Erzeugen Sie das vorgesehene Produkt und das SBOM im selben kontrollierten Job oder dokumentieren Sie die Trennung.
- Prüfen Sie, ob die Datei vorhanden, lesbar und im erwarteten Format ist.
- Vergleichen Sie die erfassten Pakete und Beziehungen mit den erwarteten Abhängigkeiten und Produkten.
- Testen Sie das Verhalten bei fehlender oder nicht verwendbarer Ausgabe und halten Sie das Ergebnis als CI-Nachweis fest.
Diese Prüffolge ist eine Betriebsregel, keine von SwiftPM garantierte Eigenschaft. Sie muss an den konkreten Pipeline-Aufbau angepasst werden. Besonders wichtig ist die Fehlerbehandlung: Ein optionaler Warnhinweis kann für eine frühe Erprobung nützlich sein, ist aber nicht gleichbedeutend mit einer bestandenen Compliance-Abnahme. Wenn die SBOM für eine Release-Entscheidung erforderlich ist, muss die verantwortliche Stelle ausdrücklich festlegen, ob ein fehlendes oder ungültiges Dokument den Build blockiert.
Die Konfiguration sollte auch festhalten, welcher Job die Datei erzeugt und wer sie prüfen darf. Bei einem gemeinsamen Runner dürfen Berechtigungen für Quellcode, Signierschlüssel und Artefaktablage nicht allein deshalb weiter gefasst werden, weil ein neuer Schritt hinzukommt. Für die operative Umgebung sind außerdem Aufbewahrung, Zugriff und Löschung mit den geltenden internen Regeln sowie den Anforderungen der DSGVO abzugleichen.
[ SECTION_05 ] Nach dem Build: Inhalt und Produktzuordnung kontrollieren
Die wichtigste Abnahmefrage lautet nicht „Wurde eine SBOM-Datei geschrieben?“, sondern „Welches Produkt beschreibt genau diese Datei?“. Verknüpfen Sie für den Vergleich mindestens Quellstand, Build-Aufzeichnung, SBOM-Datei und ausgeliefertes Artefakt. Eine Prüferin oder ein Prüfer muss diesen Zusammenhang später ohne Annahmen rekonstruieren können.
Kontrollieren Sie den Inhalt in mehreren Schritten. Prüfen Sie zuerst, ob die erwarteten SwiftPM-Pakete vertreten sind. Achten Sie dann darauf, ob die Beziehungen zwischen Paketen plausibel sind und ob die erfasste Produktgrenze zur Release-Beschreibung passt. Falls das Projekt mehrere Produkte baut, halten Sie fest, ob die Ausgabe diese einzeln oder in einem gemeinsamen Kontext abbildet. Die Dokumentation zur SwiftPM-Paketstruktur unterstützt die Einordnung von Paketen und Produkten, ist aber kein projektbezogener Vollständigkeitsnachweis.
Bei separat erzeugten SBOMs ist zusätzlich zu belegen, dass die Abhängigkeitsauflösung zwischen Erzeugung und Build gleich geblieben ist. Ein identischer Quellstand allein reicht nicht als Nachweis, wenn die Paketauflösung oder andere Eingaben abweichen können. Speichern Sie deshalb die für den Job relevanten Eingaben und die Prüfergebnisse zusammen mit den Artefakten.
Fehlende erwartete Komponenten, ein unerwartetes Produkt, ein Generierungsfehler oder eine nicht nachvollziehbare Zuordnung sind Abweichungen. Die zuständige Stelle sollte die betroffene Freigabe anhalten und zunächst Erzeugungsweg, Paketauflösung und Ausgabeverzeichnis untersuchen. Eine Datei nachträglich zu ergänzen, ohne ihre Verbindung zum ursprünglichen Build zu belegen, behebt die Nachweislücke nicht.
[ SECTION_06 ] Vor der Freigabe: Entscheidungskriterien und Mac-CI-Betrieb
Die Verbreitung sollte vom Prüfergebnis abhängen. Beginnen Sie nicht mit einer pauschalen Aktivierung in sämtlichen Repositorys. Nutzen Sie die Pilotbelege, um zwischen einer Einführung je Repository, einer zentral gepflegten CI-Konfiguration oder einer vorläufigen Zurückstellung zu wählen.
Entscheidungsbedingungen für die Freigabe:
- Wenn die SBOM im gewählten Format erzeugt wird, ihr Umfang zum Produkt passt und sie eindeutig mit Build und Artefakt verknüpft ist, dann kann die Einführung für vergleichbare Repositorys geplant werden.
- Wenn die Datei korrekt erzeugt wird, aber einzelne Abhängigkeiten außerhalb von SwiftPM liegen, dann ergänzen Sie den Erfassungsweg oder kennzeichnen die Abdeckung klar, bevor das Dokument als Produktnachweis verwendet wird.
- Wenn eine separate Generierung verwendet wird und der Paketgraph nicht sicher mit dem Build-Zustand übereinstimmt, dann wechseln Sie für diesen Nachweis zum Build-Pfad oder blockieren die Freigabe bis zur Klärung.
- Wenn Datei, Produkt oder Eingaben nicht miteinander verbunden werden können, dann gilt die Abnahme als offen; eine automatische Warnung darf die fehlende Zuordnung nicht ersetzen.
Legen Sie für jede Freigabe eine Aufzeichnung an. Sie sollte die Toolchain, den Commit-Bezug, die verwendete Paketauflösung, die SBOM-Datei, das zugehörige Build-Artefakt, die Prüfergebnisse und die Behandlung von Fehlern enthalten. Das ist der Mindestkontext, um eine spätere Prüfung nicht auf Vermutungen über den CI-Lauf zu stützen.
Für den Betrieb auf Mac-CI ist nicht allein die SBOM-Funktion ausschlaggebend. Entscheidend sind die kontrollierte Toolchain, stabile Ablage der Build-Belege und ein Berechtigungsmodell, das zur Pipeline passt. Prüfen Sie im Pilot, ob ein gemeinsam genutzter oder dedizierter Mac-Knoten mit den Anforderungen an Zugriff, Isolation und Aufbewahrung vereinbar ist. Daraus lässt sich ohne echte Betriebsdaten weder eine Leistungs- noch eine Kostenaussage ableiten.
Wer die technische Ausführung auf eigene Mac-Infrastruktur verlagert, muss Anschaffung, Wartung, Verfügbarkeit und Kapazitätsplanung selbst abdecken. Ein Remote-Mac-Angebot kann für zeitlich begrenzte Tests oder eine zusätzliche CI-Umgebung eine Alternative sein; vor einer Entscheidung sollten jedoch Zugriff, Aufbewahrungsregeln und Toolchain-Verwaltung geprüft werden. Für einen Vergleich der Beschaffungspfade kann die Übersicht zu Mac-mini-Bestellungen als Orientierung dienen; sie belegt nicht automatisch, dass eine konkrete CI-Konfiguration die hier beschriebenen Abnahmekriterien erfüllt. Einen Überblick über die verfügbaren Mac-Angebote und den Remote-Zugriff finden Sie auch auf der NOVAKVM-Übersichtsseite.
Die Integration ist erst dann freigabefähig, wenn Erzeugung, Inhaltsprüfung und Artefaktzuordnung als zusammenhängender Nachweis funktionieren. Ein eigenes Mac-System ist sinnvoll, wenn das Unternehmen dauerhaft eine kontrollierte Auslastung, physische Schnittstellen oder vollständig selbst verwaltete Infrastruktur benötigt. Für einen zeitlich begrenzten SwiftPM-Pilot oder zusätzliche macOS-Build-Kapazität kann das Mieten eines Mac von NOVAKVM den Einstieg erleichtern, ohne die Abnahmeverantwortung aus der eigenen CI zu verlagern. Prüfen Sie die tatsächlichen Toolchain-, Berechtigungs- und Archivierungsanforderungen zuerst im Pilot und vergleichen Sie danach, ob ein Mietmodell zu den betrieblichen Vorgaben passt.