Seite 4: Meilensteine für die Qualität

Inhaltsverzeichnis

Quality Gates in der Entwicklung helfen beim Prüfen der Einhaltung von Qualitätsanforderungen. Analog zur sogenannten Definition of Done (DoD), der teamweiten Definition davon, wann ein Task als erledigt gelten darf, sollten auch Quality Gates nicht ausschließlich in geduldiger Papierform vorliegen. Idealerweise sind automatisierte Checks in der CI-/CD-Pipeline integriert, beispielsweise durch statische Codeanalysen (SAST, Static Application Security Testing).

SonarQube als Plattform für statische Analysen und Qualitätsbewertungen erlaubt es, auf Projektebene unabhängige Quality Gates anzulegen, deren Einhaltung Teams über einen Build-Server wie Jenkins sicherstellen können.

Es kann für Entwickler jedoch sinnvoll sein, neben dem serverseitigen Feedback zusätzlich während des Programmierens Feedback zum Code zu erhalten. Dafür existieren einige sprach- und plattformabhängige IDE-Plug-ins und separate Codeanalyse-Tools wie Findbugs/Spotbugs, Checkstyles oder PMD. Falls SonarQube serverseitig zum Einsatz kommt, bietet sich SonarLint als IDE-Plug-in an, das den Abgleich der Client- und Serverseite vereinfacht.

Ein zusätzlicher vorgelagerter Prozess zum Überprüfen des Codes in der IDE verfolgt wiederum das Ziel, Entwickler bereits während der Entwicklung an Sicherheitsüberlegungen heranzuführen. Die Verbesserung der Codesicherheit tritt nicht nur an den durch das Plug-in identifizierten Stellen ein, sondern über den gesamten Code, weil Entwickler ein Security-Mindset erhalten. Als weiterer Nebeneffekt sinkt die Zahl der False Positives auf dem Buildserver. Letztere sind vor allem bei Security Quality Gates hoch, da Sicherheitsschwachstellen im Code oft kontextabhängig sind und eine manuelle Überprüfung erforden, womit eine enorme Erhöhung des Entwicklungsaufwandes verbunden sein kann.

Die Sicht der Angreifer

Evil User-Stories (auch Ab-User-Stories oder Bad User-Stories genannt) leiten sich aus den fachlichen User-Stories ab und dienen der Abbildung der gewünschten Funktionsweise aus der Sicht eines Angreifers. Analog zu User-Stories sind sie so konzipiert, dass ihr Fokus nicht auf der technischen Umsetzung liegt. Dementsprechend können Personen mit wenig technischem Hintergrund in der IT-Sicherheit durchaus die User-Stories verfassen. Das erhöht jedoch in der Folge den Aufwand für die Generierung von Tasks aus den gegebenenfalls zu unspezifischen (Evil) User-Stories.

Im Idealfall versuchen Evil User-Stories die Attack Surface abzubilden. Sie erlauben dem Entwicklerteam, identifizierte Angriffsvektoren in einem gewohnten Workflow abzuarbeiten. Dadurch schaffen sie ein Bewusstsein für potenzielle Angriffsvektoren, sind jedoch limitiert. Evil User-Stories sind einerseits durch das Wissen und die Erfahrungen ihrer jeweiligen Autoren und deren Vorstellungskraft begrenzt, andererseits durch die Fertigkeiten der Entwickler, den Angriffsvektor im Rahmen des Sprints abzuwehren. Dabei geht es nicht nur darum, ob die Entwickler die richtige Mitigationsstrategie entwickeln, sondern zusätzlich um das korrekte und umfassende Identifizieren des Use-Case im Code.

Die Evil-Varianten sind wie herkömmliche User-Stories nicht immer leicht zu schreiben. Insbesondere Teams, die wenig Erfahrung mit der Entwicklung sicherer Software haben, können beim Entwerfen sinnvoller Evil User-Stories auf Schwierigkeiten stoßen. Wenn ein SecM im Team vorhanden ist, sollte er die Aufgabe weitgehend übernehmen oder Hilfestellungen bieten. Teams ohne SecM sollten entweder externe Fachexpertise suchen oder ein strukturiertes Vorgehen zum Erstellen der Evil User-Stories planen. Dabei können die im Folgenden vorgestellten OWASP Cornucopia Cards helfen.

Methoden zur Evaluierung

Um Sicherheit als Prozess innerhalb der agilen Entwicklung zu etablieren, gilt es, regelmäßig Code Reviews mit Fokus auf das Sicherheitsniveau des Codes durchzuführen – und zwar sowohl komponentenweise als auch komponentenübergreifend. Idealerweise lassen sich einfach zu vermeidende Fehler, die Sicherheitsschwachstellen bedingen können, bereits im Rahmen der CI-/CD-Pipeline identifizieren und beheben – beispielsweise durch Quality Gates und automatisierte Tests. Die komponentenweise Überprüfung beschäftigt sich in diesem Fall primär mit der Untersuchung der Attack Surface der jeweiligen Komponente und der Mitigation von Angriffsvektoren. Ein Cheat Sheet zur Attack-Surface-Analyse findet sich im GitHub der OWASP Cheat Sheet Series.

Teams müssen die Attack Surface regelmäßig neu definieren, da sie sich mit jedem Sprint verändern kann. Die komponentenübergreifende Überprüfung dient analog zur Überwachung der Attack Surface des Gesamtprodukts, da sie sich ebenfalls mit jedem Sprint ändern kann. Schließlich ermöglicht erst eine komponentenübergreifende Sicht die Suche nach Angriffsvektoren, die sich durch Wechselwirkungen von Komponenten oder auch Abhängigkeiten ergeben.

Sofern keine SecMs vorhanden sind, lässt sich durch strukturiertes Vorgehen und gemeinsame Weiterbildung im Team eine Security Evaluation durchführen. Unter anderem die OWASP Cornucopia (s. Abb. 5) kann solch ein Vorgehen fördern. Bei der Cornucopia handelt es sich um ein Kartenspiel, das auf der Projektwebseite frei erhältlich ist. Spieler versuchen die auf den Karten vorgestellte Angriffsszenarien auf eine vom Team vorab ausgesuchte Domäne, Komponente – oder gegebenenfalls nur auf einzelne Methoden – der Codebasis anzuwenden. Das Team diskutiert schließlich, ob das Angriffsszenario der gespielten Karte denkbar ist. Im Fokus steht folglich die Identifikation der Angriffsvektoren, Mitigationsstrategien sollten aus zeitlichen Gründen an anderer Stelle diskutiert werden. Gewinner des Kartenspiels ist derjenige, der die meisten und schwierigsten Karten erfolgreich ausspielen konnte. Die Teams dokumentieren den Spielverlauf und die daraus resultierenden Sicherheitsanalysen.

Ein Vorteil der Cornucopia ist, dass sie das Bewusstsein für Codeschwachstellen im Team insgesamt erhöht. Zudem verbessert das Spiel das Fachwissen der Entwickler rund um das Thema IT-Sicherheit. Die Befähigung der Entwickler steht im Fokus und spiegelt somit agile Leitlinien wieder. Cornucopia-Sessions lassen sich hervorragend dazu nutzen, im Nachgang Evil User-Stories zu generieren.

Problematisch an den Cornucopia-Sessions ist, dass sie insbesondere unerfahrene Teams am Anfang mit einer steilen Lernkurve konfrontieren. Des Weiteren besteht die Gefahr, dass das Team einen potenziellen Angriffsvektor fälschlicherweise verwirft. Bei schlechter Vorbereitung wie zu großen Komponenten oder zu wenig Fachexpertise über mögliche Angriffsvektoren kann Cornucopia zeitlich ineffizient sein. Es empfiehlt sich daher insbesondere für die ersten Sitzungen, kleine, eigenständige Komponenten zu untersuchen und eventuell Sicherheitsexperten hinzuzuziehen.

Blick in die Fachliteratur

Literaturklassiker für Entwickler sind "Clean Code", "Clean Architecture" [3] und "Clean Coder" [8] von Robert C. Martin. Einige Teams lassen neue (Junior-)Entwickler Kurzvorträge über die einzelnen Kapitel der Bücher halten. Das sorgt einerseits dafür, dass Entwickler die als Pflichtlektüre gehandelten Werke tatsächlich lesen. Außerdem erhalten Alteingesessenen eine regelmäßige Auffrischung der Inhalte mit moderatem Zeitaufwand und die bestehende Codebasis wird reflektiert.

Die Suche nach Büchern, die sich praktisch mit der Entwicklung sicheren Codes befassen, gestaltete sich zwischenzeitlich schwierig. Bücher wie "Writing Secure Code" [4] und "Building Secure Software" [5] enthalten zwar tatsächlich praktische Tipps, stammen jedoch aus den frühen 2000ern. "24 Deadly Sins of Software Security" [9] aus dem Jahr 2009 bietet trotz seines Alters noch interessante Codebeispiele. Nach längerer Ankündigungsphase ist nunmehr "Secure by Design" [6], das seinen Fokus auf sauberes Design und Architekturen legt. "Agile Application Security" [7] beschreibt Ansätze zur Integration von Sicherheit in die agile Entwicklung. Bücher, die sich zum Erhalt der CISSP- oder CISM-Zertifizierung nutzen lassen, enthalten zwar oft Abschnitte über den "Secure Software Development Lifecycle", dürften für Entwickler jedoch im Allgemeinen zu oberflächlich gehalten sein. Wer im Web Development tätig ist, findet in "Security for Web Developers Using JavaScript, HTML, and CSS" [10] einen umfassenden Überblick.