Der Feind in meinem Repo

In diesem Commit lag ein beispielhaftes Kickstart-File. Darin, oh Schreck und Graus: der Hostname meiner damaligen dienstlichen Workstation. Ein furchtbar kreativer Name wie workstation-pope-01. Ja, ich weiß, ich schäme mich heute auch dafür. Inzwischen sind meine Maschinen nach ägyptischen Göttern benannt – Anubis, Horus, Thot. Das klingt nicht nur cooler, es ist auch… nun ja, es ist einfach cooler.

Aber der Hostname war nicht alles. Das Kickstart-File setzte natürlich auch initiale Passwörter für Root und einen User. Ein notwendiges Übel, denn irgendeinen Zustand muss die Kiste ja nach der Installation haben, bevor das Ansible-Playbook übernimmt und alles mit kryptisch sicheren Passwörtern versiegelt.

Die Eskalation: Von Null auf CISO in 3,5 Sekunden

Für einen erfahrenen Admin ist der Fall klar: Ein initiales Setup-File, dessen Passwörter eine Halbwertszeit von wenigen Minuten haben und das einen internen Hostnamen enthält, der längst zu Elektroschrott verarbeitet wurde. Kritikalität? Nahe Null.

Für unsere Security-Youngsters? ALARMSTUFE TIEFROT!

Ich stelle mir bildlich vor, wie die Tastaturen klappern, die Augen sich weiten und jemand ruft: “Wir haben ihn! Den Generalschlüssel zum Internet!” Statt kurz den Hörer in die Hand zu nehmen und zu fragen: “Du, sag mal, was ist das hier für ein komisches File?”, wurde der Prozess eingehalten. Und der Prozess besagt offenbar: Bei Gefahr sofort zum CISO rennen.

Und so knallt ein Prio-1-Ticket direkt auf den Schreibtisch des Chief Information Security Officer. Der, wahrscheinlich gerade zwischen zwei wichtigen Meetings über die Farbgestaltung der neuen Firewall-Oberfläche, sieht nur die Schlagworte: “Passwörter”, “im Klartext”, “GitHub”, “Exposed”.

Der Fallout: Wenn Dummheit den Stecker zieht

Was macht ein CISO in so einer Situation? Richtig, er drückt den großen roten Knopf. Ohne Rückfrage, ohne ein kurzes “Könnte das vielleicht harmlos sein?”, ohne Sinn und Verstand.

Und zack: Meine Workstation ist offline. Diverse Server meiner Laborumgebung sind offline.

Einfach abgeschaltet. Weil ein uralter Commit einen längst pensionierten Hostnamen und temporäre Passwörter enthielt. Ein Anruf hätte genügt. Fünf Minuten Erklärung, und die Sache wäre vom Tisch gewesen. Stattdessen: Produktionsausfall im Labor und ein Admin, der erstmal herausfinden muss, warum sich seine SSH-Session gerade in Luft aufgelöst hat.

Man soll ja keine Bosheit unterstellen, wo Dummheit als Erklärung ausreicht. Aber manchmal, wirklich nur manchmal, fällt es schwer.

Den Zirkus von vornherein vermeiden

Genug gelästert. Wie verhindern wir, dass so ein Blödsinn überhaupt erst passiert? Die Antwort ist Automatisierung, denn auf den gesunden Menschenverstand ist offensichtlich kein Verlass.

Lösung 1: Pre-Commit Hooks (Die lokale Türsteher-Logik) Die erste Verteidigungslinie ist dein eigener Rechner. Ein Pre-Commit Hook ist ein kleines Skript, das ausgeführt wird, bevor ein Commit überhaupt erstellt wird. Findet das Skript etwas Verdächtiges, bricht es den Commit-Vorgang ab.

Das Framework pre-commit macht die Verwaltung solcher Hooks zum Kinderspiel.

Installation (falls noch nicht geschehen):

pip install pre-commit

Konfiguration im Repo: Erstelle eine Datei namens .pre-commit-config.yaml im Wurzelverzeichnis deines Projekts.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

# .pre-commit-config.yaml
repos:
-   repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
    -   id: check-yaml
    -   id: end-of-file-fixer
    -   id: trailing-whitespace
-   repo: https://github.com/gitleaks/gitleaks
    rev: v8.18.2
    hooks:
    -   id: gitleaks

Dieser Beispiel-Hook nutzt Gitleaks, ein mächtiges Tool, das Commits auf Passwörter, API-Keys und andere Geheimnisse prüft.

Hooks installieren: pre-commit install

Wenn du jetzt versuchst, eine Datei mit password = “topsecret123” zu committen, wird Gitleaks Alarm schlagen und den Commit verweigern. Problem gelöst, bevor es entsteht.

Lösung 2: GitHub Actions (Das serverseitige Sicherheitsnetz)

Was, wenn jemand (natürlich nicht du!) die Hooks umgeht (mit git commit --no-verify, aber das hast du nicht von mir)? Dann brauchen wir eine zweite Instanz, die aufpasst: eine CI-Pipeline. GitHub Actions eignen sich hierfür perfekt.

Erstelle eine Workflow-Datei unter .github/workflows/security-scan.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

# .github/workflows/security-scan.yml
name: Security Scan

on:
  push:
    branches: [ main, master, develop ]
  pull_request:
    branches: [ main, master ]

jobs:
  gitleaks:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0 # Wichtig, um die gesamte History zu klonen
      - uses: gitleaks/gitleaks-action@v2
        env:
          # Bei Bedarf eine Konfigurationsdatei für Gitleaks angeben
          # GITLEAKS_CONFIG: .gitleaks.toml
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Dieser Workflow führt bei jedem Push oder Pull Request auf die Haupt-Branches einen Gitleaks-Scan durch. Findet die Action ein Geheimnis, schlägt der Build fehl, und der Merge wird im besten Fall blockiert. Der CISO bekommt davon gar nichts mit – und genau so soll es sein.

Die Moral von der Geschicht'

Am Ende war der Spuk schnell vorbei. Ein kurzer, leicht entnervter Anruf beim CISO, eine Erklärung, und die Systeme wurden wieder hochgefahren. Zurück blieb die Erkenntnis, dass Prozesse manchmal wichtiger sind als Pragmatismus – und dass man sich auf seine automatisierten Wächter verlassen sollte.

Also, schützt eure Repos, automatisiert eure Scans und benennt eure Server nach ägyptischen Göttern. Das hält zwar die Security-Praktikanten nicht auf, aber es fühlt sich einfach verdammt richtig an.

Denn am Ende des Tages gilt doch die alte Admin-Weisheit: Wir halten alle Angreifer fern – für die Produktionsausfälle sorgen wir schließlich selber!