0Pricing
Cyber Security Academy · Lektion

CI/CD-Pipelines absichern

Build- und Release-Prozess härten

CI/CD-Pipelines absichern ist eine kostenlose Cyber Security Academy-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des Cyber Security Academy-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Die Pipeline als Ziel

Eine CI/CD-Pipeline hat privilegierten Zugriff auf Quellcode, Secrets und die Produktion. Eine Kompromittierung ermöglicht es einem Angreifer, in jeden zukünftigen Build Hintertüren einzuschleusen und dabei die Codeprüfung zu umgehen. Sie ist eines der wertvollsten Ziele in der modernen Softwareentwicklung.

Behandeln Sie die Pipeline wie Produktionsinfrastruktur: Sie verdient dieselbe Härtung, Überwachung und Disziplin beim Prinzip der geringsten Rechte wie Ihre Live-Systeme.

Nicht vertrauenswürdige Eingaben in Builds

Pipelines werden automatisch durch Ereignisse ausgelöst, die Sie nicht vollständig kontrollieren: Pull Requests, Tags und externe Beiträge. Ein bösartiger PR kann versuchen, den Build selbst zu verändern.

  • Eine manipulierte Pipeline-Definition in einem Fork kann versuchen, Secrets zu exfiltrieren
  • Nicht vertrauenswürdiger Code kann mit denselben Berechtigungen wie vertrauenswürdige Builds ausgeführt werden

Trennen Sie vertrauenswürdige und nicht vertrauenswürdige Workflows: Geben Sie Jobs, die durch externe Pull Requests ausgelöst werden, keine Secrets.

Actions und Images festschreiben

Pipelines beziehen häufig Actions von Drittanbietern oder Container-Images über ein veränderliches Tag. Wenn dieses Tag auf bösartigen Inhalt umgeleitet wird, ist Ihr Build kompromittiert. Verwenden Sie unveränderliche Digests.

# BAD: mutable tag can be moved under you
uses: some/action@v3

# GOOD: pinned to an immutable commit SHA
uses: some/action@a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0

# pin container steps by digest too
image: build-tools@sha256:9f86d081884c7d659a2feaa0c55ad015...

Prinzip der geringsten Rechte für Tokens

Standardmäßige Pipeline-Tokens verfügen häufig über zu viele Berechtigungen und gewähren Schreibzugriff auf das gesamte Repository oder die gesamte Registry. Beschränken Sie sie auf genau das, was jeder Job benötigt.

# scope the default token to read-only, grant more only where needed
permissions:
  contents: read

jobs:
  publish:
    permissions:
      contents: read
      packages: write   # only this job can publish

Secrets-Hygiene

Fest im Code hinterlegte oder weitreichend gemeinsam genutzte Secrets sind ein zentraler Weg für Datenlecks. Wenden Sie strenge Regeln an:

  • Speichern Sie Secrets in einem Secrets-Manager oder im Secret-Speicher der CI, niemals im Code
  • Bevorzugen Sie eine kurzlebige OIDC-Föderation gegenüber statischen Cloud-Schlüsseln
  • Maskieren Sie Secrets in Protokollen und verhindern Sie, dass sie ausgegeben werden
  • Beschränken Sie jedes Secret auf die minimal erforderlichen Jobs und Umgebungen

Die OIDC-Föderation ermöglicht es der Pipeline, eine Buildzeit-Identität gegen kurzlebige Cloud-Zugangsdaten einzutauschen, sodass langlebige Schlüssel vollständig entfallen.

Ephemere, isolierte Runner

Ein wiederverwendeter Build-Runner kann Malware oder geleakte Secrets von einem Job zum nächsten übertragen. Ephemere Runner werden für jeden Job neu erstellt und anschließend zerstört, sodass nichts bestehen bleibt.

  • Eine saubere Umgebung pro Build, die anschließend verworfen wird
  • Kein gemeinsamer Zustand zwischen vertrauenswürdigen und nicht vertrauenswürdigen Jobs
  • Netzwerkzugriff nach außen auf die erforderlichen Endpunkte beschränkt

Dies unterstützt unmittelbar die Isolationsziele von SLSA L3.

Den Quell-Branch schützen

Das Vertrauen in die Pipeline beginnt bei der Quellcodeverwaltung. Wenn jeder auf den Release-Branch pushen kann, sind nachgelagerte Signaturen und Scans gegenstandslos.

  • Vor dem Zusammenführen eine Prüfung des Pull Requests verlangen
  • Signierte Commits auf geschützten Branches erzwingen
  • Verlangen, dass Statusprüfungen (Tests, Scans) erfolgreich sind
  • Force-Push und direktes Pushen auf main untersagen
# require signed commits on a branch
git config commit.gpgsign true

# verify a commit signature locally
git verify-commit HEAD

In der Pipeline scannen

Bauen Sie Sicherheitsprüfungen direkt in die CI ein, damit Probleme den Build fehlschlagen lassen, statt in die Produktion zu gelangen.

# secret leak detection
gitleaks detect --source . --redact

# dependency vulnerabilities
osv-scanner --lockfile=package-lock.json

# IaC and config misconfig
trivy config .

# fail the job on critical findings (non-zero exit stops CI)

Vier-Augen-Prinzip für Releases

Maßnahmen mit großer Auswirkung verdienen eine menschliche Kontrollinstanz. Produktionsbereitstellungen und Änderungen an Zugangsdaten sollten die Genehmigung einer anderen Person als des Autors erfordern.

  • Schutzregeln für Umgebungen verlangen vor der Bereitstellung eine Prüfung
  • Trennen Sie die Identität für den Build von der Identität für die Bereitstellung
  • Keine einzelne Person darf sowohl Code erstellen als auch ungeprüft in die Produktion übertragen

Dies begrenzt sowohl das Insider-Risiko als auch das Schadensausmaß eines einzelnen kompromittierten Kontos.

Auditierung und Manipulationsnachweis

Sie müssen nachvollziehen können, was die Pipeline getan hat. Zentralisieren und schützen Sie ihre Protokolle.

  • Leiten Sie CI-Protokolle an einen nur erweiterbaren, zugriffskontrollierten Speicher weiter
  • Halten Sie fest, wer Pipeline-Definitionen wann geändert hat
  • Erzeugen Sie eine signierte Provenienz, damit Artefakte auf einen bestimmten Build zurückgeführt werden können
  • Alarmieren Sie bei Anomalien: neuer selbst gehosteter Runner, unerwarteter Zugriff auf Secrets, Konfigurationsänderung außerhalb der Prüfung

Checkliste zur Pipeline-Härtung

Eine belastbare Pipeline verbindet Kontrollen für Quellcode, Build und Release:

  • Branch-Schutz sowie geprüfte und signierte Commits
  • Actions und Images anhand ihres Digests festgeschrieben
  • OIDC-Tokens mit geringsten Rechten und kurzer Laufzeit
  • Ephemere, isolierte Runner
  • Scans auf Secrets, Abhängigkeiten und Konfigurationen innerhalb der Pipeline
  • Release-Freigabe nach dem Vier-Augen-Prinzip
  • Signierte Artefakte, SBOM und Provenienz mit Audit-Protokollierung

Schnelltest: Token-Berechtigungen

Entscheiden Sie, welche Kontrolle für ein privilegiertes Build-Token geeignet ist.

Zusammenfassung: CI/CD-Pipelines absichern

Sie haben gelernt, den gesamten Build- und Release-Pfad zu härten.

  • Behandeln Sie die Pipeline wie Produktion; sie kann in jeden zukünftigen Build eine Hintertür einschleusen
  • Isolieren Sie nicht vertrauenswürdige PR-Builds von Secrets
  • Schreiben Sie Actions und Images anhand ihres Digests fest; verwenden Sie OIDC-Tokens mit geringsten Rechten und kurzer Laufzeit
  • Verwenden Sie ephemere, isolierte Runner und schützen Sie den Quell-Branch
  • Scannen Sie innerhalb der Pipeline, verlangen Sie die Freigabe eines Releases nach dem Vier-Augen-Prinzip und führen Sie manipulationsnachweisbare Audit-Protokolle

Der Kurs ist abgeschlossen: Sie können die Software-Lieferkette jetzt durchgängig absichern.

Häufig gestellte Fragen

Ist die Lektion „CI/CD-Pipelines absichern“ kostenlos?

Ja — der vollständige Text von „CI/CD-Pipelines absichern“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des Cyber Security Academy-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der Cyber Security Academy-Kurs umfasst insgesamt 4 Lektionen.

Was lerne ich in „CI/CD-Pipelines absichern“?

Build- und Release-Prozess härten Du übst Cyber Security Academy mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.

Brauche ich Erfahrung, um Cyber Security Academy zu starten?

Keine Vorkenntnisse erforderlich. Cyber Security Academy auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.

Wie lange dauert die Lektion „CI/CD-Pipelines absichern“?

Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.

Kann ich in dieser Cyber Security Academy-Lektion Code schreiben und ausführen?

Ja. Jede Cyber Security Academy-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.

Alle Lektionen in diesem Kurs

  1. Bedrohungen der Lieferkette
  2. Software Bill of Materials (SBOM)
  3. Signieren von Abhängigkeiten und Artefakten
  4. CI/CD-Pipelines absichern
← Zurück zu Cyber Security Academy