Kapitel 1. Die Notwendigkeit von DevSecOps

Diese Arbeit wurde mithilfe von KI übersetzt. Wir freuen uns über dein Feedback und deine Kommentare: translation-feedback@oreilly.com

Software wird entwickelt, um Probleme zu lösen. Doch allzu oft bringt die Entwicklung von Software eine Reihe von Problemen mit sich und schafft manchmal sogar neue Probleme. Ein Unternehmen muss sich entscheiden, ob es eine maßgeschneiderte Software entwickeln oder eine vorgefertigte Software kaufen möchte. Die vorgefertigte Software ist am wirtschaftlichsten, wenn es sich um eine Standardsoftware wie eine Office-Suite handelt. Für die Entwicklung fortschrittlicher Lösungen in funktionalen Geschäftsbereichen ist jedoch oft eine individuelle Entwicklung erforderlich. Maßgeschneiderte Lösungen werden mit dem Ziel entwickelt, Wettbewerbsvorteile zu erzielen oder die Effizienz zu steigern.

Der Prozess der Softwareentwicklung hat sich in den späten 1990er Jahren und Anfang der 2000er Jahre stark verändert. Der Schwerpunkt lag nicht mehr auf dem Sammeln von Anforderungen, sondern auf Iteration und Geschwindigkeit. Die iterative Art und Weise, in der Software entwickelt wird, zeichnet sich durch wiederholbare Prozesse und Automatisierung aus, die eine schnelle Bereitstellung neuer Funktionen ermöglichen und Feedbackschleifen während des gesamten Entwicklungszyklus einschließen. Zusammen mit kulturellen Veränderungen in der Organisation, die eine transparente Open-Source-Mentalität fördern, führt dies zu funktionsübergreifenden Teams, die sich mehr um die Qualität als um das Territorium kümmern, und zur Zusammenlegung mehrerer Teams: Entwicklung, Betrieb und Sicherheit - DevSecOps.

Dieses Kapitel befasst sich mit den Treibern hinter der DevSecOps-Bewegung. Der Prozess der Softwareentwicklung steht zunächst im Mittelpunkt. Die Entwicklung der Softwareentwicklungsmethoden liefert den nötigen Hintergrund, um DevSecOps vollständig zu verstehen und damit erfolgreich zu sein. Im weiteren Verlauf des Kapitels wird betont, wie wichtig kulturelle Veränderungen für Unternehmen sind, die sich auf DevSecOps zubewegen.

Software entwickeln

Um ihre Ziele zu erreichen, setzen Unternehmen einen Teil ihrer Ressourcen für die Entwicklung von Software ein. Es ist wichtig zu bedenken, dass diese Ressourcen auch an anderer Stelle investiert werden könnten, wo sie einen höheren Ertrag bringen. Wenn du z. B. 100.000 Dollar in Marketing investierst, wirst du vielleicht mehr Kunden gewinnen, als wenn du diese Mittel in die Optimierung des Anmeldeprozesses auf deiner Website investierst.

Auch wenn Geld keine Rolle spielt, ist es die Geschwindigkeit. Die Fähigkeit, Software schnell zu entwickeln und einzusetzen, ist ein limitierender Faktor bei allen Bemühungen, Wettbewerbsvorteile zu erzielen oder die Effizienz zu steigern. Ab einem bestimmten Punkt wird ein Projekt nicht schneller, wenn mehr Entwickler/innen daran arbeiten. Ganz im Gegenteil. Je mehr Entwickler/innen hinzukommen, desto unmöglicher wird eine kohärente Kommunikation.

Software beginnt mit einer Idee. Um diese Idee in eine funktionierende Software zu verwandeln, sind Voraussicht und Planung erforderlich. Ein Softwareprojekt kann mit verschiedenen Prozessen durchgeführt werden, die zum Teil von der Art der zu entwickelnden Software abhängen. Die Softwareentwicklung umfasst die Festlegung der Anforderungen, den Entwurf der Lösung, die Entwicklung und Codierung und schließlich das Testen der Software kurz vor der Veröffentlichung. Dieser Prozess ist in Abbildung 1-1 dargestellt.

Abbildung 1-1. Ein Prozess für die Softwareentwicklung

Die vier Phasen, die manchmal auch als Software Development Lifecycle (SDLC) bezeichnet werden, können als Wasserfall konzipiert werden, wobei jede Phase ein oder mehrere Artefakte produziert, die dann an die nächste Phase weitergegeben werden (siehe Abbildung 1-2).

Abbildung 1-2. Abschluss jeder Phase eines Projekts in der Wasserfallentwicklung

Bei einer Methodik wie der Wasserfallmethode wird jede Phase abgeschlossen, bevor man zur nächsten Phase übergeht. Dies wird in Abbildung 1-1 veranschaulicht, in der die Anforderungen gesammelt und dokumentiert werden, bevor man zur Entwurfsphase übergeht, die in Abbildung 1-1 mit "Entwurfslösung" gekennzeichnet ist. Wenn während der Entwurfsphase eine neue Anforderung entdeckt wird oder zusätzliche Fragen zu neuen Anforderungen führen, werden diese Elemente häufig in einem Folgeprojekt hinzugefügt.

Am Ende der Phase der Anforderungserhebung wird der Umfang des Projekts formell festgelegt, der alle Funktionen der Software umfasst. Diese Funktionen umfassen die Hauptfunktionen der Software sowie zusätzliche Funktionen, die technisch nicht erforderlich sind, aber erwartet werden, damit die Software funktioniert. Zu diesen nicht-funktionalen Anforderungen gehören Dinge wie Reaktionsfähigkeit oder Geschwindigkeit, Sicherheit und andere Verhaltensweisen der Anwendung. Wenn die nichtfunktionalen Anforderungen nicht erfasst und hinzugefügt werden, werden die Benutzer/innen von dem Softwareprodukt frustriert und nicht überzeugt sein.

Stell dir eine Geschäftsanforderung vor: Ein Kunde soll ein Produkt finden und eine Bestellung aufgeben können. Bevor es Computer gab, wurde diese Geschäftsanforderung auf verschiedene Arten erfüllt, z. B. indem der Kunde in ein Geschäft ging, das Produkt suchte und dann kaufte oder indem er einen Katalog benutzte, um das Produkt zu finden, das Unternehmen anrief und die Bestellung per Telefon aufgab. Mit Computern und dem Internet wird diese Geschäftsanforderung jetzt häufig über das Internet erfüllt.

Die Erfüllung der geschäftlichen Anforderung, dass ein Kunde über eine Website ein Produkt finden und eine Bestellung aufgeben kann, lässt viel Raum für eine Lösung. Das Hochladen einer PDF-Datei des Katalogs auf die Website und die Bereitstellung eines Formulars, mit dem der Kunde seine Bestellung per E-Mail aufgeben kann, erfüllt die minimalen funktionalen Anforderungen an die Website. Aber auch wenn die Anforderungen erfüllt sind, würden die meisten Nutzerinnen und Nutzer etwas anderes erwarten und wahrscheinlich nicht mit einem so schwerfälligen Verfahren bestellen, das viele der Funktionen vermissen lässt, die Kunden bei der Online-Bestellung von Produkten als selbstverständlich ansehen.

Stattdessen müssen auch die nichtfunktionalen Anforderungen erfasst werden. Ein paar explorative Fragen an den Stakeholder oder den Projektsponsor würden eine Fülle von Details über die Absicht für die Lösung zutage fördern. Zum Beispiel:

  • Wie werden die Produkte auf der Website dargestellt (Fotos, Beschreibungen, technische Daten usw.)?

  • Wer macht die Produktfotos und produziert sie für das Internet, und wer schreibt die Produktionsbeschreibung?

  • Wie wird der Bestand aktualisiert, damit die Kunden keine Produkte bestellen können, die nicht mehr auf Lager sind?

  • Wie werden die Bestellungen aufgegeben?

  • Wie werden die Mitarbeiter benachrichtigt, wenn eine neue Bestellung aufgegeben wird?

  • Wer wird den Online-Katalog mit neuen Produkten pflegen?

  • Welche Zahlungsmittel werden akzeptiert?

  • Müssen Kunden Konten anlegen, den Bestellverlauf verfolgen, den Versand verfolgen?

Diese Fragen stellen nur einen kleinen Teil der Fragen dar, die bei einem ersten Sondierungs- oder Machbarkeitsgespräch beantwortet werden müssten. Einige dieser Fragen sind bereits in der Machbarkeits- oder Anforderungserhebungsphase in funktionale Anforderungen umgewandelt worden oder werden es bald . Aber ohne jemanden in der Runde, der ein solches Projekt bereits durchgeführt hat, würden sicherlich einige Anforderungen fehlen.

Der Projektumfang definiert also die Elemente, die in das Projekt einbezogen werden, und grenzt andere Elemente ab, die nicht in das Projekt einbezogen werden sollen. Alles, was nicht ausdrücklich enthalten ist, gilt als ausgeschlossen und damit als nicht im Projektumfang enthalten. Wenn eine grundlegende Anforderung nicht erfüllt wurde, muss der Projektträger entweder den Umfang neu festlegen oder ohne diese Anforderung weitermachen und die fehlende Funktion in einem späteren Folgeprojekt hinzufügen.

Zwischen der Idee und der Umsetzung können Monate oder sogar Jahre vergehen. Die Verzögerung zwischen der Idee und der Veröffentlichung des Softwareprodukts macht das Warten auf eine verpasste Funktion für den Projektsponsor noch schmerzhafter. Innerhalb dieser Zeitspanne kann jeder Wettbewerbsvorteil, den man vielleicht erzielt hat, schnell verpuffen, wenn ein Konkurrent, der die Anforderung nicht vermisst hat, seine eigene Version veröffentlicht.

In den folgenden Abschnitten werden einige der Probleme und die dazugehörigen Lösungen für die moderne Softwareentwicklung untersucht.

Entwicklung von Agilität

Als Reaktion auf die Verzögerung zwischen der Definition von und dem Abschluss eines Projekts haben sich Unternehmen iterativen Prozessen wie Agile und Scrum zugewandt, um den Stakeholdern schnell einen Mehrwert zu bieten. Bei einem iterativen Softwareentwicklungsprozess werden alle vier zuvor beschriebenen Phasen (Anforderungen, Design, Entwicklung und Testen) durchlaufen. Anstatt zu versuchen, alle Anforderungen für alle möglichen Aspekte des Projekts zu erfassen, konzentriert sich die iterative Entwicklung auf die Funktionen, die für den Stakeholder den höchsten Wert haben. Die Funktionen mit dem höchsten Wert werden dann durch eine Runde der Anforderungserfassung erweitert, bevor sie in einem kurzen Zyklus von zwei bis vier Wochen entworfen, entwickelt, getestet und freigegeben werden. Abbildung 1-3 zeigt, wie jede Phase des SDLC in einem iterativen Prozess wie Agile gehandhabt wird.

Abbildung 1-3. Jede Phase durchlaufen und dann mit einem Agile-ähnlichen Prozess neu beginnen

Wie in Abbildung 1-3 dargestellt, wird jede Phase abgeschlossen, aber es wird nicht versucht, alle Anforderungen zu erfassen, da die iterative Entwicklung einen Lernprozess darstellt. Wenn eine Anforderung nicht erfüllt wird, kann der Stakeholder entscheiden, ob er die Funktion nicht freigibt oder die fehlende Anforderung in der nächsten Iteration nachholt. Bei einem iterativen Entwicklungsprozess ist die nächste Veröffentlichung nur noch Wochen und nicht Monate oder Jahre entfernt. Wenn du das mit einer fehlenden Anforderung in einem Wasserfallprozess vergleichst, bei dem die nächste Version Monate oder Jahre entfernt sein kann, siehst du den klaren Vorteil dieses Prozesses.

Iterative Entwicklung ermöglicht auch eine schnelle Reaktion auf veränderte Marktbedingungen. Du könntest zum Beispiel die beste Idee für die nächste Killer-App haben, mit der Entwicklung dieser App beginnen, aber dann bringt dein Konkurrent im Wesentlichen die gleiche App heraus. In einem Wasserfallmodell müsstest du das Projekt komplett verwerfen. Bei einem iterativen Prozess kann der Schwerpunkt auf Funktionen gelegt werden, die in der App des Konkurrenten fehlen könnten.

In der agilen Softwareentwicklung gibt es verschiedene Zeremonien wie Sprintplanung, tägliches Stand-up, Sprint-Review, Sprint-Retrospektive und Backlog Grooming. Ein Gesamt-Backlog oder eine Liste aller möglichen Funktionen, die zu einem bestimmten Zeitpunkt bekannt sind, wird erstellt und nach Prioritäten geordnet. Aus dieser priorisierten Liste von Funktionen wird ein Sprint Backlog erstellt. Das Sprint Backlog ist eine Zusage des Entwicklungsteams, welche Funktionen in der aktuellen Iteration umgesetzt werden sollen. Der Sprint Backlog wird auf der Grundlage der Verfügbarkeit der Teammitglieder und ihrer Einschätzung des Aufwands, auch Level of Effort (LOE) genannt, für jedes einzelne Element des Backlogs erstellt.

Am Ende des Sprints wird ein Sprint-Review durchgeführt, bei dem das Team zeigt, was es in dieser Iteration erreicht hat. Nach dem Sprint-Review prüft das Team in der Retrospektive, was es während des Sprints anders hätte machen können. Ein Team könnte während der Retrospektive drei Fragen beantworten:

  • Was sollten wir jetzt tun?

  • Was sollten wir nicht mehr tun?

  • Was sollten wir weiterhin tun?

Diese drei Fragen ermöglichen es dem Team, darüber nachzudenken, was funktioniert hat, was nicht funktioniert hat und was sie bei der nächsten Iteration ändern könnten. Wenn die Retrospektive abgeschlossen ist, kann das Team zum Backlog Grooming übergehen, bei dem das Backlog verfeinert und neu priorisiert wird. Der Stakeholder oder Product Owner ist in der Regel an der Verfeinerung des Backlogs beteiligt und legt die Prioritäten für das Team fest.

Kaputte Software entwickeln

Fehlerhafte Anforderungen führen zu fehlerhafter Software oder zu Software, die die ursprüngliche Anforderung nicht erfüllt. Fehlerhafte Software kann unabhängig davon entstehen, ob die ursprüngliche Anforderung erfolgreich vom Projektsponsor erfragt wurde. Das Ergebnis sind Unzufriedenheit, fehlerhafte Funktionen und Sicherheitsprobleme.

Bei der Prüfung der Anforderungen bleiben bei den Entwicklern oft viele Fragen offen. Diese Fragen reichen von banalen Fragen, wie z. B. wo die geschweiften Klammern für eine Bedingung in einigen Sprachen platziert werden sollen, bis hin zu kritischen Fragen, wie z. B. die Beschaffung von Zugangsdaten für eine Datenbankverbindung. In letzterem Fall muss die Entwicklung möglicherweise unterbrochen werden, während die Zugangsdaten beschafft werden. In anderen Fällen beantworten die Entwickler/innen die Frage einfach so gut sie können und machen weiter.

Software in einem Silo zu entwickeln, ohne Interaktion mit anderen als den Entwicklern, führt zu fehlerhafter Software. Bei der Silo-Entwicklung mit einer Wasserfall- oder ähnlichen Methodik untersuchen und interpretieren die Entwickler die Anforderungen nach bestem Wissen und Gewissen. Betrachte die folgende Frage: "In welchen Webbrowsern soll die Website funktionieren?" und die übliche Antwort: "In welchen Browsern? Ich habe mit Chrome entwickelt; ich habe nicht daran gedacht, dass die Seite auch in anderen Browsern funktioniert." Abbildung 1-4 zeigt die Entwicklung in einem Silo, in dem Entwickler, Betriebsmitarbeiter und Sicherheitstechniker nicht gut miteinander kommunizieren.

Abbildung 1-4. Silo-Entwicklung in einer Organisation führt zu mangelnder Sichtbarkeit

Die Fristen diktieren die Anzahl der Funktionen und die Qualität dieser Funktionen. Der Abgabetermin kann so knapp bemessen sein, dass keine Zeit bleibt, die Probleme zu erkennen, die beim Testen mit einem anderen Browser oder einem anderen Ansichtsfenster (z. B. einem Handy) auftreten könnten, geschweige denn, diese Probleme zu beheben. Wenn Cross-Browser-Tests nicht in das Projekt aufgenommen wurden und die Browser, in denen die Website funktionieren muss, nicht in den Anforderungen angegeben wurden, ist es reine Spekulation, in welchen Browsern die Website funktionieren wird.

Die Fristen, also der Zeitplan des Projekts, ist einer der drei Hebel, die in einem Softwareentwicklungsprojekt kontrolliert werden können. Die anderen beiden Hebel sind Kosten und Funktionen. Ein Projekt kann sich für zwei der drei Hebel entscheiden: Wenn das Projekt schnell und mit vielen Funktionen durchgeführt werden muss, werden die Kosten steigen. Das heißt, wenn das Projekt schnell und mit vielen Funktionen durchgeführt werden muss, steigen die Kosten. Und wenn die Kosten so niedrig wie möglich gehalten werden müssen, ohne dass der Termin überschritten wird, müssen die Funktionen als erstes geopfert werden.

Abbildung 1-5 veranschaulicht das Konzept des Softwareentwicklungsdreiecks.

Abbildung 1-5. Wähle jeweils zwei der drei Elemente aus

Das nächste Problem, das ich anspreche, ist die Übergabe zwischen Entwicklung und QA.

Arbeiten in einer Dunkelkammer

Irgendwo zwischen der Entwicklung und dem Testen liegt eine allzu oft unangenehme Übergabe zwischen denjenigen, die die Software entwickelt haben, und denjenigen, die nun für die Bereitstellung, den Betrieb und die Unterstützung der Software in der Produktionsumgebung zuständig sind: dem Betriebsteam. Das Betriebsteam kann unter vielen Namen bekannt sein, z. B. Netzwerkadministratoren, Systemadministratoren oder Ingenieure (Site Reliability Engineer [SRE], Produktionsingenieure und so weiter).

Das Betriebsteam muss die Software, die möglicherweise noch nie in einer Computerumgebung wie der von in der Produktion getestet wurde, gemäß den vom Unternehmen geforderten Service Level Agreements (SLA) ausführen. Diese Software wurde vielleicht nur auf Entwicklerarbeitsplätzen und in einer kleinen Qualitätssicherungsumgebung (QS) getestet. Die QA-Umgebung kann ganz anders konfiguriert sein, z. B. ohne Load Balancer, in einer anderen Region und mit deutlich geringerer Auslastung als die Produktionsumgebung. Trotzdem wird die Software in der Produktion eingesetzt, und das Betriebsteam muss sie unterstützen.

Stell dir folgendes Szenario vor: Bis zu dem Zeitpunkt, an dem die Software bereitgestellt wurde, hat alles gut funktioniert. Es gab so gut wie keine Latenz bei Anfragen, und selbst wenn alle Entwickler an der Website arbeiteten, waren die Antwortzeiten unauffällig. Dabei wurde nicht bemerkt, dass die Entwickler einen Server verwendeten, der sich physisch im selben lokalen Netzwerk (LAN) befand wie sie selbst, und dass die von der Anwendung verwendeten Daten von einem nicht produktiven Replikat stammten, das nur selten Anfragen erhält.

Als das Betriebsteam die Software in die Produktion überführte, war die Website sofort so leistungsschwach, dass sie unbrauchbar wurde. Benutzer, die sich einloggten, konnten nicht weitermachen, weil die Sitzungen auf mehrere Server verteilt waren und nicht nur auf den einen, den die Entwickler während des gesamten Entwicklungszyklus verwendet hatten. Und dann ist da noch das Sicherheitsproblem.

Sicherheit als nachträglicher Gedanke

In manchen Unternehmen gibt es eine Mentalität, die "um jeden Preis produzieren" und ein "minimal lebensfähiges Produkt" (MVP) vorschreibt. Theoretisch kann ein solches Entwicklungsparadigma zwar funktionieren, aber es wird davon ausgegangen, dass genügend Zeit zur Verfügung steht, um die Probleme zu beheben, die die Software überhaupt erst "minimal lebensfähig" gemacht haben. Diese Zeit gibt es selten.

Wenn Deadlines drohen, scheint die Sicherheit das erste Erfordernis zu sein, das geopfert wird - vorausgesetzt, man hat überhaupt an Sicherheit gedacht. Ähnlich wie in der Mathematik ist Sicherheit sehr schwierig. Sicherheitsanalysten müssen jedes Mal richtig liegen, während ein Angreifer nur einmal richtig liegen muss.

Allzu oft wird die Abteilung für Datensicherheit in einem Unternehmen als die Abteilung angesehen, die "Nein" sagt. Ganz gleich, ob es sich um eine neue Anwendung, eine Firewall-Änderung oder eine Lockerung der Regeln für den Datenbankzugriff handelt, die für die Aufrechterhaltung der Sicherheit zuständigen Mitarbeiter neigen zwangsläufig dazu, Nein zu sagen, wenn eine Änderungsanfrage eintrifft.

Das Problem mit dem Betrieb und der Datensicherheit ist, dass sie unsichtbar sind, bis etwas schief geht. Im Falle der Datensicherheit wird viel Zeit damit verbracht, auf Compliance-Audits zu reagieren, die für viele Unternehmen scheinbar kaum einen Mehrwert für die alltägliche Sicherheit bringen. Die Einhaltung von Gesetzen und Vorschriften ist unerlässlich, aber die Vorschriften hinken oft der Realität hinterher, was bedeutet, dass die Vorschriften die Einhaltung von Schwachstellen von gestern festschreiben, während die Angreifer den neuesten Zero-Day nutzen.

Im Rahmen von DevSecOps ist eine frühzeitige Sicherheitsintegration notwendig, damit Firewall-Änderungen oder nicht konforme Methoden für den Zugriff auf und die Speicherung von Daten gar nicht erst in Betracht gezogen werden. Ohne Sicherheitsintegration könnte ein Entwickler unverschlüsselte Passwörter verwenden oder Anmeldedaten im Quellcode-Verwaltungssystem speichern, wodurch sie möglicherweise für Personen zugänglich werden, die nicht berechtigt sind, die Daten einzusehen.

In diesem Abschnitt wurden viele der mit der Softwareentwicklung verbundenen Probleme angesprochen, von denen einige mit DevOps und DevSecOps gelöst werden. Als Nächstes gehe ich darauf ein, wie die Kultur deines Unternehmens deinen Erfolg mit DevSecOps bestimmen kann.

Kultur zuerst

Die Organisationskultur ist der wichtigste Faktor, der darüber entscheidet, ob DevSecOps erfolgreich sein wird. Ein kontrollorientiertes Unternehmen, das von oben nach unten arbeitet, wird mit den notwendigen Veränderungen kämpfen, um DevSecOps wirklich umzusetzen. Eine solche Organisation kann Technologien einsetzen, die sich wie DevSecOps anfühlen, aber der kulturelle Wandel hin zu einer teamübergreifenden Abstimmung wird einen echten Erfolg verhindern.

Ein gewisses Verständnis für die Bedeutung der kulturellen Passung ist erst möglich, wenn du die Erfahrung gemacht hast, agile Praktiken in einer starren, kontrollorientierten Organisation umzusetzen. In einer solchen Organisation ist die beste Lösung weniger wichtig als die Unterordnung und die Aufrechterhaltung der Trennung, um die Kontrolle an der Spitze zu behalten. Ohne diese Erfahrung könnte man glauben, dass die Kultur für den Erfolg von DevSecOps keine Rolle spielt.

Anarchie und Chaos sind natürlich nicht das Ziel von DevSecOps. Stattdessen ermöglicht DevSecOps einen Problemlösungsansatz, selbst wenn die Lösung von jemandem aus einer anderen Abteilung kommt. Manche mögen glauben, dass DevSecOps in Verbindung mit der Mentalität von Startups (die historisch gesehen eine viel flexiblere Kultur haben) am besten gedeiht, aber die Bewegung ist viel nuancierter.

Die Mentalität eines Start-ups beinhaltet sowohl Wettbewerbsfähigkeit als auch Innovation und das Beschreiten neuer Wege ohne Rücksicht auf Hierarchien. Der Gründer eines Startups arbeitet häufig als Kollege, vielleicht sogar als Mentor, an der Seite seiner Mitarbeiter, um das Produkt voranzutreiben. In einem Startup sind Jobtitel weniger wichtig als die Sicherstellung, dass die Arbeit erledigt wird.

Bei DevSecOps arbeiten die Menschen funktionsübergreifend zusammen und setzen ihre Fähigkeiten dort ein, wo sie gebraucht werden. Wie bei einem Startup ist das Team transparent in seiner Arbeit und konzentriert sich auf das Ziel, nützliche Arbeit zu leisten. In einem solchen Umfeld können potenzielle Probleme frühzeitig erkannt und angegangen werden, lange bevor das Problem sichtbar wird.

Der nächste Abschnitt befasst sich mit dem Kern von DevOps, nämlich der Betonung von Prozessen im Gegensatz zu den Tools, die zur Umsetzung dieser Prozesse verwendet werden.

Prozesse statt Tools

Bei DevOps und DevSecOps geht es mehr um Prozesse als um die Werkzeuge, die zur Umsetzung dieser Prozesse verwendet werden. Ohne kulturelle Anpassung und Prozessänderungen stehen die bei DevSecOps verwendeten Werkzeuge dem Fortschritt oft im Weg und verlangsamen manchmal die Entwicklung. Selbst wenn ein Unternehmen noch nicht bereit ist, die für echtes DevSecOps erforderlichen kulturellen Veränderungen vorzunehmen, kann es durch die Anwendung einiger bewährter Methoden, die DevSecOps zugrunde liegen, einige Vorteile erzielen. Beginnen wir mit der Frage, wie man die Talente erkennt, die DevSecOps annehmen werden.

Förderung der richtigen Fähigkeiten

Die Zustimmung des Managements und das sichtbare Engagement für die DevSecOps-Prozesse entscheiden letztendlich darüber, ob DevSecOps erfolgreich sein wird. Es ist ein erster Schritt, die Teams miteinander reden zu lassen, auch wenn er wahrscheinlich eher symbolisch als produktiv ist. Manager können nicht erwarten, dass sie Menschen zusammenbringen, deren Interessen manchmal miteinander kollidieren, und dann erwarten, dass ein Wunder geschieht.

Die Prozesse, die mit DevSecOps verbunden sind, erfordern unterschiedliche Fähigkeiten, die sich über verschiedene Funktionsbereiche erstrecken. So ist zum Beispiel ein Entwickler, der auch seine eigenen Cluster einrichtet und den Unterschied zwischen DNS und DHCP erklären kann, ein Kandidat für ein DevSecOps-Pilotprogramm innerhalb einer Organisation. Der erste Schritt besteht also darin, die Mitarbeiter zu identifizieren, die über funktionsübergreifende Erfahrungen verfügen. Diese Personen können als Vorreiter für DevSecOps eingesetzt werden.

Die Identifizierung vielseitiger Fähigkeiten und die Befähigung von Mitarbeitern mit diesen Fähigkeiten, Funktionsgrenzen zu überschreiten, ist der erste Schritt des Prozesses und verdeutlicht, wie wichtig es ist, dass das Management und die Führungskräfte DevSecOps unterstützen. Die Entwickler müssen Zugang zu oder zumindest Einblick in Server- und Netzwerkbereiche haben, die bisher ausschließlich in den Zuständigkeitsbereich von Operations fielen. Mitarbeiter aus den Bereichen Betrieb und Sicherheit müssen frühzeitig in den Projektzyklus eingebunden werden, damit sie Feedback zur Verbesserung der nachgelagerten Prozesse geben können. Ein Beispiel: Eine Änderung für ein in der Entwicklung befindliches Projekt wird die Festplattenauslastung immens erhöhen. Mit einer kleinen Änderung am Projekt kann die Auslastung jedoch auf ein anderes System verlagert werden. Die Möglichkeit, diese Änderung vorzunehmen, besteht nur zu einem frühen Zeitpunkt im Entwicklungsprozess, weshalb es wichtig ist, dass die Mitarbeiter/innen des Bereichs Operations an jedem Projekt maßgeblich beteiligt sind.

DevSecOps als Prozess

Der Prozess von DevSecOps bringt Menschen aus verschiedenen Funktionsbereichen zusammen. Das Ziel ist es, bessere Software zu produzieren - Software, die die Anforderungen erfüllt und schnell und präzise geliefert wird. Der Prozess zur Bereitstellung dieser Software kann und wird häufig mit Werkzeugen durchgeführt. Im nächsten Abschnitt werden wir uns einige dieser Prozesse ansehen.

Hämmer und Schraubenzieher

Manche Aufträge lassen sich nur mit Hilfe von Werkzeugen effizient erledigen . Ein Dachdecker benutzte eine Nagelpistole, die an einen Drucklufttank angeschlossen war, um Schindeln auf meinem Dach zu befestigen. Dieselbe Arbeit hätte auch mit einem Hammer erledigt werden können, aber mit einem Schraubenzieher wäre es viel schwieriger gewesen. Natürlich hätte der Bauunternehmer den Griff des Schraubenziehers benutzen können, um die Nägel einzuschlagen, aber das wäre langsam und ineffizient gewesen und hätte dazu geführt, dass die Nägel verbogen und die Schindeln beschädigt worden wären. Hätte ich auf dem Dach versucht, die Nagelpistole zu bedienen, wäre ich mindestens einmal in die Notaufnahme gekommen.

DevSecOps ist ähnlich. Genauso wie man für ein richtiges Dach eine Kombination aus Facharbeitern und Werkzeugen benötigt, braucht man für DevSecOps Werkzeuge und das Know-how, um die Werkzeuge richtig zu nutzen. Genauso wie eine leistungsstarke Nagelpistole das richtige Werkzeug ist, wenn sie von einer qualifizierten Person benutzt wird, können DevSecOps-Werkzeuge enorme Effizienzgewinne bringen, wenn sie von den richtigen Leuten eingesetzt werden.

Das Werkzeug soll helfen, den Auftrag zu erledigen, aber das Werkzeug definiert nicht den Auftrag.

Wiederholbarkeit

DevSecOps konzentriert sich auf den Aufbau wiederholbarer Prozesse, die dann die Automatisierung erleichtern. Oder vielleicht ist es auch andersherum. Automatisierung erleichtert wiederholbare Prozesse. Ja, beides ist richtig. Durch die Automatisierung der Erstellung von Umgebungen und der Bereitstellung von Code können diese Prozesse immer wieder mit demselben Ergebnis durchgeführt werden. Automatisierte Tests ersparen es, dieselben Bereiche des Codes manuell zu testen und erneut zu testen, selbst wenn Änderungen oder Fehlerbehebungen vorgenommen wurden.

Bei der Implementierung von Prozessen und Tools, die die Wiederholbarkeit unterstützen, steht in Unternehmen, die DevSecOps praktizieren, das "as Code"-Paradigma im Vordergrund. "Infrastructure as Code", "Configuration as Code" und "Everything as Code" sind Begriffe, die sich alle auf dasselbe Konzept beziehen: so viel wie möglich mit Tools und Prozessen zur Quellcodeverwaltung verwalten.

Die meisten Server verwenden Textdateien oder textähnliche Dateien, um Konfigurationselemente zu speichern. Diese Textdateien können in einem Quellcode-Verwaltungstool wie Git gespeichert werden. Auf diese Weise können Konfigurationsänderungen versioniert werden. So können andere Administratoren zum Beispiel die Commit-Historie einsehen und sehen, dass ich einmal einen Unterstrich in einem DNS-Hostnamen verwendet und damit Tausende von Domains offline genommen habe. Wenigstens ist das Repository nicht öffentlich zugänglich, so dass niemand meinen Fehler finden wird. Im Ernst: Die Versionierung von Konfigurationsänderungen ermöglicht eine schnelle Wiederherstellung, wenn ein Problem durch eine Konfigurationsänderung verursacht wird. Die Quellcodeverwaltung für Serverkonfigurationen erleichtert auch die Versionierung, d. h., Entwickler können einen bestimmten Satz von Konfigurationen einsetzen, um einen gemeldeten Fehler in derselben Umgebung erneut zu erzeugen.

Der gleiche Satz von Konfigurationen mit den gleichen Softwareversionen macht die Softwarebereitstellung wiederholbar. Die wiederholbare Bereitstellung steht in direktem Zusammenhang mit Continuous Integration/Continuous Deployment (CI/CD) Szenarien, bei denen der Code automatisch getestet und durch eine Reihe von Umgebungen geleitet wird, bevor er in die Produktionsumgebung übertragen wird. Ein Administrator ändert ein Konfigurationselement für einen Dienst, überträgt die Konfigurationsdatei und schiebt die Änderung in das entfernte Repository, wo die Änderung bemerkt und die Verteilung an die entsprechenden Server automatisch gestartet wird.

Hinweis

Ich ignoriere absichtlich die zahlreichen Formate, die zum Speichern von Konfigurationen verwendet werden, wie Yet Another Markup Language (YAML), INI-Dateistruktur, Extensible Markup Language (XML), JavaScript Object Notation, brew Skripte, m4 Befehle und jede andere Struktur, die mit einem Texteditor wie Vim bearbeitet werden kann. Für die Zwecke dieses Buches werden alle diese Formate einfach als Textdateien bezeichnet, es sei denn, dies würde zu unnötiger Verwirrung führen. Hier ist ein Beispiel für YAML:

- name: add docker apt key
    apt_key:
      url: https://download.docker.com/linux/debian/gpg
      state: present
      
- name: add docker repo
    apt_repository:
      repo: deb [arch=amd64] \
https://download.docker.com/linux/debian stretch stable
      state: present

Sichtbarkeit

DevSecOps dient auch dazu, die Sichtbarkeit während des gesamten Entwicklungsprozesses zu ermöglichen. Es gibt nicht nur eine häufige Sichtbarkeit durch eine agile Zeremonie wie das Daily Standup, sondern auch durch die Werkzeuge, die den Code bei Bedarf automatisch in die Umgebungen einspielen. Die Mitglieder eines DevSecOps-Teams können genau sehen, welcher Code und welche Konfigurationen in welchen Umgebungen vorhanden sind und können bei Bedarf neue Umgebungen bereitstellen.

Zuverlässigkeit, Geschwindigkeit und Umfang

Wiederholbarkeit und Transparenz führen zu Zuverlässigkeit. Code und Umgebungen können immer wieder auf dieselbe Art und Weise bereitgestellt werden. Wenn bei der Bereitstellung ein Fehler auftritt, wird dieser aufgrund der Transparenz der Bereitstellungswerkzeuge und -prozesse sofort gefunden. Mit der Zuverlässigkeit kommt auch die Geschwindigkeit, d.h. die Fähigkeit, schnell auf veränderte Anforderungen zu reagieren. Diese Veränderung kann darin bestehen, dass die Zahl der Mitarbeiter/innen je nach Bedarf erhöht oder verringert werden muss, was aufgrund der wiederholbaren und zuverlässigen Prozesse bei der Bereitstellung möglich und nicht mehr schwierig ist.

Microservices und Architekturmerkmale

Auch wenn sie für DevSecOps nicht direkt erforderlich sind, kann die Nutzung von Microservices die Geschwindigkeit und Skalierbarkeit erhöhen. Bei Microservices werden kleine Funktionsbereiche des Codes identifiziert und getrennt, so dass diese Funktionsbereiche für sich alleine stehen können und eine konsistente Programmierschnittstelle (API) zu anderen Diensten innerhalb der Architektur bieten. Die API wird häufig durch einen HTTP-Webdienst ausgedrückt. Da Microservices eigenständig sind, können sie getrennt von anderen Diensten oder Funktionsbereichen entwickelt und eingesetzt werden, was die Gesamtgeschwindigkeit und die Entwicklungsdynamik weiter erhöht.

In diesem Abschnitt haben wir uns einige der Prozesse angesehen, die mit DevOps und DevSecOps zu tun haben. Im nächsten Abschnitt wird der SDLC, der weiter oben im Kapitel vorgestellt wurde, erweitert, indem die Ideen hinter den Prozessen in einen erweiterten SDLC für DevSecOps einfließen.

Der DevSecOps SDLC

An dieser Stelle hast du hoffentlich ein Gefühl für einige der Probleme in der Softwareentwicklung bekommen; selbst relativ neue Entwicklungsmethoden wie Agile fördern eine Silo-Mentalität. Anstelle des in Abbildung 1-2 dargestellten Vier-Phasen-Modells wurde ein Acht-Phasen-Modell entwickelt. Dieses Modell umfasst neben anderen Aufgaben auch die Planung, die Entwicklung und das Testen und ist in Abbildung 1-6 dargestellt.

Abbildung 1-6. Erstellen eines neuen SDLC für DevOps

Der Hauptvorteil des DevOps SDLC ist, dass er die tatsächlichen Abläufe der Softwareentwicklung besser widerspiegelt. Es wird viel mehr Zeit für die Programmierung und das Testen der Software aufgewendet als für die Planung der Programmierung und des Testens der Software, aber der Zwischenschritt "Build" spiegelt die Montagephase wider, in der die verschiedenen Teile einer modernen Anwendung miteinander verbunden werden. Der Zwischenschritt "Release" spiegelt die Notwendigkeit mehrerer Komponenten und potenzieller Genehmigungsverfahren wider, die die Software durchlaufen muss, um eingesetzt werden zu können. In den SDLCs, die in diesem Kapitel behandelt werden, ist die Notwendigkeit des Betriebs und der Überwachung der Software nach der Inbetriebnahme nicht enthalten. Ohne die Phasen "Betrieb" und "Überwachung" wird das Betriebsteam wieder unsichtbar.

Du hast vielleicht bemerkt, dass "Sec" im letzten Absatz und in Abbildung 1-6 vorübergehend weggelassen wurde. Das liegt daran, dass DevOps bereits eine eigene Bewegung war, bevor die Sicherheit in der Mitte hinzugefügt wurde. Es ist klar, dass es einen Bedarf an Sicherheit gibt, aber wo soll sie hin? Aus konzeptioneller und praktischer Sicht wäre es schwierig, Sicherheit als eigene Phase einzuführen. Wenn "Sicherheit hinzufügen" eine neue Phase ist und nach der Planung durchgeführt wird, was passiert dann, wenn ein Sicherheitsproblem während der Programmierung auftritt? Es ist auch schwierig, die Sicherheitsphase nach oder während des Testens oder der Freigabephase einzufügen. Was passiert, wenn ein ernsthaftes Sicherheitsproblem auftaucht? Kommt dann das gesamte Projekt zum Stillstand, um das Problem zu beheben? Wenn du die Sicherheitsphase erst später in den Betrieb und die Überwachung verlegst, bedeutet das, dass das Problem in der Produktionsumgebung auftritt - mit der Gefahr, die ein Sicherheitsproblem in der Produktion mit sich bringt.

Stattdessen wird die Sicherheit in der Regel als Grundlage jeder Phase dargestellt. Du kannst dir die Sicherheit wie in Abbildung 1-7 vorstellen.

Abbildung 1-7. Sicherheit ist Teil jeder Phase eines DevSecOps SDLC

Sicherheit wird in der Regel auf diese Weise dargestellt, um die Notwendigkeit zu verdeutlichen, Sicherheit und sicherheitsorientierte Prozesse in jeder Phase der Softwareentwicklung einzubeziehen. So muss nicht mehr festgelegt werden, wo eine Sicherheitsphase auftreten soll oder was zu tun ist, wenn ein Sicherheitsproblem gefunden wird.

Die Erweiterung des SDLC vom Vier-Phasen-Modell auf das neuere Acht-Phasen-Modell, das die Sicherheit mit einbezieht, ermöglicht es DevSecOps-Praktikern, die Prozesse abzubilden, die die moderne Softwareentwicklung umfassen. Wichtig ist, dass die Aufgaben, die in jeder Phase erledigt werden, ohnehin hinter den Kulissen stattfinden. Der DevSecOps SDLC hebt diese Aufgaben lediglich hervor. Diese Phasen werden im weiteren Verlauf des Buches untersucht.

Zusammenfassung

DevSecOps ist eine natürliche Weiterentwicklung der Softwareentwicklung. Ausgehend von agilen Prozessen und einer transparenten Open-Source-Mentalität arbeitet DevSecOps daran, Silos aufzubrechen, die die Entwicklung verlangsamen und weniger zuverlässig machen. Kulturelle Veränderungen, die an der Spitze eines Unternehmens beginnen, sind das wichtigste Schlüsselelement, um den größten Nutzen aus DevSecOps zu ziehen. Ohne das Engagement des Managements kann DevSecOps zu mehr Werkzeugen verkommen, die nur halb genutzt werden. Mit einem Kulturwandel und dem Abbau von Barrieren zwischen den Teams können jedoch Tools hinzugefügt werden, die die Wiederholbarkeit, Transparenz, Zuverlässigkeit, Geschwindigkeit und Skalierung erleichtern, die moderne Unternehmen benötigen.

Von hier aus untersucht das Buch gängige DevSecOps-Praktiken, wobei die Inhalte aus Abbildung 1-7 als Leitfaden dienen. Jedes Kapitel behandelt eine oder mehrere Phasen des DevSecOps SDLC. Der Schwerpunkt liegt dabei auf den Prozessen und Praktiken sowie auf ausgewählten Tools, die in diesen Phasen eingesetzt werden. Bevor du dich auf den unendlichen Pfad von DevSecOps begibst, enthält Kapitel 2 Grundlagenwissen, das für die späteren Kapitel des Buches hilfreich sein wird. Viele Leserinnen und Leser werden bereits über viel, wenn nicht mehr, Wissen verfügen. Ebenso werden viele Leser/innen, je nach ihrem Hintergrund, bereits eine Vorstellung von einigen der in Kapitel 2 behandelten Bereiche haben. Natürlich können die in Kapitel 2 behandelten Technologien auch völlig neu sein. Aber wenn das Buch tiefer in DevSecOps einsteigt, wird es für alle hilfreich sein, eine gemeinsame Definition für die oft überladenen Fachbegriffe zu haben.

Get DevSecOps lernen now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.

Start your free trial