Nach elf Sessions, in denen wir eine komplette DevSecOps-Pipeline mit GitHub aufgebaut haben — Software Composition Analysis, License Compliance, SAST, Container Scanning, Secret Detection, DAST, Pull Requests, Scheduled Pipelines und Vulnerability Management — schliessen Patrick Steger und ich die Serie mit unseren Empfehlungen ab. Was auf GitHub funktioniert, wo die Lücken sind und was wir jedem mitgeben würden, der die gleiche Pipeline bauen will.
Workflows hierarchisch strukturieren#
Das erste, was wir empfehlen würden: strukturiere deine Workflows top-down. Bau einen Main-Pipeline-Workflow, der kleinere, einzelzweckorientierte Workflows orchestriert — einen für Build, einen für SCA, einen für SAST und so weiter. Jeder Sub-Workflow macht eine Sache gut, und die Main Pipeline setzt sie zusammen. Das ist über die Zeit deutlich einfacher zu warten als ein riesiges YAML. Wenn etwas bricht oder sich ändert, fixt du es in einem kleinen Workflow, und jede Pipeline, die ihn nutzt, bekommt den Fix mit.
Branches und Schedules explizit definieren#
Sei explizit, welcher Workflow auf welchem Branch läuft. Du kannst — und solltest oft — unterschiedliche Pipelines für unterschiedliche Branches haben. Und du musst deine Pipelines schedulen. Der Grund: Deine Pipeline läuft normalerweise nur bei Änderungen, aber die Anwendung in Produktion ändert sich nicht jeden Tag. Neue Schwachstellen werden täglich bekannt. Ohne Scheduled Pipeline wirst du Produktionscode nie erneut scannen und nie die Schwachstellen sehen, die nach dem letzten Commit aufgetaucht sind. Den Default Branch in GitHub zu setzen ist einfach — Settings, General, Default Branch — aber die Scheduled Pipeline ist das, was Produktion absichert.
Pull Requests als Security-Gate#
Pull Requests funktionieren gut, um neu eingeführte Security-Probleme sichtbar zu machen. Verdrahte deine Security-Workflows in jeden PR und definiere einen Review- und Approval-Prozess für den Fall, dass eine kritische Schwachstelle auftaucht. Kombiniere das mit Branch Protection Rules, um es tatsächlich zu erzwingen. Unter Settings → Branches kannst du eine Regel definieren (wir nutzen *, damit sie für alle Branches gilt), die Reviews, Status Checks und alles andere verlangt, was du brauchst, bevor ein Merge möglich ist. Ohne Branch Protection ist dein ganzes PR-Gating nur Theater.
Marketplace Actions Security-reviewen#
Dieser Punkt zählt besonders in vertraulichen und Enterprise-Kontexten. Alles, was du aus dem GitHub Marketplace ziehst, ist Community-Code, der in deiner Pipeline läuft — mit Zugriff auf deine Secrets und deinen Source. Review, was du nutzt. Im besten Fall forkst du es in dein eigenes Repository und managest es von dort, sodass du Updates kontrollierst und Änderungen auditieren kannst. Behandle Marketplace Actions wie jede andere Drittanbieter-Abhängigkeit — denn genau das sind sie.
Secret Management: Azure Key Vault nutzen#
Für Secrets ist der GitHub Secret Store die Baseline. Er funktioniert. Wenn du eine bessere Lösung willst, nutze Azure Key Vault. Die Integration ist exzellent, und du bekommst erweiterte Management-Funktionen — Rotation, Access Policies, Audit Logs — die der eingebaute Store nicht bietet. Andere Key Vaults funktionieren auch, aber die Azure-Integration sticht heraus.
Du musst deine Security-Tools selbst auswählen#
Im Gegensatz zu GitLab liefert GitHub kein Default-Set an Security-Scannern mit. Das heisst, du musst evaluieren und auswählen, was zu deinem Stack passt. Der Vorteil ist Freiheit; der Nachteil ist die Arbeit. Unsere vorherigen Episoden sind konkrete Kandidaten für SCA, SAST, Container Scanning, Secret Detection und DAST durchgegangen — fang dort an, wenn du eine Shortlist willst.
Wenn es speziell um DAST geht, customize die Scanner-Konfiguration. Ein nicht customizter DAST-Scan kratzt kaum an der Oberfläche. Ohne Authentifizierung, Crawl-Regeln und Input-Definitionen kann der Scanner die Anwendung nicht sinnvoll durchexerzieren, und der Nutzen ist sehr begrenzt.
Die Lücke beim Vulnerability Management#
Selbst ein kleines Java-Projekt produziert eine Menge Findings. Diese Findings zu managen ist essenziell. GitHubs Vulnerability Management ist okay — du kannst damit arbeiten — aber es gibt eine echte Lücke: du kannst keine eigenen Findings anlegen. Wenn dein Pen-Tester eine Schwachstelle findet, die die automatischen Scanner nicht gefunden haben, kannst du sie nicht im GitHub Vulnerability Management erfassen. Das limitiert die Plattform erheblich. Unsere Empfehlung, leider: Plane ein externes Vulnerability Management Tool ein.
Hol einen Security-Experten ins Team#
Wie bei GitLab ist unsere letzte Empfehlung die gleiche: Hol einen Security-Experten ins Team. Du wirst viele Findings haben, du musst jedes Tool korrekt konfigurieren, und du musst aus dem, was rauskommt, etwas Sinnvolles machen. Das braucht Expertise. Ohne sie ertränkt die Pipeline das Team entweder im Rauschen oder lässt echte Probleme stillschweigend durch.
Key Takeaways#
Kleine Workflows zu grossen komponieren. Eine Main Pipeline, die fokussierte Sub-Workflows (Build, SCA, SAST etc.) orchestriert, ist deutlich einfacher zu warten als ein monolithisches YAML.
Pipelines schedulen, um Produktionscode abzusichern. Code in Produktion wird nicht mehr gescannt, sobald die Commits aufhören. Scheduled Runs decken neu bekannt gewordene Schwachstellen ab.
Pull Requests plus Branch Protection sind dein Gate. PRs machen Probleme sichtbar; Branch Protection Rules erzwingen, dass das Gate auch tatsächlich geschlossen ist.
Marketplace Actions sind Drittanbieter-Code. Reviewe sie, im besten Fall in eigenes Repo forken und Updates selbst managen — gerade in Enterprise-Kontexten.
Für ernsthaftes Secret Management Azure Key Vault nutzen. GitHubs eingebauter Secret Store funktioniert; Azure Key Vault integriert sich sauber und bietet die Management-Fähigkeiten, die du irgendwann brauchst.
GitHubs Vulnerability Management hat eine echte Lücke. Eigene Findings lassen sich nicht hinzufügen. Plane ein externes Vulnerability Management Tool ein und hol einen Security-Experten ins Team.