GitHub Actions CI/CD Engineering für sichere, schnelle Software-Auslieferung

GitHub Actions ist die richtige Standardwahl, wenn Ihr Quellcode bereits auf GitHub liegt – keinerlei Infrastruktur zu pflegen, native Integration mit Pull Requests, Dependabot und dem GitHub Security Graph. Jenkins eignet sich für Teams mit komplexer On-Premises-Infrastruktur und ausgereiften Shared Libraries. GitLab CI ist die natürliche Wahl, wenn die gesamte DevSecOps-Plattform in GitLab betrieben wird. Eine Migration von Jenkins oder GitLab CI zu GitHub Actions erfordert für einen mittelgroßen Pipeline-Bestand typischerweise ein bis zwei Wochen.

OIDC-Keyless-Deployment ersetzt langlebige Cloud-Credentials (AWS Access Keys, GCP Service Account JSON), die als GitHub Secrets gespeichert sind, durch kurzlebige Tokens des GitHub Identity Providers. Jeder Job erhält ein Token, das genau für das jeweilige Repository, den Branch und die Umgebung gültig ist und auf die minimal notwendigen IAM-Berechtigungen beschränkt ist. Das Token läuft nach Abschluss des Jobs ab – es gibt nichts zu rotieren, nichts preiszugeben und nichts nach einem Sicherheitsvorfall zu widerrufen.

Für die meisten Workloads empfehlen wir GitHub-hosted runners – kein Wartungsaufwand und ein sauberer Zustand pro Job. Self-hosted runners sind sinnvoll, wenn Builds spezifische Hardware (GPU, ARM, High-Memory) benötigen, auf private Netzwerkressourcen zugreifen müssen, die nicht öffentlich zugänglich sein können, oder wenn bei sehr hohem Build-Volumen eine Kostenoptimierung erforderlich ist. Beim Einsatz von self-hosted runners müssen diese ephemer sein – per GitHub Actions Runner Controller oder einer Cloud-Auto-Scaling-Gruppe für jeden Job frisch provisioniert.

SLSA (Supply-chain Levels for Software Artefacts) Provenance ist eine signierte Aussage, die genau festhält, welcher Quell-Commit, welche Build-Toolchain und welche Build-Umgebung ein bestimmtes Artefakt erzeugt haben. GitHub Actions erzeugt sie über die slsa-framework/slsa-github-generator-Action, die in einem isolierten reusable Workflow läuft und die Attestierung mit cosign über das keyless Protokoll von Sigstore signiert. Verbraucher können die Provenance unabhängig mit der cosign CLI vor dem Deployment verifizieren.

Wir verfolgen einen vierstufigen Ansatz: unabhängige Jobs im Workflow-Graph parallelisieren, Dependency-Caching hinzufügen (actions/cache für npm, pip, Maven, Gradle), auf Docker buildx mit GHCR-Layer-Caching umstellen, um unveränderte Layer nicht neu zu bauen, und Turborepo oder Nx Affected-Analyse integrieren, um unveränderte Pakete in Monorepos zu überspringen. Ein typisches erstes Audit reduziert die Pipeline-Laufzeit um 40–70 %, ohne eine einzige Zeile Applikationscode zu ändern.

GitHub Encrypted Secrets sind die richtige Grundlage – sie werden in Logs maskiert und niemals fork-basierten Pull Requests zugänglich gemacht. Für Produktions-Deployments ersetzen Sie statische Secrets durch OIDC-Tokens (kein Secret notwendig). Für Secrets, die unbedingt existieren müssen (API-Keys, Signing-Zertifikate), verwenden Sie environment-scoped Secrets mit Protection Rules, die vor dem Job-Zugriff eine manuelle Freigabe erfordern. Secret Scanning bei jedem Push verhindert versehentliche Commits, bevor sie das Remote erreichen.

Wir integrieren Turborepo oder Nx mit GitHub Actions über dynamische Matrix-Generierung. Ein Setup-Job führt die Affected-Graph-Analyse durch und gibt eine JSON-Matrix der geänderten Pakete aus. Nachfolgende Jobs fächern sich über die Matrix parallel auf – jedes Paket erhält einen isolierten Test- und Build-Job. Unveränderte Pakete werden vollständig übersprungen. Die Ergebnisse werden in einem einzigen erforderlichen Status-Check zusammengeführt, der Merges absichert – die Merge Queue sieht ein grünes Signal unabhängig von der Monorepo-Größe.