Wie bleiben Mac-CI-Prüfnachweise nach Änderung der GitHub-Actions-Aufbewahrung erhalten? 2026

Nachweisumfang statt bloßer Statusanzeige

Für die Auditplanung sollten Sie zunächst unterscheiden, welche Aussage ein Datensatz überhaupt belegt. Ein erfolgreicher Status kann das Ergebnis einer Prüfung anzeigen, enthält aber nicht automatisch deren vollständiges Protokoll oder das dazugehörige Build-Artefakt. Ein Workflow-Lauf ist wiederum nicht dasselbe wie ein unabhängig gespeicherter Export.

GitHub nennt drei Arten von Einträgen, die von der Änderung betroffen sind: Prüfungen, Workflow-Ausführungen und Commit-Statusinformationen. Die offizielle Mitteilung umfasst relevante Einträge aus Actions ebenso wie solche, die durch Drittanbieterintegrationen erstellt wurden. Die REST-Dokumentation zu Check Runs und Commit-Statusinformationen beschreibt diese Objekte getrennt. Behandeln Sie eine externe Prüfung oder einen Status deshalb nicht als nebensächlich, nur weil der Eintrag nicht aus dem eigenen Workflow stammt.

Für Mac-CI-Audits gehören mindestens diese Nachweisgruppen in die Bestandsaufnahme:

• Prüfungen und Commit-Status: Ergebnis, Quelle und Zuordnung zum Commit.
• Workflow-Ausführungen: Laufkennung, Auslöser, Abschlusszustand und Verknüpfung zum Code-Stand.
• Protokolle: Ausführungsdetails, die bei einer Prüfung oder Fehlersuche benötigt werden.
• Build-Dateien: etwa Testberichte, Archivdateien oder Symboldateien, sofern sie für Freigabe, Untersuchung oder erneute Prüfung erforderlich sind.

Das ist der zentrale Schutz vor einem häufigen Fehlschluss: Wenn eine Prüfung in der Oberfläche noch sichtbar ist, folgt daraus nicht, dass ein benötigtes Protokoll oder eine Datei ebenfalls heruntergeladen werden kann. Umgekehrt beweist eine archivierte Datei für sich allein nicht, aus welchem Lauf sie stammt. Für jede Gruppe muss deshalb eine eigene Aufbewahrungs- und Wiederherstellungsentscheidung dokumentiert werden.

Rückverfolgbarkeit einer Freigabe

Eine belastbare Freigabe lässt sich vom Ergebnis zurück zum ausgeführten Code verfolgen. Definieren Sie vor dem Export, welche Verknüpfungen Ihr Audit verlangt: typischerweise Commit, Workflow-Lauf, Prüfergebnis und Statusquelle. Wenn die Freigabe von einer externen Integration abhängt, muss deren Ergebnis ebenfalls zuordenbar sein.

Verwenden Sie einen stabilen Index und nicht allein einen Ordner mit Dateien. Ein Eintrag kann zum Beispiel folgende Felder enthalten:

repository:
commit:
workflow_run:
check_or_status_source:
result:
artifact_path:
log_path:
exported_at:
archive_reference:

Die konkreten Werte müssen aus Ihrem System stammen; das Beispiel ist ein Schema und kein vorbefüllter Datensatz. Legen Sie außerdem fest, welche Felder für eine Veröffentlichung zwingend vorhanden sein müssen. Fehlt etwa die Statusquelle, kann eine prüfende Person möglicherweise nicht unterscheiden, ob das Ergebnis aus dem eigenen CI-Lauf oder einer Drittanbieterprüfung stammt.

Nutzen Sie für die Erhebung nur die tatsächlich verfügbaren Schnittstellen und Berechtigungen Ihrer Organisation. Das Checks-API und die API für Commit-Statusinformationen helfen dabei, diese Objektarten auseinanderzuhalten. Die Tatsache, dass ein API-Eintrag abrufbar war, ist aber noch kein Nachweis, dass er in Ihrem externen Archiv angekommen oder dort später wieder auffindbar ist.

Ein einfaches Manifest kann die Zuordnung zwischen Datei und Archivbestand nachvollziehbar machen. Auf einem Mac lassen sich beispielsweise für einen bereits exportierten Ordner Prüfsummen erzeugen:

find ./ci-export -type f -print0 \
  | sort -z \
  | xargs -0 shasum -a 256 > ./ci-export-manifest.sha256

shasum -a 256 -c ./ci-export-manifest.sha256

Der erste Befehl dokumentiert Prüfsummen für vorhandene Dateien; der zweite kontrolliert, ob die geprüften Dateien noch zu diesen Prüfsummen passen. Das ersetzt weder Herkunftsinformationen noch Zugriffskontrollen und beweist auch nicht, dass der Export vollständig war. Gleichen Sie dafür die erwarteten Objekte zusätzlich mit dem Index ab. Speichern Sie Manifest und Index so, dass sie selbst in den vorgesehenen Wiederherstellungsprozess einbezogen werden.

Aufbewahrungsfenster und Einstellungsebenen

Das passende Aufbewahrungsfenster ergibt sich aus den eigenen Prüf-, Untersuchungs- und Geschäftsanforderungen. Übernehmen Sie keine pauschale Frist, wenn Ihr Unternehmen unterschiedliche Anforderungen für Entwicklungszweige, Veröffentlichungen oder Sicherheitsfälle festgelegt hat. Vergleichen Sie stattdessen das definierte Auditfenster mit der tatsächlich wirksamen Konfiguration und dokumentieren Sie Ausnahmen.

Prüfen Sie, welche Richtlinien auf Unternehmens-, Organisations- und Repository-Ebene gelten und welche Grenzen eine übergeordnete Richtlinie setzt. Eine Einstellung auf Repository-Ebene darf nicht als wirksame Verlängerung interpretiert werden, bevor die maßgebliche Obergrenze geklärt ist. GitHub erläutert die Konfiguration für Artefakte und Protokolle in der Dokumentation zu den Organisations-Einstellungen. Vergleichen Sie diese Dokumentation mit der konkreten Konfiguration Ihrer Organisation, statt aus einer einzelnen Repository-Anzeige auf alle Ebenen zu schließen.

Für die Prüfung eignet sich ein Konfigurationsprotokoll mit folgenden Angaben:

• geltende Einstellung und Ebene, auf der sie gepflegt wird;
• übergeordnete Grenze oder Richtlinie, die eine Änderung einschränkt;
• betroffene Repositories und begründete Ausnahmen;
• verantwortliche Person für Genehmigung und Umsetzung;
• Zeitpunkt der Prüfung und Verweis auf den Konfigurationsnachweis.

Wenn Ihre Untersuchung zeigt, dass die vorhandene Plattformaufbewahrung kürzer ist als das interne Audit- oder Ermittlungsfenster, genügt es nicht, nur eine Änderung der Einstellung zu beantragen. Sorgen Sie dafür, dass die benötigten Einträge rechtzeitig unabhängig exportiert werden. Eine spätere Anpassung der Aufbewahrung repariert keine bereits entstandene Datenlücke. Halten Sie im Prüfprotokoll fest, welche Anforderung durch Plattformaufbewahrung abgedeckt wird und welche durch ein externes Archiv erfüllt werden muss.

Entscheidungs- und Nachweismatrix

Die folgende Matrix ist ein Auswahlwerkzeug: Sie ordnet jeder Nachweisart eine verantwortliche Stelle, einen Aufbewahrungsweg und ein Abnahmekriterium zu. Nutzen Sie sie, um Lücken zwischen Plattformdaten und unabhängig archivierten Inhalten sichtbar zu machen.

Ein Eintrag in der Matrix gilt nicht allein deshalb als abgenommen, weil ein Team den Export eingeschaltet hat. Entscheidend ist, ob der definierte Nachweis im vorgesehenen Archiv vorliegt, auffindbar ist und einer konkreten Prüfung oder Veröffentlichung zugeordnet werden kann. Die Zuständigkeit für Plattformdaten darf außerdem nicht stillschweigend mit der Verantwortung für langfristig benötigte Build-Dateien gleichgesetzt werden.

Archivierung und Wiederherstellungsprobe

Die Archivierung sollte vom benötigten Nachweis ausgehen, nicht vom verfügbaren Exportknopf. Erfassen Sie für jedes Objekt die Quelle, den Bezug zu Commit und Lauf, den vorgesehenen Speicherort, die zugriffsberechtigten Rollen und den Rückweg für eine Prüfung. Workflow-Artefakte sind eigenständige Dateien; die Ablage eines Statusdatensatzes sichert sie nicht automatisch mit.

Richten Sie einen Ablauf ein, der Export und Index gemeinsam aktualisiert. Der Index sollte nicht nur einen Pfad enthalten, sondern auch einen Schlüssel, über den ein Team nach Commit, Workflow oder Veröffentlichungsbezug suchen kann. Legen Sie fest, wer einen fehlgeschlagenen Export erkennt, wer ihn erneut ausführt und wie eine nicht verfügbare Quelle als Ausnahme dokumentiert wird.

Führen Sie danach eine Wiederherstellungsprobe durch:

1. Wählen Sie einen repräsentativen Commit oder eine Veröffentlichung aus, deren Nachweise im Archiv vorhanden sein sollen.
2. Suchen Sie über den vorgesehenen Index nach Workflow-Lauf, Statusquelle, Protokoll und benötigten Build-Dateien.
3. Rufen Sie die Dateien aus dem Archiv ab und kontrollieren Sie, ob sie lesbar sind und zum Manifest passen.
4. Prüfen Sie, ob eine prüfende Person die Beziehungen zwischen Commit, Lauf, Ergebnis und Datei ohne Zugriff auf ein einzelnes Teamkonto erklären kann.
5. Halten Sie fehlende Objekte, Zugriffsprobleme und nicht nachvollziehbare Zuordnungen fest; schließen Sie die Lücke, bevor der Prozess als abgenommen gilt.

GitHub dokumentiert den Abruf von Workflow-Protokollen als eigenen Vorgang. Auch das Entfernen von Workflow-Artefakten wird separat beschrieben. Prüfen Sie daher für jeden benötigten Datentyp gesondert, was noch auf der Plattform liegt und was Ihr Archiv tatsächlich enthält. Ein erfolgreicher Abruf eines Protokolls belegt nicht, dass Build-Dateien vorhanden sind; eine gespeicherte Build-Datei belegt nicht, dass die dazugehörige Prüfung und ihr Status ebenfalls gesichert wurden.

Behandeln Sie die Probe nicht als einmalige Demonstration ohne Folgemaßnahmen. Dokumentieren Sie, welche Rolle den Test ausgeführt hat, welche Nachweise verwendet wurden und welche Abweichungen auftraten. Wenn sich eine Datei öffnen lässt, die Beziehung zum Lauf aber nicht belegt werden kann, ist die Wiederherstellung nur teilweise gelungen. Wenn der Index zwar einen Speicherort nennt, dort aber kein lesbares Objekt liegt, ist die Archivierung ebenfalls nicht abgenommen.

Rollen, Freigabe und Abschlussnachweis

Eine Änderung der Aufbewahrung braucht einen nachvollziehbaren Verantwortungsweg. Organisationsadministratoren prüfen und dokumentieren die maßgebliche Einstellung. Repository-Verantwortliche melden lokale Ausnahmen und prüfen, ob die vorgesehenen Läufe erfasst werden. Sicherheits- oder Auditverantwortliche definieren die erforderliche Nachweiskette und prüfen Zugriffe. Das Mac-CI-Plattformteam stellt sicher, dass Protokolle und Build-Dateien getrennt erfasst und in der Wiederherstellungsprobe berücksichtigt werden.

Bündeln Sie für die Abnahme drei Arten von Belegen: einen Konfigurationsnachweis für die geltende Richtlinie, einen Index der exportierten Nachweise und das Ergebnis einer Wiederherstellungsprobe. Ergänzen Sie die Freigabeentscheidung um die verantwortlichen Rollen und offene Ausnahmen. Das Paket sollte nicht behaupten, dass eine Plattform oder ein Dienst automatisch Compliance gewährleistet. Es soll belegen, welche Nachweise Ihr Unternehmen tatsächlich gesichert und geprüft hat.

Prüfen Sie außerdem, ob die Berechtigungen für Export, Archivzugriff und Löschung voneinander abgegrenzt sind. Wer eine Datei ablegen kann, sollte nicht automatisch alle Auditdaten verändern dürfen. Dokumentieren Sie, wer Ausnahmen genehmigt, wie ein Zugriff widerrufen wird und welche Stelle die Vollständigkeit der Nachweise bestätigt. Diese Angaben helfen, technische Verfügbarkeit und organisatorische Freigabe auseinanderzuhalten.

Häufige Fragen

Welche Einträge können von der geänderten GitHub-Actions-Aufbewahrung betroffen sein?
Prüfungen, Workflow-Ausführungen und Commit-Statusinformationen fallen seit dem von GitHub genannten Wirksamkeitsdatum unter die Actions-Aufbewahrungseinstellungen. Die Änderung umfasst relevante Einträge aus Actions und Drittanbieterintegrationen. Protokolle und Dateien müssen zusätzlich separat betrachtet werden, denn ein vorhandener Status sagt nicht aus, dass sie ebenfalls verfügbar sind.

Wie bleiben Statusinformationen und Workflow-Läufe gemeinsam nachvollziehbar?
Erfassen Sie die Verknüpfung von Commit, Laufkennung, Ergebnis und Statusquelle in einem durchsuchbaren Index. Exportieren Sie die benötigten Datensätze unabhängig und nehmen Sie Drittanbieterprüfungen in die Bestandsaufnahme auf. Prüfen Sie beim Wiederherstellungstest, ob eine Person die Freigabe vom Ergebnis bis zum Code-Stand zurückverfolgen kann.

Stellt eine verlängerte Aufbewahrungsfrist gelöschte Prüfdaten wieder her?
Nein. Die Änderung einer Einstellung ist keine Wiederherstellungsfunktion für bereits gelöschte Daten. Prüfen Sie zuerst, ob die Einträge noch abrufbar sind. Ist das nicht der Fall, muss eine vorhandene externe Kopie gefunden oder eine verbleibende Nachweislücke dokumentiert werden; eine geänderte Frist allein genügt nicht.

Wie unterscheiden sich die Archivierungswege für Mac-CI-Protokolle und Build-Dateien?
Protokolle dokumentieren den Ablauf eines Laufs; Build-Dateien sind eigenständige Artefakte. Statusinformationen belegen Ergebnisse, ersetzen aber weder Protokoll noch Datei. Definieren Sie für jede Gruppe Quelle, Ablage, Indexbezug, Berechtigungen und Wiederherstellungsprobe getrennt, damit ein erfolgreicher Export nicht mit einer vollständigen Sicherung verwechselt wird.

Beginnen Sie mit der Matrix und prüfen Sie, ob jedes benötigte Auditobjekt einen Verantwortlichen, einen Archivort und einen getesteten Wiederherstellungsweg hat. Wenn Ihrem Team zusätzlich ein eigener macOS-Build-Knoten fehlt, klären Sie zuerst dessen Zugriffs- und Betriebsanforderungen; ein gemieteter Mac ersetzt weder den Export noch die Prüfung der Nachweise. Eine Remote-Mac-Umgebung für CI-Arbeiten kann bei der Bewertung eines zusätzlichen Knotens helfen. NodeMini kommt als Option für einen temporären oder ergänzenden Mac-CI-Knoten infrage, wenn eine Anschaffung nicht zum aktuellen Bedarf passt. Für die technische Planung können Sie außerdem die Anforderungen an einen Mac mini für den Unternehmenseinsatz prüfen. Die Archivierungsrichtlinie und ihre Abnahme bleiben in jedem Fall Aufgabe Ihres Teams.