Seit einiger Zeit rennt mal wieder eine Sau durchs Dorf… und alle rennen hinterher: DevSecOps.
Was steckt hinter DevSecOps?
Kurz gesagt: DevSecOps ist der Versuch, das Thema Security zu positionieren. Leute, die DevSecOps sagen, sind allerdings dem Missverständnis aufgelaufen, dass DevOps nur etwas mit Entwicklung und Betrieb zu tun hat. Sie haben das grundlegende Konzept von DevOps nicht verstanden.
Woher kommt der Name DevOps?
In 2009, the first conference named DevOps Days was held in Ghent, Belgium. The conference was founded by Belgian consultant, project manager and agile practitioner Patrick Debois
https://en.wikipedia.org/wiki/DevOps (Abruf am 21.04.2023)
Der Name DevOps hat sich aus dem Konferenz-Namen abgeleitet. Von Anfang an ging es aber nicht nur um Entwicklung und Betrieb. Vielmehr steckt die Idee dahinter, dass alle Parteien, die an einem Produkt mitarbeiten, Teil der Entwicklung sind. Alle Unternehmen sollen sich als IT-Unternehmen verstehen, statt Abteilungssilos aufzubauen.
Deshalb wurde bereits im Buch „The Phoenix Project“ aus dem Jahr 2014 klar herausgestellt, dass Information Security und Compliance sowie das Business natürlich ein wichtiger Bestandteil von DevOps ist. Auch im 2016 erschienenen „The DevOps Handbook“ gibt es das Kapitel 22: „Information Security as Everyone’s Job, Every Day“.
Muss man dazu mehr sagen?
Allerdings ist das leider nur die halbe Wahrheit. Deshalb müssen wir uns folgende Frage stellen: Wenn Security bereits ein integraler Bestandteil von DevOps ist: Warum wird DevSecOps dennoch durchs Dorf getrieben?
Der Zweck von DevSecOps
Es gibt genau einen Zweck, den der Begriff DevSecOps erfüllt. Dafür muss ich allerdings kurz ausholen.
Obwohl es sich bei DevOps eigentlich nur um die Adaption der bewährten Prinzipien und Praktiken aus der Produktion handelt, war das in den 2010er Jahren für viele IT-Entscheider zu revolutionär. Um das Konzept DevOps dennoch in den Unternehmen zu etablieren, haben IT-Berater, Entwickler und „DevOps-Tools“-Herstellern das ursprüngliche Konzept verwässert und an die bestehende Unternehmenskultur angepasst. Herausgekommen ist ein Wildwuchs an Interpretationen, was DevOps sein könnte.
Um nun die IT-Entscheider zum nächsten konkreten Schritt zu bewegen, glauben viele, dass das ursprüngliche Konzept nicht mehr nutzbar ist, da der Name verbrannt sei. Deshalb werden wild neue Namens-Kreationen erstellt.
Das Problem: Ohne Business und Security ist DevOps eine wertlose Worthülse. Statt das eigentliche Problem mit dem Konzept DevOps zu lösen, hangelt man sich nun von einem Marketing-Begriff zum nächsten.
Radikal agiles DevOps
Wie in der traditionellen Produktion ist auch in der IT das Fließband, in der IT als CI/CD-Pipelines bezeichnet, zum Rückgrat der Arbeit geworden. Damit die Entwickler produktiv arbeiten können und den Betrieb und die Security sicherstellen können, müssen diese CI/CD-Pipelines einige Kriterien erfüllen:
- Sie müssen schnelles Feedback liefern
- Sie müssen leicht wartbar sein
- Sie müssen zuverlässig laufen
- Am Ende der Pipeline muss das Artefakt bereit für die Produktion sein
- Sie müssen leicht anpassbar sein, wenn sich die Umweltbedingungen ändern
- Sie sind das einzige Werkzeug, mit dem Artefakte und Konfigurationen in Produktion kommen
- Sie müssen durch geeignete Scan-Software die Sicherheit des Artefakts garantieren können
- Sie müssen mit den ITSM-Prozessen, dem Entwicklungsprozess, dem Schwachstellenmanagement, dem Risikomanagement und den Betriebsprozessen eng verzahnt sein.
Wenn du eine solche CI/CD-Pipeline in deinem Unternehmen betreiben möchtest, habe ich ein Angebot für dich:
Dein kostenfreier Pipeline-Checkup
Wir nehmen uns genau eine Stunde Zeit. Du präsentierst mir, wie deine Pipeline aufgebaut ist, welche Schritte nacheinander durchlaufen werden.
Ich werde dir ein paar Fragen stellen, um mir ein klares Bild zu machen.
Im Anschluss bekommst du eine Liste an nächsten Schritten, die du angehen solltest, um deine Pipeline nachhaltig, robust und zukunftssicher aufzubauen.
Was tun wir nicht?
Eine Stunde ist zu wenig Zeit, um durch den Code zu gehen. Das wäre auch nicht zielführend, weil wir uns sonst verzetteln. Wir schauen uns also nicht an, wie konkret die Arbeit an den einzelnen Stationen stattfindet.
Stattdessen gehen wir auf eine gewisse Flughöhe und betrachten deine Pipeline von dort aus. Damit ist sichergestellt, dass wir uns nicht verzetteln und dass du geeignete und sinnvolle Verbesserungsvorschläge bekommst.
Wenn du Interesse hast, schreib mir gerne eine E-Mail an johannes@radikal-agile.de. Ich freue mich, von dir zu hören.