Worauf CRACI zugreifen kann und was es speichert

Warum diese Frage eine klare Antwort verdient

Ein CI-Runner sieht mehr als die meisten Tools in Ihrem Stack. Er checkt Ihren Quellcode aus, installiert Ihre Abhängigkeiten und hält die Secrets bereit, mit denen Ihre Workflows Pakete veröffentlichen und deployen. Als die GitHub Action tj-actions/changed-files im März 2025 kompromittiert wurde, berichtete CISA, dass der bösartige Code Secrets offenlegte, darunter Access Keys, GitHub Personal Access Tokens, npm-Tokens und private RSA-Schlüssel. Der Runner ist der Ort, an dem diese Secrets liegen, während ein Job läuft.

Bevor Sie einen Workflow auf CRACI umstellen, sollten Sie also genau wissen, worauf es zugreifen kann. Die Antworten stehen unten, und das CRACI Trust Center und docs.craci.com liefern die Details.

Wozu die GitHub App dient

CRACI ersetzt den Runner, nicht GitHub Actions. Sie behalten Ihre Workflows, ändern runs-on für die Jobs Ihrer Wahl auf craci, und die Läufe erscheinen weiterhin in der GitHub-Oberfläche. Damit das funktioniert, installiert Ihre Organisation die CRACI GitHub App.

Bei der Installation gewähren Sie der App Zugriff entweder auf alle Repositories oder auf eine Auswahl. Nur Repositories, für die Sie Zugriff gewährt haben, können Workflows auf CRACI ausführen.

Die genauen Berechtigungen, die die App anfordert, stehen auf dem Installationsbildschirm von GitHub, und Sie können sie danach in Ihren Organisationseinstellungen einsehen. Kurz gesagt: Die App kann Ihren Code und Ihre Actions-Läufe lesen, und sie verwaltet die Runner, die sie für Ihre Organisation registriert.

Wo Ihr Code läuft

Jobs werden in isolierten virtuellen Maschinen ausgeführt. Die Build-Ausführung läuft auf europäischer Bare-Metal-Infrastruktur. Ihr Quellcode wird für die Dauer des Builds in der Job-VM verarbeitet.

Jeder Job läuft auf einem von drei Images: CRACI Slim, CRACI Slim ARM64 oder einem GitHub-kompatiblen Ubuntu-24.04-Image. Runner gibt es heute nur für Linux; Windows und macOS sind auf der Roadmap.

Wie Jobs isoliert werden und was mit der VM eines Jobs nach dessen Ende geschieht, ist auf docs.craci.com und im Trust Center dokumentiert.

Was CRACI speichert und wie lange

CRACI verarbeitet Ihren Quellcode während des Builds in der Job-VM und speichert ihn nicht. Aufbewahrt werden die Nachweise, die CRACI zu jedem Build aufzeichnet, sowie die Caches, die Ihre Workflows speichern:

• Build-Metadaten
• Paketdaten, also die Abhängigkeiten, die jeder Job geladen hat
• Netzwerk-Traces des Jobs
• SBOMs
• Provenienzaufzeichnungen
• Caches
• Audit-Aufzeichnungen

Ein Cache enthält, was immer Ihr Workflow hineinlegt. Behandeln Sie Cache-Inhalte also wie jede andere Build-Ausgabe.

Die Standard-Aufbewahrungsdauer beträgt 180 Tage. Enterprise-Pläne können eine individuelle Aufbewahrungsdauer festlegen. Datenlöschung und Verschlüsselung behandelt das Trust Center.

Hosting und Datenresidenz

CRACI wird in Europa gehostet und bietet Datenresidenz in der EU, mit Build-Ausführung auf europäischer Bare-Metal-Infrastruktur. Die Plattform läuft bei Hetzner, einem deutschen Anbieter, in einem Rechenzentrum in Tuusula, Finnland. Welche Daten CRACI verarbeitet, lesen Sie unter Datenresidenz.

Kontrollen für den Build selbst

Ein Runner, der Ihre Secrets sieht, sollte Sie auch begrenzen lassen, wohin sie gelangen können. Die Netzwerk-Egress-Richtlinien von CRACI legen für jeden Job einen Standard von Deny oder Allow fest, mit 24 integrierten Presets für gängige Softwarequellen und typisierten benutzerdefinierten Quellen für Registries wie npm, PyPI, Cargo, Go Proxy und OCI. Sie können auch explizite TLS-, TCP-, UDP- und ICMP-Regeln schreiben. Richtlinien werden vor dem Start des Jobs validiert, blockieren im Zweifel (fail closed) und weisen unbekannte Felder zurück. Warnungen weisen auf Richtlinienverstöße hin.

Jobs kommunizieren nach außen über einen stabilen Egress-IP-Bereich, sodass Sie CRACI-Runner in Ihren eigenen Firewalls per Adresse zulassen können.

Zugriff innerhalb Ihrer Organisation

• Enterprise-Pläne unterstützen SAML Single Sign-on mit Google Workspace als Identitätsanbieter.
• Ein Admin-Audit-Log zeichnet administrative Aktionen auf. Es ist in der Oberfläche verfügbar und kann noch nicht exportiert werden.
• API-Tokens werden von Admins erstellt, können jederzeit widerrufen werden und laufen nach 90 Tagen ab.

So halten Sie den Umfang klein

Um CRACI zu evaluieren, müssen Sie ihm nicht Ihre gesamte Organisation geben.

1. Installieren Sie die App für ausgewählte Repositories. Wählen Sie bei der Installation der App „Only select repositories“ und ein oder zwei Repositories aus. Sie können die Auswahl später in den Settings Ihrer Organisation unter GitHub Apps, CRACI, Configure erweitern oder einschränken. Die Änderung wird sofort wirksam.
2. Verlagern Sie einen Job nach dem anderen. Nur Jobs mit runs-on: craci laufen auf CRACI. Alles andere bleibt auf dem Runner, den es heute nutzt.
3. Beginnen Sie mit einem Job, der wenige Secrets nutzt. Ein Test- oder Lint-Job zeigt Ihnen die SBOM und die Netzwerk-Nachweise, ohne Zugangsdaten zum Veröffentlichen oder Deployen auf einen neuen Runner zu bringen.
4. Aktivieren Sie eine Default-Deny-Egress-Richtlinie. Erlauben Sie die Paketquellen, die der Job braucht, und nichts anderes.
5. Wissen Sie, wie Sie wieder aussteigen. In GitHub können Sie die App sperren, was ihren Zugriff blockiert, sie aber installiert lässt, oder sie deinstallieren, was ihren Zugriff auf Ihre Organisation entfernt.

Unsere Sicherheitslage

Unsere Sicherheitsseite erklärt unseren Ansatz: dokumentiert, nicht behauptet. Das Trust Center bündelt die Richtlinien, Kontrollen und Dokumentation hinter der Plattform, und dort können Sie Unterlagen für eine Lieferantenbewertung anfordern.

Diese Seite trifft keine Aussagen zu Zertifizierungen. Den aktuellen Stand unseres Sicherheitsprogramms und etwaiger Audits finden Sie im Trust Center.