Shift left security – Sicherheit ist Daily-Business

IT-Security ist ein Thema, das nicht ausschließlich InfoSec-Expert*innen angeht. Auch als Entwickler*in muss man diese Thematik auf dem Schirm haben. Security gehört zum grundlegenden Prozess der Softwareentwicklung und von Beginn an zum Daily-Business. Dieser Artikel erklärt, warum man das Thema frühzeitig ins Projekt integrieren sollte – shift left security.

Warum überhaupt Security?

TLDR; Weil es sonst richtig teuer wird.

Sicherheit ist ein wichtiger Aspekt der Softwareentwicklung. News über Data Breaches und Angriffe auf große Systeme sind alltäglich. Auch als kleine Applikation verschwindet man nicht unter dem Radar. Bestenfalls ist man Beifang eines sogenannten Scriptkiddie, im schlimmsten Fall ist man das nächste High-Prio-Target einer kriminellen Gemeinschaft oder Hacktivisten-Gruppe. Selbst wenn ein Stück Software nicht explizit Teil einer kritischen Infrastruktur ist – angesiedelt im Bereich des Gesundheits-, Finanz oder Versorgungswesens – haben die dahinter liegenden Ressourcen trotzdem einen (Geschäfts-)Wert, den es zu schützen gilt. Daten werden vorgehalten und verarbeitet, Prozesse werden gesteuert, Wertschöpfungsketten automatisiert. Wenn Angriffe, Missbrauch oder Fehlfunktionen die Software oder die enthaltenen Daten stören oder unbrauchbar machen, entsteht Schaden. Im besten Fall ist dieser Schaden nur monetärer Natur. Kommen gesetzlich regulierte Daten ins Spiel, zum Beispiel personenbezogene Daten, wird es deutlich kritischer – und damit auch deutlich teurer. Nicht zu vergessen ist der mögliche Image-Schaden. Also müssen wir etwas tun, um eine Anwendung gegen Schäden dieser Art zu schützen.

Ok, aber erst die Features. Danach ist immer noch Zeit für Security, nicht wahr?

Fokus von Projektverantwortlichen ist es, Features zu entwickeln. Man will ja schließlich „PS auf die Straße bekommen“. Nicht-funktionale Anforderungen wie IT-Security rutschen erstmal nach ganz unten auf der Prioritätenliste. Wenn man es vom ökonomischen Standpunkt her betrachtet, ist dieser Gedankengang vielleicht zunächst sogar nachvollziehbar. Features erzeugen direkten Wert, IT-Security blockiert hingegen in erster Linie augenscheinlich nur wertvolle Ressourcen und schützt gegen Schäden, „die vielleicht nie eintreten“. Somit entsteht häufig das Muster, dass erst einmal entwickelt und kurz vor Release über eine abschließende Sicherheitsprüfung nachgedacht wird.

Doch das ist leider eine sehr kurze Sicht auf die Dinge. Bitte nicht falsch verstehen, natürlich ist ein regelmäßiges Audit in Form eines professionellen Penetrationstests wichtig und empfohlen. Wenn dieser Pentest allerdings der erste Kontakt mit dem Thema Security ist und auch noch relativ spät in der Entwicklungsphase stattfindet, werden die Ergebnisse höchstwahrscheinlich zum unwillkommenen Augenöffner. Je nach Komplexität der Architektur werden plötzlich Dutzende ungeplanter To-dos in das Backlog gespült, die kurzfristig und überstürzt umgesetzt werden müssen – und nicht selten eine Überarbeitung von grundlegenden Komponenten oder der Architektur selbst zur Folge haben, wenn man sie richtig umsetzen möchte. Dies kann einem Produkt kurz vor Release einen herben Schlag – wenn nicht sogar den Todesstoß – versetzen.

Vom Testing lernen!

An dieser Stelle kann man Parallelen zum Software-Testing ziehen. Als die Softwareentwicklung noch jung und das Wasserfall-Entwicklungsmodell noch verbreitet war, wurde erst geplant, dann entwickelt und in der letzten Projektphase getestet – meistens manuell. Überraschenderweise wurde dann doch nochmal der ein oder andere Fehler gefunden und der Prozess begann wieder von vorn. Dies war ein kostspieliges Unterfangen. Ebenso ließ sich dieses Muster in der eigentlichen Entwicklungsphase wiederfinden. Zuerst werden die Features entwickelt, und falls dann noch Zeit ist, schreiben wir vielleicht noch einen (automatisierten) Test. Doch im Bereich des Software-Testings hat sich nach und nach das Test-driven Development (TDD) als gute Praktik etabliert. TDD ist eine Methode, mit der Code möglichst früh und kontinuierlich im Entwicklungsprozess getestet wird. Es wurde erkannt, dass frühzeitiges Testen hilft anstatt zu schaden, auch wenn es erstmal nach zusätzlichem Aufwand (ohne direkt erkennbaren Mehrwert) klingt. Techniken wie test first und fail fast helfen dabei, frühzeitig Feedback zu bekommen und somit zu erkennen ob man den richtigen Weg eingeschlagen hat.

Diese Erkenntnis kann man auch auf den Sicherheitsaspekt anwenden. Keine Frage, Sicherheit ist nicht kostenlos und bedeutet natürlich zusätzlichen Aufwand. Aber je früher man sich der (Un-)Sicherheit einer Software bewußt ist, desto eher (und kostengünstiger!) kann man diese Sicherheitslücken korrigieren. Im besten Fall entstehen diese gar nicht erst, wenn mögliche Patzer schon in der Designphase aufgedeckt werden. Je später Sicherheitslücken oder grobe Designfehler entdeckt werden, desto teurer wird es diese Fehler nachträglich wieder zu beheben.

Im Produktdesign spricht man von der Rule of 10. Das bedeutet, dass die Fehlerbehebungskosten mit jeder Phase, die ein Produkt von der Konzeption bis hin zur Inbetriebnahme fortschreitet, um den Faktor 10 steigen. Angewendet auf die Softwareentwicklung sieht das (mit fiktiven Zahlen) etwa wie folgt aus:

Auch wenn die Kosten für dieses Beispiel willkürlich gewählt sind, der Sinn dahinter wird klar. Fehler und somit auch Sicherheitslücken müssen möglichst frühzeitig gefunden und behandelt werden. Also schieben wir den Erstkontakt mit der Security auf der Zeitachse weitmöglichst nach links – shift left!

Ok, verstanden. Was kann ich in meinem Projekt tun?

Awareness schaffen!

Da wir nun ein Gefühl für die Wichtigkeit des Themas Security und auch für die Notwendigkeit, uns möglichst früh darum zu kümmern, entwickelt haben, ist es hilfreich, diesen Spirit auch im gesamten Projekt weiterzuverbreiten. Dabei müssen alle Projektbeteiligten mitziehen. Product Owner und Stakeholder (mit gegebenenfalls wenig technischem Background) müssen nicht zwangsweise jedes Detail verstehen, aber zumindest nachvollziehen können, warum IT-Security bzw. einzelne Maßnahmen wichtig und wertvoll sind. Wenn wir die Entscheider mit im Boot haben und das Verständnis auf allen Ebenen vorhanden ist, finden die Themen leichter einen Weg in den Alltag. Sind wir hingegen als Einzelkämpfer*innen unterwegs, kann es ein aussichtsloses Unterfangen werden. Hier hilft oft ein offenes Gespräch. Am Ende des Tages ist das Thema „Kosten“ ein überzeugendes Argument.

Threat modeling

Wenn nun allen Beteiligten klar ist, dass wir Security-Maßnahmen benötigen, wollen wir natürlich direkt mit der Realisierung loslegen. Es ergibt aber keinen Sinn, in blinden Aktionismus zu verfallen. Dies wäre mindestens eine Verschwendung von Ressourcen, im schlechtesten Fall ist dieser Ansatz sogar kontraproduktiv. Wenn wir nicht verstehen, was wir tun sollen, und nur anfangen, Security mit der Gießkanne in unserem System zu verteilen, machen wir unser Projekt damit unnötig komplex und den Build-Cycle unnötig langsam. Um herauszufinden, wo unsere wichtigsten Baustellen sind, hat sich das Threat Modeling etabliert. Hier haben sich verschiedene Techniken bewährt, wie STRIDE oder P.A.S.T.A und einige mehr, die sich in Details unterscheiden aber alle das gleiche Ziel verfolgen:

Priorität 1 ist es, zu ermitteln, wo sich die wertvollen Assets, also die Werte meiner Anwendung oder meines Prozesses befinden. Das können Dinge wie (Nutzer-)Daten, Informationen zu internen Prozessen, Zugangsdaten oder geistiges Eigentum jeglicher Form sein. Damit wissen wir, was zu beschützen ist. Wenn das geschehen ist, geht man dazu über, zu bestimmen, wer die potenziellen Angreifer*innen und deren (größten) Einfallstore sind, damit klar ist, woher die größten Bedrohungen kommen.

Mit den Informationen findet dann eine Bewertung (Kosten-Nutzen-Analyse) statt, indem der Wert der in Betracht gezogenen Assets dem Risiko eines Angriffs und dem erforderlichen Aufwand (sowohl Angriff als auch Verteidigung) entgegengestellt wird. Schlussendlich lassen sich dadurch die Maßnahmen ableiten und auch priorisieren, die nötig sind, um die Sicherheit des Projekts unter Berücksichtigung der Wirtschaftlichkeit zu verbessern.

Mit dieser priorisierten Liste können wir nun guten Gewissens zum Doing übergehen, ohne Ressourcen an die falschen Stellen zu binden.

Kenne die „üblichen Verdächtigen“

Jede Software ist individuell. Die dahinterliegenden Prozesse, die verwendeten Programmiersprachen, Build-Pipelines und Produktionsumgebungen unterscheiden sich. Daher gibt es auch keine allgemeingültige Anleitung zur Bekämpfung aller Schwachstellen und das macht das eben angesprochene Threat Modeling enorm wichtig.

Allerdings gibt es einige ständig wiederkehrende Probleme und auch passende Lösungsmuster, die man kennen sollte. Vom OWASP-Projekt wird beispielsweise regelmäßig eine Liste der am häufigst ausgenutzten Schwachstellen veröffentlicht.

Die OWASP Top 10 stellt allerdings keine umfassende Checkliste dar und ist sicher nur die Spitze des Eisbergs. Sie ersetzt keinesfalls das Threat Modeling und die konkrete Analyse des eigenen Projekts. Sie ist aber schonmal ein guter Startpunkt, um die wichtigsten Themen nicht zu übersehen. Beispielsweise findet man das Thema (SQL-)Injection seit Jahren ganz weit oben auf der Liste, was zeigt, dass diesen Schwachstellen trotz aller vermuteten Awareness weiterhin in einem Großteil der aktuellen Projekte existieren.

Sicherheitsaspekte in der Softwareentwicklung

Betrachtet man Software auf einem abstrakten Level formen sich Bereiche, die aus Security-Sicht interessant sind:

• Daten (sowohl während des Transports zum Nutzer oder bei der Kommunikation mit angeschlossenen Systemen als auch im Ruhezustand)
• Externe Abhängigkeiten (Sourcecode aus Bibliotheken und Frameworks)
• Eigener Sourcecode
• Prozesse und Organisation

Daten

Da die Welt der Umsysteme und Datenspeicher sehr heterogen ist und auch nicht unbedingt in unserem Einflussbereich als Entwickler*innen stehen, kann zu diesem Thema nur ein allgemeiner Ratschlag gegeben werden. Sowohl während des Transports als auch in persistenter Form müssen Daten verschlüsselt werden.

Für den Transport bieten sich hier die weitverbreiteten Spielarten des TLS (Transport Layer Security ) an. Somit können Daten während des Transports weder mitgelesen noch manipuliert werden.

Daten im Ruhezustand sollten ebenfalls nicht im Plaintext vorgehalten werden, erst recht nicht wenn es sich um sensible Daten (personenbezogene Daten, Passwörter etc.) handelt.

Hashing vs. Encryption

Sensitive Informationen können auf viele Arten vor unberechtigtem Zugriff geschützt werden. Zwei bekannte Arten sind innerhalb der Softwareentwicklung weit verbreitet: zum einen das Hashing und zum anderen die Verschlüsselung von Daten. Beide Praktiken haben ihr optimales Einsatzgebiet.

Passwörter werden in aller Regel gehasht, da Hashing eine Einweg-Funktion ist und es für den Server keinen Grund gibt, das Passwort wieder zu entschlüsseln und den wahren Wert hinter einem gehashten Passwort zu kennen. Beim Login werden vom Nutzer übergebene Passwörter ebenfalls gehasht und gegen den im System hinterlegten Hash abgeglichen.

Bewegungsdaten hingegen werden verschlüsselt. Da Verschlüsselung eine Zweiwege-Funktion ist, können diese Daten beim Zugriff wieder entschlüsselt werden.

Zusätzlich sollte noch erwähnt werden, dass für beide Methoden natürlich zum aktuellen Zeitpunkt als sicher geltende Algorithmen und ausreichend lange Schlüssel verwendet werden müssen.

Externe Abhängigkeiten

Nahezu jede größere Anwendung nutzt (Open-Source-)Bibliotheken. Diese Abhängigkeiten erleichtern natürlich die Erstellung eines neuen Produkts, indem man das Rad nicht neu erfinden muss und auf bereits implementierte Funktionalitäten zurückgreifen kann. Aber diese externen Bestandteile bringen potenziell auch Gefahren mit sich. Mit fremdem Quellcode kommen vielleicht auch neue Schwachstellen in unser System.

Prüfung auf bekannte Schwachstellen

Mit der Verwendung von externen Abhängigkeiten liegt die Verantwortung bei uns, diese Teile unseres Produktes auf Sicherheitskriterien zu prüfen. Möglicherweise gibt es für diese Artefakte einen oder mehrere öffentlich bekannte Schwachstellen – sogenannte CVEs – und im schlimmsten Fall erlauben wir mit deren Verwendung Angreifern mit Zugriff auf das entsprechende Tooling die bekannten Einfallstore mit den passenden Exploits per Mausklick zu öffnen.

Prüfungen der verwendeten Bibliotheken lassen sich auf verschiedene Arten realisieren. Für nahezu jede Programmiersprache gibt es hier die passenden Produkte und Adapter für Build Pipelines. Neben vielen, meist kostenpflichtigen „as-a-Service“-Lösungen ist hier aber auch unbedingt das OWASP-Dependency-Check-Projekt zu erwähnen.

Prüfung der verwendeten Lizenzen

Einerseits kann fremder Quellcode bekannte Sicherheitslücken enthalten und somit die Sicherheit unserer Anwendung gefährden, andererseits unterliegen eingebundene Bibliotheken möglicherweise Lizenzen, die Einfluss auf unser ausgeliefertes Produkt haben können. Die Palette an Softwarelizenzen ist riesig. Für nahezu jeden Anwendungsfall gibt es sicherlich eine passende Lizenz, doch den Überblick darüber zu behalten ist gar nicht so einfach. Um die für das eigene Projekt gewählte Lizenz dann auch verwenden zu können, dürfen die Lizenzen der verwendeten Fremdbibliotheken diesem Vorhaben natürlich nicht im Weg stehen. Schwachstellen-Analyse-Tools bieten daher auch häufig eine Prüfung der entsprechenden Lizenzen an.

Eigener Sourcecode

Bei der Erstellung von Sourcecode können mögliche Schwachstellen durch die Einhaltung einiger Prinzipien von Beginn an minimiert werden. Folgende Grundsätze können dabei helfen:

Design der Anwendung

Eine durchdachte Architektur ist das Fundament jeder Applikation. Was wie ein naheliegender und sehr allgemeiner Grundsatz klingt, um eine wartbare und verständliche Anwendung auf die Beine zu stellen, ist für das Thema IT-Sicherheit ebenso elementar. Ist Software gut strukturiert, können Sicherheitszonen einfacher verwaltet und die Anwendung kann „by Design“ besser abgesichert werden. Beispielsweise können Fachdomänen auf Datenbankebene bereits über Schemata und ein Rechte- und Rollenmanagement getrennt werden und der Zugriff kann mit dedizierten Nutzern erfolgen. Auf Pfad-Ebene können Zonen über HTTP-Security-Konfigurationen eingerichtet werden. Ein simples Beispiel wäre hier das Trennen von Adminfunktionen und der regulären Funktionen über dedizierte Routen.

Validierung von Input & Output – Injection vermeiden

Sowohl eingehende Informationen als auch die von uns weitergeleiteten Daten stellen ein Medium für potentielle Angreifer dar. Daher dürfen Daten nicht unkontrolliert prozessiert werden.

• Upstream-Eingaben immer als potenziell bösartig behandeln
• Einen eindeutigen Satz von Wahlmöglichkeiten (Dropdown/Enumeration) anstelle einer offenen Eingabe (Textfeld) anbieten
• Überprüfen, ob sich Eingabe/Ausgabe in einer erwarteten Range befindet
• Eingaben nur geprüft oder bereinigt nutzen/weiterleiten
• Prepared Statements bzw. ORMs für den Datenbankzugriff nutzen (niemals SQL-Statements per String-Verkettung zusammenbauen)
• Cross-Site Request Forgery verhindern (bspw. durch CSRF-Tokens)

Clients misstrauen

Alles, was von einem Client kommt (Browser, Skript, mobile App usw.), kann falsch oder bösartig sein. Daher muss jeder Client-Requests geprüft werden.

• Überprüfungen von Identität, Rollen und Rechten im Backend
• Mehrstufige Authentifizierung (2FA, MFA) oder passwortlose Verfahren (bspw. WebAuthN) verwenden
• Nur authentifizierte Benutzer zulassen
• Falls möglich, das Hochladen von Dateien generell vermeiden
• Überprüfen von Größe, Typ und Metadaten von Dateien (das Überprüfen von Inhalten ist schwierig. Hier ist ein besonderer Schutz vor Ressourcenerschöpfung nötig)
• Upload-Ziele festlegen (Pfad Traversierung durch Freitext-Eingabe vermeiden)
• Vermeiden von Ausführung hochgeladener Dateien (durch entsprechende Benutzerrechte)

Ressourcenerschöpfung verhindern

Auch wenn Daten zunächst syntakisch valide oder ungefährlich erscheinen, können Payloads unerwartet groß sein. Auch übermäßig viele (valide) Anfragen können ein System lahm legen („Denial of service“-Angriff).

• Deserialisierung von JSON, XML etc. mit Vorsicht genießen (XML Bombs)
• Falls möglich, aufwendige kryptografische Berechnungen vermeiden
• Das Hochladen von großen Dateien vermeiden
• Connection pooling für vom Client initiierte Verbindungen nutzen
• Das „proof of work“-Pattern anwenden, um große Berechnungen im Backend für den Client entsprechend aufwendig zu gestalten

Das Minimalprinzip leben

Rechte, Ressourcen und Informationen sollten immer nach dem Prinzip „So viel wie nötig, so wenig wie möglich“ zugeteilt werden.

• Benutzerrechte auf das Notwendige beschränken
• Nur notwendige Services oder Dienste aktivieren
• Keine internen Informationen preisgeben, die nicht für den aktuellen Anwendungsfall nötig sind
• Keine unnötigen (technischen) Daten in Fehlermeldungen herausgeben
• Bei einem fehlgeschlagenen Login keine Rückschlüsse auf existierende Accounts zulassen

Wartbaren Sourcecode schreiben

Quellcode wird viel häufiger gelesen als geschrieben. Code, der schlecht lesbar ist, ist auch schlecht wartbar und kann Sicherheitslücken verschleiern.

• Sourcecode sollte gut lesbar und (für andere Teammitglieder) leicht verständlich sein
• Klassen, Variablen und Methoden sollten beschreibende Namen haben
• Konventionen (Einrückungen, Leerzeilen usw.) automatisiert prüfen
• Explizite Klammersetzung kann zum Verständnis beitragen

Prozesse/Organisation

Sicheres Verwalten von Geheimnissen

Geheime Informationen sollten niemals in fremde Hände gelangen. Das gilt auch für Zugangsdaten zu unseren und zu anderen Systemen.

• Zugangsdaten (Token, Passwörter) niemals als Plaintext im Sourcecode/im Versionskontrollsystem hinterlegen
• Konfigurationen der Systeme sicher verwalten, bspw. in Vaults

User-Account-Management

Häufig wird vergessen, dass User-Accounts einen Lifecycle haben. Dies beinhaltet sowohl das Anlegen als auch das Löschen von Accounts.

• Das (rückstandslose) Löschen von Accounts ermöglichen
• Gesetzliche Regelungen beachten (DSGVO)

Intrusion Detection, Incident Response und Disaster Recovery

Nicht nur auf der Code-Ebene sollte das Thema Sicherheit präsent sein. Auch die umgebenden Prozesse müssen organisiert werden, falls es doch einmal zu einem Datenverlust kommt oder Systeme anderweitig kompromittiert werden. Zuerst muss überhaupt erkannt werden, dass das System Ziel eines Angriffs geworden ist. Und man sollte nicht erst dann darüber nachdenken müssen, was zu tun ist.

• Das System permanent auf Anomalien prüfen (Baselines für die wichtigsten KPIs ermitteln und überwachen)
• Prozesse und Meldeketten erstellen und dokumentieren
• Vergangene Vorfälle analysieren und daraus lernen
• “False positives” identifizieren
• Playbooks für verschiedene Szenarien anlegen (z. B.: Wie setze ich ein völlig neues System auf, wenn das alte unwiederbringlich verloren ist?)

Die wichtigsten Schritte sind hier (Reihenfolge ohne Wertung):

• Den aktuellen Angriff stoppen/die Schwachstelle schließen
• Die Ursache der Schwachstelle finden
• Die Geschäftsprozesse am Laufen halten
• Die Daten der Kunden schützen
• Angreifer identifizieren
• Zukünftige Angriffe gleicher Art vermeiden
• Gesetzliche Pflichten erfüllen (ggf. Meldepflicht)

Backups

Eines der Sicherheitsziele in der IT ist – neben Vertraulichkeit und Integrität – die Verfügbarkeit. Damit ist nicht nur die generelle Erreichbarkeit der Services gemeint, auch die fachgerechte Sicherung der Daten zahlt auf dieses Schutzziel ein. Deshalb ist es neben einer resilienten Applikation auch unverzichtbar, regelmäßige Backups der Daten zu erstellen. Welche Backup-Strategie für den eigenen Prozess ideal ist, muss von Fall zu Fall entschieden werden. Für manche Projekte ist sicher die Einfachheit der Verwaltung oder die Geschwindigkeit der Backup-Erstellung ein Kriterium, in anderen Anwendungsfällen ist vielleicht eher der verbrauchte Speicherplatz ausschlaggebend. Selbstverständlich müssen auch Backups verschlüsselt aufbewahrt werden.

Shift left security in meinem (agilen) Projekt

Awareness zu haben ist wichtig und ein guter Start. Jetzt stellt sich noch die Frage, wie wir Security in unser Tagesgeschäft integrieren. Hier ist das Schlüsselwort Regelmäßigkeit. Den Prozess einer Schwachstellenanalyse, Auswertung und Behebung der Findings einmalig durchgeführt zu haben, ist der Einstieg – aber leider nur von kurzzeitigem Wert. Im Laufe eines Projekts ändert sich häufig die Architektur der Systeme und die Menge der verwendeten Bibliotheken steigt. Auch konkrete Implementierungen werden angepasst. Mit jeder Zeile Code kommen mögliche neue Schwachstellen hinzu. Auch die Angreifer*innen lernen stetig dazu und entdecken neue Schwachstellen. Threat Modelings müssen regelmäßig durchgeführt werden und der Outcome muss immer wieder in unseren Backlog wandern. Die Form kann hierbei vielfältig sein, zum Beispiel können die Findings als reguläre Backlog-Items (z. B. „Endpunkt A muss mit einer Authentifizierung gesichert werden“) erfasst werden. Eine andere Möglichkeit sind auch sogenannte Evil User Stories. Das sind aus der Sicht eines Angreifers formulierte User Stories, die ungewollte Zustände oder aktuelle Sicherheitslücken beschreiben (z. B.: „Ich als User*in möchte nicht nur meine eigenen Daten, sondern auch die Daten aller anderen User*innen sehen und verändern können“). Einmal eingeplant, dürfen diese Stories nur in die Done-Spalte wandern, wenn diese Sicherheitslücke nicht mehr besteht. Wie man diese Themen platziert ist zweitrangig. Der wichtige Punkt ist, die sicherheitsrelevanten Prozesse in den Projektablauf (Secure Software Development Lifecycle) einzubinden. Wiederkehrende, professionelle Pentests gehören ebenfalls dazu.

Last but not least – für wen schreiben wir Software?

IT-Security ist eine wichtige, wenn nicht sogar die wichtigste nicht-funktionale Anforderung. Der (End-)Nutzer unseres Produkts darf aber hierbei natürlich auch nicht vergessen werden, hier sei der Trade-off „Security vs. Usability“ noch kurz erwähnt. Wenn Software durch Security Maßnahmen unbenutzbar wird, haben wir damit auch nichts gewonnen. Trotzdem müssen wir die Daten unserer Kunden schützen und hier einen praktikablen Mittelweg finden.

Takeaway

In welcher Form wir unsere Backlog-Items schreiben ist Nebensache. Wichtig ist, dass wir uns frühzeitig und regelmäßig mit dem Thema Security auseinandersetzen und dass der dazu nötige Aufwand in einem guten Kosten-Nutzen-Verhältnis zu unserem Projekt steht. Uns muss klar sein, dass Security zwar Aufwand bedeutet, aber notwendig und keine einmalige Sache ist. Wir spielen hier ein „endless game“.