Nachdem wir die GitLab DevSecOps Serie abgeschlossen haben, hat Patrick den Job gewechselt — und sein neues Team arbeitet mit GitHub. Das Problem ist dasselbe: keine Security-Checks während der Entwicklung. Die Plattform ist eine andere. In Teil 1 unserer GitHub DevSecOps Serie zeigen wir, was GitHub ist, welches CI/CD-Vokabular man teilen muss, bevor irgendein Pipeline-Gespräch funktioniert, und wie die DevSecOps-Pipeline aussieht, die wir in den nächsten Sessions aufbauen werden.
Was GitHub ist#
GitHub ist eine verteilte Entwicklungsplattform, auf der du Source Code hostest und deine Entwicklungspipelines baust. GitHub wurde 2018 von Microsoft übernommen und ist eine der grössten Entwicklerplattformen weltweit, mit rund 83 Millionen Entwicklern und 28 Millionen Repositories. Am Ende dieser Serie vergleichen wir GitLab und GitHub direkt. Vorerst konzentrieren wir uns auf GitHub.
Was eine DevSecOps-Pipeline leisten muss#
Produkte entwickeln sich kontinuierlich weiter. Der DevSecOps-Zyklus — plan, code, build, test, deploy, release, operate, monitor — ist das, was deine Plattform durchgängig unterstützen muss. Bevor wir über konkrete Tools sprechen, müssen wir drei Begriffe sauber trennen, die ständig vermischt werden: Continuous Integration, Continuous Delivery und Continuous Deployment.
Continuous Integration#
Der Entwickler committet Code. Der CI-Server holt ihn, baut ihn, führt statische Code-Analyse durch, statische Security-Analyse, Unit Tests und einen Teil der Integrationstests. Output ist ein deploybares Artefakt. Security-Tests sind von Anfang an Teil der CI — kein separates Gate am Ende.
Feedback-Zeit zählt mehr, als viele denken. Dauert der Loop Stunden, hat der Entwickler längst etwas Neues angefangen, wenn das Ergebnis kommt. Der Aufwand für den Context Switch frisst den Vorteil des frühen Findens komplett auf. Wir reden über Minuten, nicht über Stunden.
Continuous Delivery#
Das deploybare Artefakt wird automatisch in eine Staging-Umgebung deployed, die der Produktion entspricht. Dort laufen weitere automatisierte Tests, bei Bedarf auch manuelle. Das Deployment ist automatisiert; der Release ist eine separate Entscheidung.
Continuous Deployment#
Continuous Deployment geht einen Schritt weiter. Nach Staging wird das Artefakt automatisch in Produktion deployed. Dort läuft ein zweites Set automatisierter Tests. Falls die scheitern, wird sofort auf die letzte stabile Version zurückgerollt. Es gibt kein manuelles Gate.
In vielen Organisationen ist dieser letzte Schritt absichtlich nicht automatisiert — Security- oder Compliance-Vorgaben verlangen einen formellen manuellen Trigger. Das ist in Ordnung, aber es heisst, dass du Continuous Delivery machst, nicht Continuous Deployment. Sei ehrlich, was du tatsächlich tust.
Die Continuous Delivery Pipeline#
CI/CD allein reicht nicht. Eine vollständige Pipeline enthält am Anfang Continuous Exploration (Ideenfindung und Backlog-Management) und am Ende Release on Demand (Aktivieren von Features in Produktion über Toggles). Das Ganze nennt sich Continuous Delivery Pipeline. In jeder reifen Pipeline siehst du viele Tools, die zusammengeschaltet sind; die Arbeit liegt nicht in der Tool-Wahl, sondern in der Integration, sodass die Tools bei jedem Commit zuverlässig laufen.
Was GitHub verspricht und was du tatsächlich bekommst#
GitHub verspricht eine einzige Plattform, die alles abdeckt. Die Realität ist nuancierter: GitHub gibt dir sehr gute Integrationspunkte, aber du wirst einige unzureichende Teile ersetzen und für mehrere Schritte Drittanbieter-Tools einbinden. Es gibt nicht für jede Security-Aufgabe ein GitHub-eigenes Default-Tool — für SCA, SAST, Container Scanning und andere wählst du aus dem Marketplace.
Warum wir das tun#
Ein Security-Problem früh zu beheben ist dramatisch günstiger als die Behebung nach dem Release. Findet ein Penetration Test ein Problem nach dem Go-live, musst du das Produkt möglicherweise vom Netz nehmen, Umsatz verlieren und die gesamte Kette — code, build, test, deploy — erneut durchlaufen. Vergleiche das mit einem Fund, während der Entwickler noch am selben Codestück arbeitet, der Kontext frisch ist und der Fix Minuten dauert. Die Wirtschaftlichkeit spricht für sich.
Die Pipeline, die wir mit GitHub bauen werden#
Die nächsten Sessions decken in dieser Reihenfolge ab: Setup des Projekts mit Build und Unit Tests, Software Composition Analysis, License Compliance, Static Application Security Testing, Container Scanning, Secret Detection, Merge Requests als Security-Gate, Dynamic Application Security Testing und Scheduled Pipelines. Die letzte Session liefert Empfehlungen und Lessons Learned aus der gesamten Reise.
Key Takeaways#
GitHub ist ein Startpunkt, keine vollständige DevSecOps-Plattform. Du bekommst starke Integrationspunkte und einen Marketplace; du bekommst kein Default-Tool für jede Security-Aufgabe. Plane Drittanbieter-Bausteine ein.
Verwende CI, CD und Continuous Deployment präzise. Continuous Integration endet mit einem getesteten Artefakt. Continuous Delivery deployed nach Staging. Continuous Deployment deployed nach Produktion. Die Trade-offs sind unterschiedlich — nenn sie beim richtigen Namen.
Feedback in Minuten ist die Design-Vorgabe. Dauert die Pipeline Stunden, ist der Entwickler längst woanders, und der Vorteil des frühen Findens ist verloren. Optimiere kompromisslos auf schnelles Feedback.
Ein manuelles Produktions-Gate ist okay — nenn es einfach Continuous Delivery. Viele Unternehmen können den Produktions-Schritt aus Compliance-Gründen nicht voll automatisieren. Das ist eine legitime Wahl, kein DevOps-Versagen.
Security früh zu finden ist dramatisch günstiger. Eine Schwachstelle, die in Produktion entdeckt wird, kann bedeuten, dass du das System abschalten musst. Dieselbe Schwachstelle zur Commit-Zeit kostet Minuten Entwickler-Aufmerksamkeit.
Die Arbeit ist Integration, nicht Tool-Wahl. Der Marketplace bietet reichlich Tools. Sie so in eine Pipeline zu verdrahten, dass sie bei jedem Commit laufen und zuverlässiges Feedback liefern, ist die eigentliche Engineering-Leistung.