Warum wird Security immer noch am Ende des Entwicklungsprozesses angeflanscht — und wie können wir sie nach vorn verschieben, ohne die Teams auszubremsen? In Teil 1 unserer GitLab DevSecOps Serie legen Patrick Steger und ich die Grundlage: Was GitLab ist, was Shift Left wirklich bedeutet und welche CI/CD-Konzepte man verstanden haben muss, bevor man eine DevSecOps-Pipeline bauen kann, die in der Praxis funktioniert.
Das Problem: Security wird zu spät gefunden#
Patrick beginnt die Session mit einer bekannten Geschichte. Er hat ein Security Review für eine Anwendung gemacht, Probleme gefunden — und wurde dafür verantwortlich gemacht, dass das Go-live nicht stattfinden konnte. Es geht hier nicht darum, dass das Review falsch war. Es geht darum, dass niemand vorher Security geprüft hat. Das Team wusste schlicht nicht, wie. Genau diese Lücke schliesst eine DevSecOps-Pipeline. Du verschiebst Security-Tests nach links, sodass Probleme dann auftauchen, wenn sie noch günstig zu beheben sind, und du automatisierst die Checks, sodass kein Entwickler daran denken muss.
Warum Produkte eine Pipeline brauchen#
Wir bauen Produkte, keine Projekte, und Produkte entwickeln sich kontinuierlich weiter. Das DevOps-Infinity-Symbol bringt das auf den Punkt: plan, code, build, test, deploy, release, operate, monitor — und wieder von vorn. Um diesen Loop zu unterstützen, brauchst du eine CI/CD-Pipeline. Und um über CI/CD zu reden, ohne aneinander vorbeizureden, müssen wir drei Begriffe sauber trennen: Continuous Integration, Continuous Delivery und Continuous Deployment.
Continuous Integration#
Continuous Integration startet in dem Moment, in dem ein Entwickler Code committet. Der CI-Server holt sich den Code, baut ihn, führt statische Code-Analyse durch, statische Security-Analyse, Unit Tests und einen Teil der Integrationstests. Output ist ein deploybares Artefakt. Wichtig: Security-Checks sind bereits Teil dieses Schritts. Du wartest nicht auf ein separates Security-Gate am Ende. Du machst sie bei jedem Commit.
Was hier ebenfalls entscheidend ist: die Feedback-Zeit. Der Entwickler darf nicht Stunden oder Tage warten. Wir sprechen von Minuten. Ist der Loop langsam, hat der Entwickler längst etwas anderes angefangen, wenn das Ergebnis kommt — und der Context-Switch frisst den Vorteil sofort wieder auf.
Continuous Delivery#
Das deploybare Artefakt aus der CI wird automatisch in eine Staging-Umgebung deployed. Dort laufen weitere automatisierte Tests, bei Bedarf auch Penetration Tests. Das Deployment ist automatisiert; der Release ist es nicht. Continuous Delivery gibt dir einen Knopf — drück ihn, wenn das Business bereit ist.
Continuous Deployment#
Continuous Deployment geht einen Schritt weiter. Das Artefakt, das CI bestanden hat und auf Staging deployed wurde, wird auch automatisch in Produktion deployed — mit einem weiteren Set automatisierter Tests, das Probleme abfängt, die durchgerutscht sind. Es gibt kein manuelles Gate. Wenn du einen manuellen Security-Checkpoint möchtest, ist das in Ordnung — aber dann machst du Continuous Delivery, nicht Continuous Deployment. Sei ehrlich, was du tatsächlich umsetzt, denn die Trade-offs sind unterschiedlich.
Release on Demand#
DevOps trennt Deployment von Release. Deployment ist das Ausrollen des kompilierten Codes nach Produktion, hinter einem Feature Toggle. Release ist das Aktivieren dieses Toggles. Mit Release on Demand entkoppelst du “der Code ist in Produktion” von “der Kunde sieht das neue Feature”. Das ist es, was Continuous Deployment auch bei wirkungsstarken Änderungen sicher macht.
Die Pipeline, die wir mit GitLab bauen werden#
Es gibt viele Plattformen, die versprechen, die gesamte Continuous Delivery Pipeline abzudecken — GitLab, GitHub, Azure DevOps und andere. In dieser Serie konzentrieren wir uns auf GitLab. GitLab verspricht, alles abzudecken, aber in der Realität wird deine Pipeline fokussierter aussehen. In dieser Serie lassen wir Continuous Exploration und Release on Demand weg und machen Continuous Delivery (kein vollständiges Continuous Deployment). Das Artefakt wird automatisch nach Staging deployed.
Die Pipeline deckt auf der CI-Seite Static Application Security Testing, Secret Detection, Software Composition Analysis und Container Scanning ab. Auf der CD-Seite kommt Dynamic Application Security Testing dazu. Jedes Thema bekommt eine eigene Session.
Key Takeaways#
Security nach links verschieben oder später teuer dafür zahlen. Je weiter rechts ein Security-Problem gefunden wird, desto teurer wird die Behebung. Bau die Checks von Anfang an in die CI ein.
CI, CD und Continuous Deployment sauber trennen. Continuous Integration endet mit einem getesteten Artefakt. Continuous Delivery deployed nach Staging. Continuous Deployment deployed nach Produktion. Vermischt man die Begriffe, vermischt man auch die Erwartungen.
Feedback in Minuten, nicht in Stunden. Entwickler wechseln schnell den Kontext. Dauert die Pipeline Stunden, kommt das Feedback bei jemandem an, der längst woanders ist — der Vorteil des frühen Findens ist weg.
Deployment vom Release trennen. Feature Toggles erlauben es, Code in Produktion zu schicken, ohne ihn für Nutzer sichtbar zu machen. Das macht aggressives Deployment sicher.
Hersteller-Versprechen entsprechen selten der Realität. GitLab behauptet, die gesamte Pipeline abzudecken; deine echte Pipeline wird fokussierter sein und braucht möglicherweise Drittanbieter-Tools. Plane das ein, statt dagegen zu kämpfen.
Eine DevSecOps-Pipeline ist eine Reihe kleiner, automatisierter Entscheidungen. SAST, Secret Detection, SCA, Container Scanning, DAST — keines davon ist exotisch. Die Disziplin liegt darin, sie so in jeden Commit zu verdrahten, dass sie laufen, ohne dass jemand daran denken muss.