DevSecOps, Secure by Design und NIST SSDF

DevSecOps, Secure by Design und NIST SSDF

0:00 Wir haben jetzt eine Landkarte und eine geordnete Liste von Bedrohungen. Was fehlt, ist der Rahmen, in dem daraus dauerhaft etwas wird — und nicht nur eine Aufräumaktion, von der in einem halben Jahr niemand mehr spricht. Dafür schauen wir uns in diesem Modul ein Rahmenwerk an, das das amerikanische Normungsinstitut NIST veröffentlicht hat: den Secure Software Development Framework.

0:21 Sein größter Vorzug ist zugleich das, was Teams zunächst irritiert — er schreibt Ihnen nicht vor, wie Sie etwas tun sollen. Er beschreibt nur, was am Ende gelten soll.

DevSecOps, Secure by Design und NIST SSDF

0:32 Dieses Modul ist das prozessorientierteste des ganzen Seminars, und es steht bewusst früh. Denn wenn wir ab Modul vier Werkzeuge einrichten, brauchen wir eine Antwort auf die Frage, wer sich um die Befunde kümmert. Wir klären deshalb drei Dinge: wie Sicherheit im Entwicklungsprozess verankert wird statt daneben, welche Rollen es dafür braucht, und wie die vier Bereiche des Rahmenwerks aufgebaut sind.

Sicherheit als Bestandteil des Entwicklungsprozesses

0:54 Im ersten Kapitel räumen wir mit einem Begriff auf, der in den letzten Jahren viel zu viel Arbeit leisten musste: Shift Left. Die Idee dahinter ist richtig. Nur ist sie oft so verstanden worden, dass man nach dem Merge nicht mehr hinsehen muss. NIST beschreibt sein Rahmenwerk als Kernsatz hochrangiger Praktiken sicherer Entwicklung, der sich in jedes Vorgehensmodell einfügen lässt — ob Sie agil arbeiten oder in Phasen.

1:18 Interessant sind die drei Ziele, die dort ausdrücklich genannt werden, weil sie sich unterscheiden. Erstens: weniger Schwachstellen in freigegebener Software. Zweitens: die Auswirkung der Schwachstellen begrenzen, die man noch nicht entdeckt hat — eine erfrischend realistische Annahme. Und drittens: ihre Ursachen beheben, damit sie sich nicht wiederholen.

1:39 Das dritte Ziel wird am häufigsten übersprungen, und es ist das einzige, das den Rückstand langfristig kleiner macht. Zwei Spalten, und die linke ist die verbreitete Lesart. Prüfung wandert nach vorn, die Freigabe wird entlastet, Codefehler werden früher gefunden — alles richtig, alles nützlich. Nur endet diese Lesart mit dem Merge. Die rechte Spalte ist die Denkweise, die dieses Seminar braucht: Prüfung an jeder Station, bis zum Supportende des Produkts.

2:07 Denken Sie an unsere vier Angriffspfade aus Modul zwei — drei davon liegen rechts vom Commit. Wer nur nach links schiebt, hat gegen diese drei nichts gewonnen. Shift Left ist also kein Gegensatz zu durchgängiger Absicherung, aber eben auch kein Ersatz. Diese Aussage steht so in der Publikation, und sie ist mehr als eine Höflichkeitsfloskel.

2:28 Das Dokument schreibt nicht vor, wie eine Praxis umzusetzen ist — im Mittelpunkt stehen die Ergebnisse. Und es verlangt ausdrücklich einen risikobasierten Zugang: Sie wählen aus, welche Praktiken für Sie relevant, angemessen und wirksam sind. Das ist eine Einladung, nicht alles gleichzeitig zu tun. Der dritte Punkt wird oft unterschätzt: Das Rahmenwerk liefert ein gemeinsames Vokabular, mit dem auch Einkäufer und Lieferanten sprechen können.

2:53 Wenn Sie in Modul sechzehn Kundenanfragen beantworten, werden Sie genau diese Begriffe wiederfinden. Eine kleine Übung mit großer Wirkung. Höchstens fünf Punkte, und zu jedem muss sich an einem konkreten Pull Request der Deichwacht mit ja oder nein antworten lassen. Dieser Test ist strenger, als er klingt. „Sicherheitsaspekte wurden angemessen berücksichtigt" fällt sofort durch — das lässt sich nicht beantworten, nur behaupten.

3:19 „Keine neuen Abhängigkeiten ohne Eintrag in der Liste" dagegen schon. Der Hinweis auf der Folie ist der eigentliche Filter: Alles, was Sie nur mit „angemessen" oder „nach Bedarf" formulieren können, gehört nicht auf die Liste. Fünf harte Punkte wirken mehr als zwanzig weiche. Der erste Punkt ist die Ironie des Themas: Man plant Sicherheit als eigene Phase — und löst sie damit genau wieder aus dem Prozess heraus, aus dem man sie nicht herauslösen wollte.

3:46 Der zweite ist der Ehrgeiz: Alle Praktiken auf einmal, obwohl das Rahmenwerk ausdrücklich zur Auswahl nach Risiko rät. Der dritte betrifft unsere eben geschriebene Liste — sie wird formuliert und nie an einer echten Änderung erprobt; dabei zeigt sich erst dort, welcher Punkt unbeantwortbar ist. Und der vierte fasst das Missverständnis dieses Kapitels zusammen: Shift Left als Erlaubnis, nach dem Merge wegzusehen.

Rollen und Verantwortlichkeiten

4:10 Im zweiten Kapitel geht es um eine Frage, die technisch klingt, aber keine technische Antwort hat: Wer kümmert sich eigentlich? Ohne benannte Rolle bleibt jede Praxis eine Absichtserklärung — und jedes Werkzeug ein Erzeuger unbearbeiteter Meldungen. Der Bereich „Prepare the Organization" enthält drei Aufgaben, die zusammengehören und meist getrennt behandelt werden.

4:31 Erstens: Rollen und Verantwortlichkeiten für den gesamten Entwicklungszyklus definieren. Zweitens: rollenbezogen schulen — also nicht alle gleich, sondern je Rolle mit eigenem Lernziel. Und drittens: sich die Unterstützung der Leitungsebene sichern. Der dritte Punkt wird gern als Formalie abgetan, ist aber der tragende. Ohne ihn bleiben die ersten beiden wirkungslos, weil in jedem Konflikt zwischen Sicherheit und Termin die Entscheidung informell fällt — und zwar immer in dieselbe Richtung.

5:01 Vier Quadranten mit einer Besonderheit: Der dritte, das Plattformteam, fehlt in den meisten Organigrammen. Dabei entscheidet er faktisch über die Sicherheit aller Projekte, weil er Werkzeuge, Pipelines und Basis-Images verantwortet. Ein Beispiel: Wenn das Basis-Image ein veraltetes Paket enthält, erben es alle Dienste — und kein einzelnes Entwicklungsteam kann das lösen.

5:23 Ähnlich beim vierten Quadranten: Product Security ist die Stelle, die bewertet und freigibt. Wenn diese Rolle niemandem gehört, bewertet am Ende die Person, die gerade Zeit hat. Das Rahmenwerk nennt Security Champions genau dort, wo Risikomodellierung im Team stattfinden soll — also nicht als Ehrentitel, sondern mit einer konkreten Aufgabe.

5:43 Und hier scheitern die meisten Programme: Die Rolle wird benannt, aber nicht mit Zeit hinterlegt. Wer neben seinem Sprintpensum noch Bedrohungsmodelle pflegen soll, tut eines von beidem nicht. Der zweite Punkt ist die rollenbezogene Schulung: Eine Entwicklerin braucht anderes Wissen als jemand, der Freigaben erteilt. Und der letzte Punkt zieht die Verbindung zum Plattformteam — wer die Werkzeuge verantwortet, entscheidet über mehr Sicherheit als jedes einzelne Projekt.

6:10 Die Fußzeile bringt die Erfahrung auf den Punkt: Streit entsteht selten über die linke Spalte, fast immer über die rechte. Dass Entwicklung die Umsetzung im Code entscheidet, bestreitet niemand. Dass sie Risikoakzeptanz nicht entscheidet, schon eher — denn im Alltag passiert genau das, nur unausgesprochen. Wenn ein Team einen Befund als „nicht so wichtig" einstuft und weitermacht, hat es Risiko akzeptiert, ohne dass jemand unterschrieben hat.

6:36 Die Tabelle macht diese Entscheidungen wieder sichtbar. Beachten Sie auch die letzte Zeile: Die Leitung entscheidet über Risikoakzeptanz, aber ausdrücklich nicht über die technische Lösung. Der erste Punkt haben wir gerade besprochen und er ist der häufigste überhaupt. Der zweite ist die klassische Lücke zwischen zwei Teams: Für Basis-Images fühlt sich niemand zuständig, weil sie zwischen Entwicklung und Betrieb fallen — und genau dort sitzen die meisten Befunde des Container-Scans aus Modul sechs.

7:04 Der dritte Punkt: Schulung findet einmal für alle statt, obwohl das Rahmenwerk je Rolle ein eigenes Lernergebnis verlangt. Und der vierte ist der stille: Die Leitung unterstützt mündlich, es gibt nur keine dokumentierte Entscheidung — und im Zweifel hat es dann niemand gesagt.

Die vier Bereiche des NIST SSDF

7:19 Jetzt zum Aufbau des Rahmenwerks selbst. Vier Bereiche, jeder mit Praktiken, jede Praxis mit Aufgaben. Das klingt nach viel Papier — ist aber vor allem ein Ordnungssystem, in das sich alles einsortieren lässt, was wir in diesem Seminar bauen. Die vier Bereiche tragen Kürzel, die Sie in Ausschreibungen und Kundenfragebögen wiedersehen werden.

7:40 PO steht für die Vorbereitung der Organisation, PS für den Schutz der Software, PW für das Herstellen gut abgesicherter Software und RV für den Umgang mit Schwachstellen. Jede Praxis darunter trägt eine Nummer — PO Punkt eins, RV Punkt zwei. Und jede Aufgabe beschreibt konsequent ein Ergebnis, keinen Weg dorthin. Das macht das Dokument anfangs abstrakt und auf Dauer nützlich: Es überlebt den Werkzeugwechsel, den Ihre Pipeline in drei Jahren durchläuft.

8:08 Vier Schichten, und ihre Reihenfolge ist kein Zufall. Ganz oben die Organisation: Anforderungen, Rollen, Werkzeuge, Kriterien, Umgebungen — das Fundament, ohne das die anderen drei nicht tragen. Darunter der Schutz der Software selbst: Code schützen, Integrität nachweisbar machen, Releases archivieren. Das sind die Themen unserer Module vier, acht und zwölf.

8:30 Die dritte Schicht ist die bekannteste, weil dort Entwurf, Build und Prüfung stehen. Und ganz unten der Bereich, um den es in Modul elf und fünfzehn geht: auf Schwachstellen reagieren, sie bewerten, beheben und ihre Ursachen analysieren. Aus dem umfangreichen Katalog habe ich vier Praktiken herausgegriffen, die dieses Seminar tragen. PO Punkt fünf verlangt sichere Entwicklungsumgebungen — trennen und härten.

8:56 PS Punkt eins verlangt, alle Formen von Code vor unbefugtem Zugriff und Manipulation zu schützen; das ist unser nächstes Modul. PS Punkt zwei verlangt einen Mechanismus, mit dem sich die Integrität eines Release überprüfen lässt — also Hashes, Signaturen, Provenance, unser Modul zwölf. Und PW Punkt sechs verlangt eine sichere Konfiguration des Build-Prozesses. Die Fußzeile ergänzt PS Punkt drei: jedes Release samt Nachweisen archivieren.

9:23 Das klingt nach Verwaltung und ist die Grundlage jeder späteren Untersuchung. Die ersten drei Bereiche lassen sich in ein Projekt fassen — man richtet etwas ein, und dann steht es. Der vierte nicht. Schwachstellen werden fortlaufend gefunden, nicht einmalig zum Release, und deshalb ist dieser Bereich Dauerbetrieb. Beachten Sie, dass das Rahmenwerk Bewertung, Priorisierung und Behebung als drei getrennte Schritte führt, jeder mit eigenen Belegen.

9:49 Und die Ursachenanalyse zielt ausdrücklich auf die Wiederholung, nicht auf den Einzelfall. Der letzte Punkt schließt den Kreis zur Archivierung: Ohne aufbewahrte Releases und Nachweise ist die Analyse nach einem Vorfall schlicht nicht durchführbar. Der erste Punkt begegnet einem in Ausschreibungen: Die Kürzel werden zitiert, weil sie gut aussehen, und niemand hat die dazugehörige Aufgabe gelesen.

10:12 Der zweite ist eine Zuständigkeitsfrage — der Umgang mit Schwachstellen wird an den Betrieb abgeschoben, obwohl die Behebung im Code stattfindet. Der dritte ist der ernsteste: Die Zuordnung endet bei der Zuordnung. Man trägt ein, was man tut, und niemand prüft, ob es wirkt. Und der vierte betrifft die Ursachenanalysen, die durchaus geführt werden — ihre Ergebnisse ändern nur nie einen Prozess. Dann sind sie Dokumentation, keine Verbesserung.

Übung

10:39 In der Übung legen wir das Rahmenwerk auf die Deichwacht. Der interessante Teil ist dabei nicht, was fehlt — das lässt sich schnell aufzählen und ist selten überraschend. Der interessante Teil ist der Unterschied zwischen dem, was gelebt wird, und dem, was nur dokumentiert ist. Diese Lücke ist in fast jedem Projekt größer als erwartet, und sie lässt sich nur ehrlich schließen, wenn man sie zuerst ehrlich benennt.

11:03 Drei Kennzeichnungen: gelebt, nur dokumentiert, fehlend. Diese Unterscheidung ist der Kern der Übung, und sie ist unbequem. Fast jedes Team findet Praktiken, die es für gelebt hielt und die in Wahrheit nur in einem Wiki stehen. Das ist kein Vorwurf — das passiert überall, wo eine Regel eingeführt und nie nachgehalten wurde.

11:23 Wichtig ist der Abgleich im vierten Schritt: Eine Lücke, zu der es keine passende Bedrohung aus Modul zwei gibt, ist keine Lücke, sondern eine Beschäftigung. Wir haben nicht die Zeit, alles zu tun, also tun wir das Wirksame. Die Reihenfolge ist wichtig: Erst eintragen, dann bewerten. Schreiben Sie die vier Bereiche als Spalten auf und tragen Sie ein, was heute passiert — ohne zu werten, sonst schreibt sich die Liste schön.

11:49 Erst danach kommt die Kennzeichnung mit gelebt, dokumentiert oder fehlend. Dann der Abgleich mit der Reihenfolge aus dem Bedrohungsmodell. Und zum Schluss die Auswahl: drei Praktiken, die wir in diesem Seminar tatsächlich bauen. Nicht fünfzehn. Drei, die am Ende der drei Tage wirklich stehen und nicht als Vorsatz überleben.

12:09 Der erste Punkt ist der verbreitetste Selbstbetrug im Umgang mit Rahmenwerken: Eine Praxis gilt als vorhanden, weil ein Werkzeug installiert ist. Ein Scanner, dessen Befunde niemand liest, ist keine gelebte Praxis. Der zweite Punkt betrifft die Auswahl — sie richtet sich nach dem, was leicht geht, statt nach dem Bedrohungsmodell, und dann bauen wir die billige Maßnahme gegen die unwahrscheinliche Bedrohung.

12:32 Der dritte ist Überehrgeiz: alle vier Bereiche gleichzeitig auf denselben Reifegrad. Und der vierte kostet den Nutzen: Das Ergebnis wird zum Statusbericht nach oben, statt Arbeitsliste nach innen zu bleiben.