Die Zeiten, in denen Software durch sogenannte Klick-Tester und Testerinnen getestet wurde, die sich anhand umfangreicher Testspezifikationen durch eine Anwendung klicken und vor allem Edge Cases – also Grenzfälle – mit extremen Parametern testen, sind längst vorbei. Software Testing hat sich inzwischen als eigenständige Disziplin innerhalb der Softwareentwicklung etabliert.
Das Testen von Edge Cases ist nicht mehr zeitgemäss. Situationen, in denen Security Testing eine riesige Rolle spielt, sind vielmehr Fälle, in denen Angriffsvektoren die Folge von unzureichendem agilem Mindset und manuellem Testing sind, nach denen z. B. Hacker und Hackerinnen suchen, um Schaden anzurichten. Wie Systeme angemessen vor solchen Angriffen geschützt werden können und wie uns neue Konzepte – wie DevSecOps und ein entsprechend angepasster Software Development Life Cycle (SDLC) – helfen können, sind Themen dieses Artikels. DevSecOps bedeutet dabei, dass Sicherheit ein essenzieller Bestandteil der Softwareentwicklung ist – von der ersten Zeile Code bis zum ausgelieferten Produkt.
Ein Gegenentwurf ist u. a. Scrum. Ein agiler SDLC mit der Möglichkeit, auf äussere Umstände schnell und flexibel reagieren zu können, ist die Grundlage dafür, dass sichere Software entwickelt werden kann. So können wir sagen: „Security? That’s baked in!“
Änderung des Mindsets
Automatisierung von Prozessen ist dabei aber nur EIN Pfeiler, der den SDLC trägt. Um DevSecOps zu kultivieren, braucht es jedoch noch mehr als diesen einen Pfeiler. Es braucht auch eine Änderung des Mindsets, um sich mit neuen Ideen auseinanderzusetzen und sie zum Teil eines ständigen Lernprozesses zu machen. Ziel ist eine stetige und inkrementelle Verbesserung mit der Bereitschaft zu experimentieren.
Dabei kann Acceptance Test-Driven Development (ATDD) helfen. ATDD ist eine Erweiterung agiler Methoden, die auf dem sog. Test-Driven Development (TDD) basieren, dass erstmals von Kent Beck im Jahr 2023 eingeführt wurde. Das Prinzip besteht hier darin, zuerst Testfälle für ein Problem zu definieren sowie zu schreiben und anhand dieser dann eine Lösung zu implementieren, wobei zunächst egal ist, ob es dabei um Sicherheit geht oder nicht. Im ATDD spezifizieren Product Owner Akzeptanztestfälle, anhand derer die Entwickler und Entwicklerinnen ihren Code schreiben können. Im Vergleich zum ATDD wird die Dimension des TDD, welches die Entwickler und Entwicklerinnen auf Basis von Unit Tests (Tests auf der tiefsten Code-Ebene) verwenden, also um Akzeptanztests erweitert. Diese Tests können z. B. in Gherkin spezifiziert werden. Gherkin ist eine Programmiersprache, mit der im Rahmen des ATDD Testfälle für das Testtool Cucumber geschrieben werden können. Cucumber ermöglicht u. a. eine automatische Ausführung von Testfällen – im Browser, aber auch auf mobilen Geräten. In der Theorie kann ATDD die Grundlage für den Drei-Amigo-Ansatz sein. Einem Konzept, bei dem sich drei Kollegen und Koleginnen mit unterschiedlichen Sichten, z. B. Business-Analysten und -Analystinnen, Entwickler und Entwicklerinnen und Tester und Testerinnen gemeinsam während des Entwicklungsprozesses treffen und Anforderungen durchsprechen, um früh Unklarheiten zu beseitigen, die im Verlauf des SDLC auch zu Sicherheitsrisiken führen könnten.
Der Werkzeugkasten mit den Tiny Tools für Retrospektiven
Wie bereits erwähnt besteht eine moderne DevSecOps-Strategie, welche die Sicherheit von Software im Fokus hat, nicht nur aus technischen Lösungen. Technisch wären hier z. B. automatisierte Tests wie ein OWASP Top 10 Check zu nennen, der die 10 grössten Bedrohungen für eine Software automatisiert prüfen kann und herausfindet, ob der Quellcode dahingehend Schwachstellen aufweist. Eine soziale Lösung, die auf Mindset-Level zur Verbesserung der Security beitragen kann, sind Retrospektiven. Sie sind ein entscheidender Teil agiler Vorgehensmodelle und lassen sich mit einem ganzen Werkzeugkasten an Methoden nutzen, die den Aspekt von DevSecOps stärken können. In Retrospektiven denkt das agil arbeitende Team darüber nach, wie sich Prozesse optimieren lassen, es kann darüber gesprochen werden, warum manche Sprints auch gegen die Wand gefahren sind und was das Team daraus lernen sollte.
Um dieses agile Mindset zu stärken, gibt es z. B. einen Werkzeugkasten mit Tiny Tools, also kleinen und kompakten Werkzeugen, die das Team in seinen Retrospektiven unterstützen kann. Sie kommen ursprünglich aus der Entwicklungszusammenarbeit, früher bekannt als Entwicklungshilfe in Ländern des sog. Globalen Südens. Die Life Line / Qualitity of Life Curve untersucht dabei z. B., wie sich die Qualitätssicherung in einem Team über einen Zeitraum entwickelt hat und was daraus gelernt werden kann. Hier werden Teammitglieder gefragt, wie sie die Entwicklung der Qualitätssicherung subjektiv wahrnehmen. Dabei können Ereignisse mit einem besonderen Impact als Startpunkt betrachtet werden, z. B. schwere Fehler. Die Teilnehmenden der Retrospektive können hier sowohl positive als auch für sie sehr negative Ereignisse auflisten. Mit Hilfe einer Lebenslinie werden dann die Ereignisse des gewählten Zeitraums bewertet, wobei eine Kurve, die hoch ausschlägt, als positiv, eine niedrig ausschlagende Kurve als negativ bewertet wird.
Tests strategisch besser planen
Road-Journey-Diagramme helfen, die individuellen Ziele einer Gruppe zu identifizieren und zu sehen, wie die aktuellen Entwicklungen damit zusammenpassen. Die Teammitglieder malen eine Roadmap, um die Veränderungen im Team über einen Zeitverlauf zu beschreiben. Dieser Weg kann gerade oder kurvig sein, auch bergauf und abwärts führen. Dabei können Symbole, wie Brücken oder andere Schlüsselelemente, verwendet werden. Eine Road Journey ist hilfreich, um den Test strategisch besser zu planen.
Wirkungsgefüge werden verwendet, um zu sehen, welche Einflüsse in einem Projekt vorhanden sind und zu bestimmten Wirkungen geführt haben. Das Team kann festhalten, welche Veränderungen zu beobachten sind, Gründe ableiten, warum diese Veränderungen da sind, und diese so durch die Fragen: Wieso? Warum? Weshalb? identifizieren. Wirkungsgefüge sind besonders effizient in Planungsphasen und in Situationsanalysen, wenn Probleme aufgetreten sind und das Team sich wünscht, die Ursache und die Entstehung des „Unfalls“ zu rekonstruieren.
Abbildung 1: Wirkungsgefüge
Eine Beteiligtenanalyse ist ein Tool, um alle Interessensgruppen in einem Ökosystem zu identifizieren, sowie Ziele und Probleme der Akteure und Akteurinnen zu erkennen. In einer Analyse muss auf die Frage Wert gelegt werden, welche Gruppe innerhalb eines Projektes von einer verbesserten DevSecOps-Strategie profitieren würde. Dieses Tool kann gut für die Entwicklung einer solchen Strategie verwendet werden, bevor sie offiziell vorgestellt wird, da sich so besser erkennen lässt, welche Herausforderungen entstehen könnten.
Proportional Piling wird vor allem verwendet, um Quantitäten zu erkennen. In einem Softwareprojekt kann dies bedeuten, dass die unterschiedlichen Einflüsse von anderen Teams auf das Projekt dargestellt und qualitative Quantitäten ermittelt werden, durch welche die Teams beeinflusst werden. Bei der Selbsteinschätzung werden Leitfragen zur Selbstevaluation gestellt. Je höher die Einschätzung, je höher das Piling. Konkret kann diese Methodik in einem Projekt verwendet werden, um zu ermitteln, welchen Impact eine Massnahme innerhalb des Projektes hatte.
Mit Automatisierung einen entscheidenden Pfeiler für ein Quality Gate bauen
Um die Mindset-Veränderung durch die Tiny Tools zu stärken, bildet die Automatisierung den zweiten Grundpfeiler einer DevSecOps-Strategie. Automatisierung ist ein sehr weites Feld. Es gibt Test-Frameworks, die für End-to-End-Testing (E2E) ausgelegt sind, und andere, die auf das Testen von REST-Schnittstellen spezialisiert sind. REST-Schnittstellen beschreiben die Kommunikation in einer Webanwendung auf Netzwerkebene. Es gibt auch Testing Frameworks, die beides leisten.
Playwright ist ein Test-Framework, es wurde 2020 entwickelt und ist damit noch recht jung. Es wurde von Microsoft entworfen und ist speziell für E2E-Testing ausgelegt, wobei bei Bedarf auch REST-Schnittstellen angesteuert werden können; für Cypress, das schon lange etablierte dominierende Framework, stellt es eine echte Herausforderung dar.
Playwright bringt einige Features für den Drei-Amigos-Ansatz mit; es kann auch mit Gherkin arbeiten, so dass das Team aus Business-Analysten und Analystinnen, Entwickler und Entwicklerinnen und Tester und Testerinnen den ATDD-Ansatz direkt anwenden kann. Zudem bietet es die Möglichkeit, E2E-Tests mit einem Tool-Testcode automatisch zu generieren, indem Nutzer und Nutzerinnen wie manuelle Tester und Testerinnen durch die Anwendung klicken, nur mit dem Unterschied, dass dabei Quelltext entsteht, der im Projekt hinterlegt und mit Gherkin gelinkt werden kann.
Da Playwright headless (d. h. ohne das Öffnen eines Browsers) in einer Build Pipeline wie Jenkins verwendet werden kann, kann man umfangreiche E2E-Tests durchführen, bevor die Software endgültig gebaut wird. In der Pipeline können auch direkt die Verwundbarkeiten der Software mit dem OWASP Top 10 Dependency Check überprüft werden.
Durch ein sicheres Tor in die Welt hinaus …
Um die Pfeiler Mindset und Automatisierung zu verbinden, wird ein Eckstein benötigt, mit dem ein Tor, oder auch ein Quality-Gate gebaut werden kann. In seinem Talk bei der GDC 2023 hat Seth Coster ein Modell für stressfreie Spieleentwicklung vorgestellt, von der die gesamte IT-Branche lernen kann. Das Vorgehen beruht auf einem SDLC, der auf Lernen und Feedbackschleifen basiert.
Abbildung 2: Geänderter SDLC
Das Konzept setzt vor allem auf die Beseitigung von Abfall, der z. B. durch manuelle Arbeiten und Moving Targets innerhalb des SDLC entsteht, die diesen in Schleifen durchlaufen und so Bottlenecks im Projekt verstopfen. Um das zu vermeiden, ist es entscheidend, Arbeitspakete immer in einer Richtung von der Entwicklung über Operations zum Kunden fliessen und diese sich gegenseitig Feedback geben zu lassen, ohne dabei Extraschleifen zu drehen.
In unserem Modell, das Retrospektiven mit den Tiny Tools nutzt und auf eine technische Lösung in Form von Automatisierung – in diesem Artikel mit Hilfe von Playwright und den OWASP Top 10 Dependency Checks – in einer Build Pipeline setzen, entsteht ein echtes Quality Gate. Durch dieses kann Software sicher zu den Kundinnen und Kunden geliefert werden.
Sie möchten mehr darüber erfahren, wie unsere in|sure-Software Ihrem Unternehmen dabei hilft, die Herausforderungen der Digitalisierung zu meistern? Dann wenden sie sich gerne an unseren Experten Karsten Schmitt, Head of Business Development.