Ein Release-Artefakt hat eine Attestierung, aber niemand kann sicher sagen, ob sie zur ausgelieferten Datei gehört.
Schnellste Lösung: Verifizieren Sie Quelle, Workflow-Identität und Digest am tatsächlichen Übergabeartefakt; behandeln Sie Tests, Apple-Signatur und Freigabe als eigene Prüfschritte.

GitHub Artifact Attestations können die Herkunft eines Build-Artefakts belegen und eine Verifikation unterstützen. Sie beweisen jedoch weder, dass der Quellcode sicher ist, noch dass Tests bestanden wurden oder Apple-Signatur und Notarisierung gültig sind. Für Ihre iOS-CI bedeutet das: Herkunftsnachweis und Build-, Test-, Signatur- sowie Release-Abnahme getrennt führen. Entscheidend ist, dass der geprüfte Digest zur Datei passt, die Ihr Team tatsächlich veröffentlicht.

Für CI-Verantwortliche: Sie richten eine nachvollziehbare Herkunftsprüfung für iOS-Builds ein.
Für Verantwortliche der Softwarelieferkette: Sie grenzen die Aussagekraft einer Attestierung sauber ab.
Für Release Engineers: Sie verbinden den Nachweis mit Tests, Signaturprüfung und Freigabe.

GitHub Artifact Attestations in der Release-Abnahme einordnen

Ein Herkunftsnachweis ist ein Baustein der Freigabe, kein Qualitätssiegel. GitHub beschreibt Artifact Attestations als Möglichkeit, die Herkunft von Build-Artefakten zu belegen und konsumierte Software zu verifizieren. Welche Aussagen Sie daraus ableiten, hängt davon ab, ob der Nachweis tatsächlich auf das erwartete Repository, den Commit, den Workflow und die geprüfte Datei verweist. GitHubs Konzeptbeschreibung zu Artifact Attestations erläutert Zweck und Grenzen.

Die Abnahme sollte deshalb mindestens diese Prüffelder unterscheiden:

  • Quelle: Stammt der Build aus dem erwarteten Repository und dem vorgesehenen Commit?
  • Workflow: Entstand er in einem für Ihr Unternehmen freigegebenen Workflow?
  • Artefakt: Passt der attestierte Digest zur Datei, die Sie verteilen?
  • Qualität: Sind die geforderten Tests und weiteren Prüfungen erfolgreich?
  • Apple-Freigabe: Ist die Signatur für den vorgesehenen Distributionsweg gültig?
  • Entscheidung: Wer darf einen fehlenden oder nicht verifizierbaren Nachweis übersteuern?

Die Attestierung kann einen nachvollziehbaren Bezug zwischen Build und Artefakt liefern. Sie erklärt aber nicht, ob ein Commit einer Sicherheitsprüfung genügt, ob Tests angemessen sind oder ob die Freigabe durch Ihr Unternehmen zulässig ist. Diese Bedingungen müssen Sie in Ihren eigenen Richtlinien festlegen.

Wichtig: „Attestierung vorhanden“ ist kein Freigabekriterium. Erst wenn Identität und Dateidigest zur freigegebenen Pipeline und zum Release-Artefakt passen, ist der Herkunftsnachweis für diesen Release-Schritt brauchbar.

Herkunft und Workflow-Identität abgleichen

Beginnen Sie bei der Quelle mit den Angaben, die Ihr Release-Prozess erwartet: Repository, Commit und verwendeter Workflow. Vergleichen Sie diese mit dem Nachweis und dem Build-Auftrag. Ein gültiger Nachweis aus einem anderen Repository oder einem nicht genehmigten Workflow erfüllt Ihre Richtlinie nicht automatisch.

Die Workflow-Identität ist ein eigener Vertrauensentscheid. Eine Attestierung kann anzeigen, welcher Workflow beteiligt war; ob dieser Workflow intern zulässig ist, definieren jedoch Sie. Führen Sie deshalb eine genehmigte Liste oder Regel für Workflows, Repository-Pfade und auslösende Ereignisse. Prüfen Sie außerdem, ob der tatsächliche Release-Build von diesem genehmigten Pfad stammt – und nicht nur ein ähnlicher Testlauf.

Praktischer Fall: Ein Team erstellt ein Archiv aus einem Pull-Request-Build und lässt später einen Release-Workflow laufen. Beide Jobs sind erfolgreich, doch der Release-Workflow baut einen anderen Commit. Die bloße Existenz beider Ergebnisse reicht nicht. Der Nachweis muss zu genau dem Commit und der Datei gehören, die in den Release-Prozess übernommen werden.

Für die Verifikation bietet GitHub unter anderem das offizielle CLI-Verfahren. gh attestation verify prüft einen angegebenen Pfad gegen eine Attestierung; verwenden Sie die aktuelle Syntax und die Optionen aus der offiziellen Verifikationsanleitung. Ein Aufruf kann etwa so aussehen:

gh attestation verify <dateipfad> --repo <organisation>/<repository>

Behandeln Sie diesen Aufruf nicht als vollständige Unternehmensrichtlinie. Ein erfolgreiches Werkzeugergebnis beantwortet nicht von selbst, ob die erkannte Workflow-Identität in Ihrem Unternehmen freigegeben ist. Für wiederverwendbare Workflows beschreibt GitHub zusätzliche Verifikationsmöglichkeiten in der Anleitung zur Erhöhung der Sicherheitsbewertung. Prüfen Sie die dort genannten Optionen gegen Ihre tatsächliche Workflow-Struktur, bevor Sie daraus eine verbindliche Regel machen.

Den Digest am tatsächlich ausgelieferten Artefakt prüfen

Eine korrekte Quelle hilft nicht, wenn der Nachweis an einer anderen Datei hängt als der, die Ihr Release-System verteilt. Legen Sie daher im Build- und Release-Ablauf ausdrücklich fest, für welche Datei die Attestierung erzeugt wird: etwa für ein Archiv, ein exportiertes Paket oder ein konkretes Übergabeartefakt.

Das ist bei iOS besonders wichtig, weil zwischen Build und Auslieferung mehrere Artefaktstufen liegen können. Ein Archiv kann exportiert, umbenannt, erneut gepackt oder in ein Distributionssystem hochgeladen werden. Nach einer Dateiänderung kann der Digest des neuen Artefakts vom zuvor attestierten Digest abweichen. Die Verifikation muss dann auf dem späteren Release-Artefakt erfolgen oder Sie müssen nachvollziehbar dokumentieren, welche Datei geprüft wurde und welche Verarbeitungsschritte darauf folgten.

Verwechseln Sie deshalb nicht:

  • den Digest des Build-Ergebnisses,
  • den Digest eines später exportierten Pakets,
  • den Digest der Datei im Release- oder Übergabesystem.

Speichern Sie Dateiname, Digest, Commit und Build-Referenz so, dass die Zuordnung auch bei einer späteren Prüfung eindeutig bleibt. Ein Dateiname allein ist kein Identitätsnachweis: Er kann gleich bleiben, obwohl sich der Inhalt geändert hat.

Für die Erzeugung und den Abruf von Attestierungen sind Repository-Einstellungen und die jeweils geltenden GitHub-Bedingungen relevant. Prüfen Sie die aktuelle Übersicht zu GitHub-Sicherheitsfunktionen und Berechtigungen, statt eine Freigabe für ein Repository pauschal auf andere Projekte zu übertragen. Der GitHub-REST-API-Hinweis zu Attestierungen ist zusätzlich relevant, wenn Ihr Consumer Nachweise programmatisch abruft oder prüft.

Die betriebliche Abnahme in sechs Schritten ausführen

Führen Sie den Test mit einem realen Release-Ablauf Ihres Teams durch. Ein Beispielprojekt kann die Werkzeugbedienung zeigen, belegt aber nicht, dass Ihre produktive Pipeline die richtige Datei attestiert und kontrolliert.

  1. Release-Artefakt festlegen. Bestimmen Sie die Datei, die der nächste Prozess tatsächlich konsumiert. Dokumentieren Sie, ob die Prüfung ein Archiv, ein exportiertes Paket oder eine andere Übergabedatei betrifft.

  2. Quellbezug festhalten. Erfassen Sie Repository und Commit des Release-Builds. Stimmen Sie diese Angaben mit der Änderung ab, die für die Veröffentlichung genehmigt wurde.

  3. Attestierung in der freigegebenen Pipeline erzeugen. Nutzen Sie einen von Ihrer Organisation genehmigten Workflow. Prüfen Sie, ob der Build-Auftrag und der erzeugte Nachweis denselben Release-Pfad abbilden.

  4. Workflow-Identität prüfen. Verifizieren Sie, dass Repository und Workflow Ihrer internen Vertrauensregel entsprechen. Ein technisch gültiger Nachweis aus einem nicht zugelassenen Workflow muss als fehlgeschlagene Abnahme behandelt werden.

  5. Digest gegen die Übergabedatei vergleichen. Führen Sie die Verifikation für genau die Datei aus, die an Release, Testverteilung oder ein anderes Ziel übergeben wird. Prüfen Sie nach Export oder erneuter Verpackung erneut, statt von unveränderten Bytes auszugehen.

  6. Fehler und Freigabe dokumentieren. Legen Sie fest, ob ein fehlender, ungültiger oder nicht abrufbarer Nachweis den Release blockiert. Bestimmen Sie eine verantwortliche Rolle für Untersuchung und begründete Ausnahme. Halten Sie die Entscheidung zusammen mit Test- und Signaturbelegen fest.

Planen Sie dabei auch den Betrieb ein. Eine Verifikation kann scheitern, weil die Attestierung nicht erzeugt wurde, weil der Consumer keinen Zugriff auf den Nachweis hat oder weil sich der Release-Pfad verändert hat. Diese Fälle sind nicht gleichbedeutend. Trennen Sie „Nachweis fehlt“, „Nachweis nicht erreichbar“ und „Nachweis passt nicht zur Datei“. Nur so erhält Ihr Bereitschaftsteam eine belastbare Diagnose statt eines unklaren roten CI-Status.

Achten Sie außerdem auf Berechtigungen. Der Runner braucht nur die Zugriffe, die zum Erzeugen oder Prüfen des Nachweises erforderlich sind. Bewahren Sie Zugangsdaten nicht in ungeschützten Build-Ausgaben auf und begrenzen Sie, wer Attestierungs- oder Freigabeschritte verändern darf. Wenn ein Team gemeinsame Mac-Knoten verwendet, prüfen Sie dessen Zugriffs- und Isolationsmodell separat; eine Artifact Attestation ist keine Bestätigung, dass der Mac-Host oder seine Benutzertrennung sicher eingerichtet ist.

Tests, Apple-Signatur und Notarisierung getrennt behandeln

Die Release-Abnahme wird unvollständig, wenn sie Herkunftsprüfung und Apple-Signatur zu einem einzigen Status zusammenfasst. Ein Herkunftsnachweis kann die Build-Quelle stützen. Er zeigt nicht, ob das fertige Produkt die von Ihnen verlangten Tests bestanden hat. Ebenso ersetzt er nicht Apples Signaturprüfung.

Für iOS müssen Sie die Signatur und den vorgesehenen Verteilungsweg unabhängig prüfen. Apples Dokumentation zu Code-Signaturdiensten erläutert die Rolle der Signatur. Die Anleitung zur Verteilung einer App an registrierte Geräte beschreibt einen konkreten iOS-Verteilungsweg. Nutzen Sie die für Ihren Release geltenden Apple-Verfahren und speichern Sie deren Ergebnis getrennt von der Attestierungsprüfung.

Notarisierung ist ebenfalls kein Synonym für Attestierung. Apples Notarisierungsprozess bezieht sich auf die Verteilung von macOS-Software, nicht auf eine allgemeine iOS-Release-Abnahme. Wenn Ihr Unternehmen zusätzlich macOS-Software verteilt, prüfen Sie diesen Schritt separat anhand der Apple-Anleitung zur Notarisierung von macOS-Software.

Ordnen Sie die Ergebnisse daher getrennten Freigabefeldern zu:

  • Herkunftsprüfung: erwartetes Repository, Commit und Workflow?
  • Artefaktprüfung: Digest der tatsächlich konsumierten Datei passend?
  • Testprüfung: vorgeschriebene Tests erfolgreich und dem Build zugeordnet?
  • Signaturprüfung: gültig für den festgelegten Apple-Verteilungsweg?
  • Release-Entscheidung: Freigabe durch die dafür verantwortliche Rolle?

Das verhindert, dass ein grünes Attestierungsergebnis fälschlich als Gesamtfreigabe interpretiert wird. Für eine revisionsfähige Abnahme bewahren Sie die Belege zusammen mit eindeutigen Verweisen auf Commit und Release-Artefakt auf. Die Nachweise können gemeinsam archiviert werden; ihre Aussagen bleiben trotzdem verschieden.

Häufige Fragen zur Abnahme

Wie prüfen Sie die Herkunft eines iOS-Builds?

Verwenden Sie die offizielle GitHub-Verifikation, zum Beispiel über gh attestation verify, und vergleichen Sie das Ergebnis mit Ihrem genehmigten Release-Pfad. Entscheidend sind nicht nur ein erfolgreicher Befehl und eine vorhandene Attestierung. Prüfen Sie, ob Repository, Commit und Workflow den Vorgaben Ihrer Organisation entsprechen. Eine interne Vertrauensliste ist eine Richtlinienentscheidung, die Sie selbst pflegen müssen.

Welche Aussage lässt sich aus einer Attestierung ableiten?

Sie unterstützt den Nachweis, woher ein Build-Artefakt stammt und wie es einem Build zugeordnet ist. Sie bescheinigt nicht, dass der Quellcode frei von Schwachstellen ist oder dass Ihre Tests alle relevanten Fehler erkennen. Auch Apple-Signatur und Release-Genehmigung müssen separat geprüft werden. Behandeln Sie die Attestierung deshalb als Herkunftssignal innerhalb einer mehrteiligen Freigabe.

Wie vermeiden Sie eine Prüfung der falschen Datei?

Definieren Sie die Übergabedatei, bevor Sie den Release-Test durchführen, und prüfen Sie den Digest genau dieser Datei. Wenn Ihr Ablauf nach dem attestierten Build ein Archiv exportiert oder neu verpackt, validieren Sie das Ergebnis erneut. Halten Sie fest, welche Datei geprüft wurde. Eine Attestierung für eine frühere Build-Stufe beweist nicht automatisch, dass eine spätere Datei unverändert ist.

Ersetzt die Herkunftsprüfung Apples Signatur oder Notarisierung?

Nein. Für iOS prüfen Sie die Apple-Signatur und den Distributionsweg separat. Notarisierung ist ein eigener Prozess für macOS-Software und keine allgemeine iOS-Freigabe. Wenn Sie beide Plattformen veröffentlichen, führen Sie getrennte Prüfpfade und ordnen Sie jedes Ergebnis dem jeweiligen Release-Artefakt zu. So bleibt klar, welche Kontrolle tatsächlich bestanden wurde.

Abnahmeoptionen und Release-Gates vergleichen

Wählen Sie die Prüftiefe danach, wo die Datei in Ihrer Lieferkette entsteht und wer sie konsumiert. Die Tabelle trennt einen schnellen Entwicklercheck von einer produktiven Release-Abnahme. Der erste kann Fehler früh sichtbar machen; er ersetzt die verbindliche Consumer-Prüfung nicht.

Prüfmodell Was Sie prüfen Geeignet für Grenze
Lokale Stichprobe mit CLI Attestierung und ausgewähltes Artefakt Fehlersuche und Workflow-Entwicklung Keine automatische Freigaberegel; manuelle Interpretation bleibt nötig
Prüfung im CI-Consumer Quelle, Workflow-Regel und Digest bei der Übernahme Wiederholbare Release-Gates Benötigt gepflegte Richtlinien und eine definierte Fehlerbehandlung
Getrennte Release-Abnahme Herkunft, Tests, Apple-Signatur und Freigabe als eigene Ergebnisse Produktive iOS-Releases und Audit-Nachweise Mehrere Verantwortlichkeiten und Belege müssen verbunden werden

Für ein produktives Gate genügt es nicht, dass die Prüfung einmal erfolgreich war. Stellen Sie sicher, dass jeder relevante Release-Pfad die Prüfung ausführt und dass ein Fehler nicht stillschweigend in einen erfolgreichen Veröffentlichungsstatus übergeht. Die Attestierung muss außerdem mit der Datei verknüpft bleiben, die nachgelagerte Systeme tatsächlich beziehen.

Die Repository-Berechtigung ist ein weiterer Abnahmepunkt. Bestätigen Sie für jedes Projekt separat, ob Erzeugung und Verbrauch von Attestierungen unter den aktuellen GitHub-Bedingungen möglich sind. Verlassen Sie sich nicht auf eine erfolgreiche Probe in einem einzelnen Repository als Beleg für sämtliche Organisationen, Repository-Typen oder Veröffentlichungswege. Die Berechtigungsbedingungen können sich unterscheiden und sollten vor dem Rollout anhand der offiziellen Dokumentation geprüft werden.

Release-Kontrolle Positives Abnahmekriterium Verhalten bei Abweichung
Quelle und Commit Stimmen mit dem genehmigten Release überein Build nicht als freigegeben behandeln
Workflow-Identität Entspricht der internen Vertrauensregel Workflow prüfen; keine automatische Ausnahme
Artefakt-Digest Passt zur Datei am Consumer Datei und Verarbeitungsschritte untersuchen
Tests Vorgeschriebene CI-Ergebnisse liegen vor Release-Gate gemäß Richtlinie blockieren
Apple-Signatur Passt zum vorgesehenen Verteilungsweg Signatur- oder Exportfehler separat beheben
Verantwortliche Freigabe Entscheidung ist einer Rolle zugeordnet Keine stille Umgehung oder unklare Übergabe

Mac-Build-Umgebung separat abnehmen

Artifact Attestations weisen nicht nach, dass Ihre Mac-Build-Umgebung für den Unternehmenseinsatz zugelassen, isoliert oder verfügbar ist. Prüfen Sie Mac-Knoten daher separat: Wer darf sich anmelden? Welche Workflows dürfen Signaturmaterial verwenden? Wie werden Build-Artefakte übergeben? Was geschieht, wenn ein Runner nicht erreichbar ist? Diese Fragen betreffen Hostbetrieb und Zugriffskontrolle, nicht den Herkunftsnachweis des fertigen Artefakts.

Wenn Sie die Kapazität für Mac-Builds bewerten, beginnen Sie mit der Zahl paralleler Aufgaben, den Release-Fenstern und dem erforderlichen Zugriff auf Signaturmaterial. Trennen Sie dabei Build-Last von Sicherheitsanforderungen. Eine zusätzliche Maschine kann Wartezeiten abfedern, ersetzt aber weder ein geprüftes Berechtigungsmodell noch eine nachvollziehbare Artefaktkette. Für einen Hardwarevergleich können Sie die Angaben auf der MACCOME-Seite zur Mac-mini-Bestellung neben die Anforderungen an Ihren eigenen Betrieb legen.

Bei einem entfernten Mac sollten Sie vor einer Nutzung konkret klären, welche Zugangsmethode und welche Übergabewege für Ihren Prozess verfügbar sind. Prüfen Sie die tatsächlichen Liefer- und Zugriffsangaben, statt aus einer Attestierung auf eine bestimmte Host-Konfiguration zu schließen. Eine regionale Produktseite, etwa die Informationen zur Mac-mini-Bestellung im Silicon Valley, ist dafür nur dann relevant, wenn dieser Standort zu Ihren Anforderungen an Teamzugriff und Betriebsablauf passt.

Wenn Ihr Team ohnehin eigene Macs dauerhaft betreibt und die Auslastung planbar ist, kann der Kauf die passende Lösung sein. Müssen Sie dagegen vorübergehend zusätzliche Mac-Kapazität für einen Release-Pilot, eine Migration oder eine klar begrenzte CI-Last bereitstellen, vergleichen Sie den bestehenden Betrieb mit einer zeitlich flexiblen Mac-Option von MACCOME. Eigene Hardware bindet Kapital, erfordert Beschaffung und laufende Wartung; eine gemeinsam genutzte Build-Maschine kann außerdem zusätzliche Regeln für Zugriff und Isolation erfordern. Ein Miet-Mac löst diese Governance-Aufgaben nicht automatisch, kann aber für einen begrenzten Test oder eine vorübergehende Kapazitätserweiterung den Kauf weiterer Geräte vermeiden. Prüfen Sie vor der Entscheidung die konkreten Zugriffs-, Übergabe- und Betriebsbedingungen und nehmen Sie die Mac-Umgebung unabhängig von der Attestierung ab.