Security im Software Development Lifecycle

Security im Software Development Lifecycle

0:00 Wir haben jetzt die Haltung, die Analyse und die Prinzipien beisammen. Bleibt die Frage, die über Erfolg oder Misserfolg entscheidet: Wie hält man das durch? Denn Sicherheit ist kein Meilenstein, den man abhakt, sondern eine Aktivität in jeder Phase — von der Anforderung bis in den laufenden Betrieb. Der Vergleich, der hier trägt, ist die Gebäudewartung: Ein Haus wird nicht einmal geprüft und ist dann für immer sicher. Es altert, die Umgebung ändert sich, Vorschriften auch.

0:28 Software ist da nicht anders, nur schneller. Dieses Kapitel beschreibt, wie Sicherheit vom Projekt zum Prozess wird.

Security im Software Development Lifecycle

0:35 Wir gehen den Lebenszyklus einmal durch. Zuerst der Überblick: Welche Sicherheitsaktivität gehört in welche Phase? Dann zwei Werkzeuge, die im Alltag den Unterschied machen — Security Reviews und dokumentierte Architekturentscheidungen. Danach der geordnete Umgang mit Schwachstellen, wenn es doch passiert ist. Ein eigener Abschnitt gilt den Abhängigkeiten, also fremdem Code in Ihrem Produkt.

0:59 Und am Ende schließen wir den Kreis: Sicherheit als kontinuierlicher Prozess. Vier Gedanken. Der erste: Sicherheit ist eine durchgängige Aktivität, kein Abnahmeschritt — jede Phase hat ihren eigenen Beitrag, und keine kann ihn an eine spätere delegieren. Der zweite: Reviews und Architekturentscheidungen sind die Stellen, an denen Sicherheit im Alltag tatsächlich passiert oder eben nicht; dort lohnt es, bewusst hinzuschauen.

1:25 Der dritte: Schwachstellen und Abhängigkeiten brauchen einen geordneten Umgang, nicht Heldentaten einzelner. Und der vierte, vielleicht wichtigste: Sicherheit ist ein Kreislauf. Was heute sicher ist, ist es in einem Jahr nur, wenn jemand nachgeschaut hat.

Security von Anforderungen bis Betrieb

1:40 Beginnen wir mit der Landkarte. Wenn Sicherheit in jeder Phase stattfinden soll, ist die naheliegende Frage: Was genau tut man dort eigentlich? Die Antwort ist erfreulich konkret — für jede Phase gibt es eine Handvoll etablierter Aktivitäten, und die meisten davon kennen Sie bereits aus den vorigen Kapiteln. Neu ist vor allem die Einsicht, dass sie zusammengehören und dass keine die andere ersetzt.

2:03 Ein sicherer Entwicklungsprozess verteilt Sicherheitsaktivitäten über alle Phasen — Anforderung, Entwurf, Implementierung, Test, Release, Betrieb — statt sie ans Ende zu schieben. Das Bild dazu kennen Sie aus dem Bauwesen: Der Bauleiter kommt nicht einmal zur Schlussabnahme, sondern schaut regelmäßig vorbei, weil manches später schlicht nicht mehr sichtbar ist.

2:24 Was hinter der verputzten Wand liegt, prüft am Ende niemand mehr. In der Software ist es dasselbe, nur dass die Wand aus Abhängigkeiten und Annahmen besteht. Wer in jeder Phase kurz hinschaut, muss am Ende weniger aufreißen. Das erste Argument kennen wir aus Kapitel 1 und es gilt hier unverändert: Früh gefundene Fehler sind billiger.

2:43 Das zweite ist neu und wird oft übersehen — jede Phase kann ihre eigenen Bedrohungen einführen. Ein sauberer Entwurf hilft nichts, wenn beim Release Zugangsdaten im Image landen; und ein sicheres Release altert im Betrieb, wenn niemand patcht. Und das dritte Argument betrifft die Übergänge selbst: Lücken entstehen bevorzugt zwischen den Phasen, dort, wo Verantwortung wechselt und jeder annimmt, der andere habe hingeschaut.

3:07 Durchgängigkeit heißt vor allem, diese Übergabepunkte bewusst zu gestalten. Diese Tabelle ist im Grunde die Zusammenfassung des ganzen Seminars, sortiert nach Zeit. Sie erkennen die vorigen Kapitel wieder: Schutzbedarf und Security Requirements aus Kapitel 2, Threat Modeling aus Kapitel 3, die Prinzipien aus Kapitel 4. Was neu dazukommt, sind die drei unteren Zeilen — Test, Release und Betrieb, also der Teil des Lebens einer Software, der länger dauert als ihre Entwicklung.

3:35 Die Logik dahinter: Jede Phase kann etwas prüfen, was in der vorigen noch nicht sichtbar war und in der nächsten schon verdeckt ist. Und die Fußzeile ist die eigentliche Anforderung an Ihren Prozess: Kein Übergang ohne bewusste Sicherheitsaktivität. Eine Kartenübung, und sie ist bewusst haptisch gehalten. Sie bekommen eine gemischte Liste von Sicherheitsaktivitäten und ordnen sie den Phasen zu.

3:59 Was dabei regelmäßig passiert: Bei einigen Karten diskutiert die Gruppe, weil eine Aktivität in mehrere Phasen passt — genau das ist der Lerneffekt. Eine Bedrohungsanalyse gehört in den Entwurf, aber sie wird im Betrieb wiederholt. Die Begründung zählt hier mehr als die Zuordnung. Und ganz nebenbei entsteht dabei etwas Nützliches: eine erste Vorstellung davon, welche dieser Aktivitäten in Ihrem eigenen Projekt heute schon stattfinden — und welche nicht.

Security Reviews und Architekturentscheidungen

4:26 Damit zu den beiden Stellen, an denen Sicherheit im Alltag konkret wird. Beide sind unspektakulär, beide kosten wenig — und beide werden erstaunlich oft ausgelassen. Das Review, weil der Termindruck drückt; die Dokumentation, weil die Entscheidung im Moment ja allen klar ist. Beides rächt sich zu unterschiedlichen Zeitpunkten, aber es rächt sich zuverlässig. Schauen wir uns an, wie man beides leichtgewichtig hinbekommt.

4:52 Ein Security Review prüft Entwurf oder Code gezielt auf Sicherheitsmängel — gezielt ist das entscheidende Wort, denn nebenbei passiert es nicht. Und Architekturentscheidungen werden mit ihren Sicherheitsauswirkungen dokumentiert, damit sie nachvollziehbar bleiben. Das gängige Format dafür ist der ADR, der Architecture Decision Record: eine halbe Seite, die festhält, was entschieden wurde, welche Alternativen es gab und warum.

5:17 Der Wert zeigt sich erst später — nämlich wenn in zwei Jahren jemand fragt, warum dieser Dienst eigentlich direkten Datenbankzugriff hat. Ohne ADR beginnt dann eine Archäologie-Sitzung. Mit ADR liest man eine halbe Seite. Vier Schritte für ein Review, das mehr ist als ein Häkchen. Erstens: sicherheitsrelevante Änderungen früh markieren — je früher, desto eher lässt sich noch etwas ändern.

5:40 Zweitens gegen Prinzipien und Bedrohungsmodell prüfen; damit haben Sie einen Maßstab statt eines Bauchgefühls, und genau deshalb war Kapitel 4 die Vorarbeit für diesen Schritt. Drittens die Entscheidung samt Sicherheitsabwägung dokumentieren. Und viertens, der Schritt, an dem es meist scheitert: Offene Punkte werden zu nachverfolgbaren Aufgaben.

6:00 Ein Satz zum "warum sicher" im ADR spart später viele Diskussionen — und schützt Sie davor, dieselbe Abwägung zweimal führen zu müssen. Drei Muster, die Reviews wirkungslos machen. Das erste: Reviews, die nur auf Funktion schauen. Das ist verständlich, denn "funktioniert es" ist leichter zu beantworten als "ist es sicher" — hilft aber nur gegen die eine Sorte Fehler.

6:23 Das zweite: mündlich getroffene Architekturentscheidungen. Sie sind nicht falsch, aber sie sind nach der nächsten Personalveränderung verschwunden. Und das dritte ist das frustrierendste: Sicherheits-Findings, die "zur Kenntnis genommen" werden und dann nirgends landen. Ein Fund ohne Ticket ist verlorene Arbeit — und schlimmer noch, er erzeugt beim nächsten Mal die Haltung, dass Reviews ja doch nichts bewirken.

Umgang mit Schwachstellen

6:47 Trotz allem wird etwas gefunden werden — im eigenen Code oder in einer Bibliothek. Die Frage ist dann nicht, ob man Fehler hat, sondern ob man einen Weg hat, mit ihnen umzugehen. Und dieser Weg entscheidet mehr über die tatsächliche Sicherheit eines Produkts, als die meisten vermuten. Teams, die Schwachstellen geordnet abarbeiten, sind am Ende besser dran als solche, die möglichst wenige finden wollen.

7:11 Der Umgang mit Schwachstellen ist ein geordneter Prozess: bewerten, priorisieren, beheben, nachhalten — mit klaren Zuständigkeiten und Fristen. Der Vergleich, der hier passt, ist die Notaufnahme. Dort wird nicht der Reihe nach behandelt, wer zuerst kam, sondern es gibt eine Triage: Wer ist in Gefahr, wer kann warten? Genau das brauchen Sie auch, denn die Zahl gemeldeter Schwachstellen übersteigt in jedem realen Projekt die Kapazität, sie alle sofort zu beheben.

7:38 Ohne Prozess entscheidet dann der Zufall oder die Lautstärke des Meldenden. Mit Prozess entscheidet das Risiko. Vier Schritte. Erst erfassen und reproduzieren — der Schritt wird gern übersprungen, kostet aber weniger als die Diskussion über einen Befund, den niemand nachstellen kann. Dann Schweregrad und Ausnutzbarkeit bewerten, klassisch mit CVSS als Orientierung.

8:00 Beachten Sie die Doppelung: Schwere allein reicht nicht, denn eine kritische Lücke in einem Codepfad, den Ihre Anwendung nie erreicht, ist ein anderes Problem als eine mittlere im offenen Endpunkt. Dann priorisieren und Fristen setzen. Und schließlich beheben, testen und per Regressionstest absichern. Der Satz in der Fußzeile verdient Beachtung: Bekannte, unbehobene Lücken sind ein Risiko, das man bewusst trägt — oder eben verdrängt.

8:27 In dieser Übung führen Sie eine Triage durch: vier Beispiel-Schwachstellen, eine begründete Reihenfolge, dazu je eine Frist-Kategorie — sofort, geplant oder beobachten. Nutzen Sie CVSS-Grundwerte als Orientierung, aber eben nur als das. Ein Wert sagt etwas über die Lücke an sich, nichts über Ihr System: Ist der betroffene Code überhaupt erreichbar? Steht davor eine weitere Schutzschicht?

8:50 Genau diese Einordnung ist Ihre Aufgabe und der Grund, warum die Priorisierung nicht automatisierbar ist. Achten Sie außerdem auf die Kategorie "beobachten" — sie ist eine legitime Entscheidung, solange sie dokumentiert und wiedervorgelegt wird.

Abhängigkeiten und Software Supply Chain

9:06 Kommen wir zu einem Thema, das in den letzten Jahren stark an Gewicht gewonnen hat. Der meiste Code, den Sie ausliefern, haben Sie nicht geschrieben — und Sie haften trotzdem dafür. Das ist keine neue Erkenntnis, aber die Angriffe auf Lieferketten haben in den vergangenen Jahren spürbar zugenommen, und die Gesetzgebung zieht gerade nach.

9:24 Umso wichtiger, den eigenen Umgang mit Abhängigkeiten einmal nüchtern anzuschauen. Die Software Supply Chain umfasst alle fremden Bausteine, die in Ihr Produkt einfließen: Bibliotheken, Container-Images, Build-Werkzeuge. Und der entscheidende Satz lautet: Ihre Schwachstellen werden zu Ihren Schwachstellen. Das Bild dafür ist die Lieferkette in der Lebensmittelindustrie — wer ein Fertiggericht verkauft, haftet für alle Zutaten, auch für die, die er nur zugekauft hat.

9:51 Für Ihre Kundschaft macht es keinen Unterschied, ob eine Lücke in Ihrem Code steckt oder in einer Bibliothek, die Sie eingebunden haben. Das Vertrauen richtet sich an Ihr Produkt, und damit auch die Verantwortung. Die Zahlen sind eindeutig: Der Großteil moderner Software ist fremder Code — in typischen Projekten stammen weit über achtzig Prozent aus Abhängigkeiten.

10:13 Damit verschiebt sich die Angriffsfläche, ohne dass jemand eine Entscheidung getroffen hätte. Der zweite Punkt: Kompromittierte Pakete verteilen Schadcode extrem breit; ein einziges manipuliertes Paket erreicht Tausende Projekte auf einmal, weshalb Angreifer dieses Vorgehen zunehmend bevorzugen — es skaliert. Und der dritte, unspektakulärste und häufigste Fall: ungepatchte Abhängigkeiten.

10:35 Keine raffinierte Attacke, sondern eine bekannte Lücke, für die es seit Monaten ein Update gibt, das niemand eingespielt hat. Zwei Arten, Abhängigkeiten zu installieren. Oben die alltägliche: Man nennt die Namen und bekommt, was die Registry gerade als aktuell ausliefert — beim nächsten Build womöglich etwas anderes. Unten dieselbe Installation, aber mit festgelegten Versionen und geprüften Prüfsummen.

10:59 Worauf es hier ankommt, ist das Prinzip: Sie wollen, dass Ihr Build reproduzierbar ist und dass eine unbemerkte Änderung im Paket auffällt. Ohne Pinning und Hash-Prüfung würden Sie eine Manipulation gar nicht bemerken. Die Fußzeile fasst die Praxis zusammen: pinnen, Hashes prüfen, eine Stückliste — die SBOM — führen und trotzdem regelmäßig aktualisieren.

11:20 Einfrieren allein ist keine Sicherheit, sondern nur Stillstand. Drei typische Fehler. Der erste: Pakete ungeprüft aus offenen Registries ziehen — jeder kann dort veröffentlichen, und Namen, die sich nur um einen Buchstaben unterscheiden, sind eine bekannte Masche. Der zweite: transitive Abhängigkeiten übersehen. Sie binden fünf Bibliotheken ein und bekommen zweihundert; die allermeisten hat nie jemand angesehen.

11:45 Und der dritte ist eine Falle, in die gerade gewissenhafte Teams tappen: Updates aus Angst vor Breaking Changes dauerhaft aufschieben. Das Problem verschwindet dadurch nicht, es wächst — irgendwann steht ein Sprung über fünf Hauptversionen an, und dann ist es wirklich riskant. Kleine, regelmäßige Updates sind unbequemer, aber sicherer.

12:06 Und damit zum Kerngedanken dieses Kapitels: Sicherheit altert. Nicht weil Ihr Code schlechter wird, sondern weil sich die Umgebung ändert — neue Angriffstechniken, neue Lücken in bekannten Bibliotheken, neue Anbindungen an Ihr System. Deshalb gehören Threat Model, Reviews und Patches in einen regelmäßigen Rhythmus, so wie Wartung eben ein Rhythmus ist.

12:26 Monitoring und Incident Response schließen den Kreis zum Betrieb: Sie merken überhaupt, dass etwas passiert, und Sie wissen, wer dann was tut. Und der letzte Punkt ist der wertvollste: Aus jedem Vorfall lernen. Ein Vorfall, der den Prozess verbessert, war wenigstens teuer bezahlte Erfahrung. Halten wir fest: Sicherheit ist in jeder Phase eine eigene Aktivität — kein Endabnahme-Schritt, den man einkaufen kann.

12:51 Reviews und dokumentierte Architekturentscheidungen machen sie nachvollziehbar und damit auch überprüfbar; ohne Dokumentation bleibt jede Abwägung im Kopf einer Person. Schwachstellen und Supply Chain brauchen geordnete, wiederkehrende Prozesse statt einzelner Kraftakte. Damit ist das Handwerkszeug vollständig. Was im letzten Kapitel folgt, ist der Transfer: Wie sich all das in typischen Anwendungsszenarien konkret niederschlägt — Web, API, Cloud, und die Fragen, die dort jeweils zuerst zu stellen sind.

Fragen & Ausblick

13:21 Kapitel 6 bringt den Transfer in typische Anwendungsszenarien — dorthin, wo Sie das Gelernte am Montag tatsächlich anwenden. In der Freigabe finden Sie die Checklisten und Vorlagen zu diesem Kapitel: die Phasenübersicht, eine ADR-Vorlage mit Sicherheitsabschnitt und ein einfaches Triage-Schema für Schwachstellen. Beides eignet sich gut, um im eigenen Team klein anzufangen — ein ADR ist schneller geschrieben, als die Diskussion darüber dauert.

13:48 Fragen jetzt gern, ansonsten erreichen Sie uns unter info@HCO.de.