Immer mehr Software wird nach agilen Prozessen (z.B. Scrum) und in kleinen Iterationen (Sprints) sukzessive (weiter-)entwickelt. Dies hilft zwar dabei, Software schneller auf den Markt zu bringen und an neue Marktanforderungen anzupassen, stellt aber das Thema Sicherheit und Sicherheitstests vor eine große Herausforderung. Wenn sich Software regelmäßig, schnell und umfangreich ändert oder sie oft erweitert wird, wie kann man dann Sicherheitstests bzw. Penetrationstests in den Entwicklungsprozess integrieren? Wie kann man Sicherheit trotz steter Änderungen auf hohem Niveau halten? Wie oft sollte man testen und in welchem Umfang? Um diese Fragen zu klären, geben wir in diesem Blog-Artikel einen Überblick über das komplexe Thema „Sicherheitstests im agilen Software-Entwicklungsprozess“.

Vorgehensweise: Mischung aus vollständigen und inkrementellen Penetrationstests

Penetrationstests sind in der modernen Softwareentwicklung eine unabdingbare Maßnahme, um Sicherheitsrisiken für Systeme, Daten und Anwender vorzubeugen. Während nicht-agil entwickelte Software im Rahmen einer Art „Sicherheitsabnahmetest“ vor jedem größeren Release getestet werden kann und dies gut planbar ist, sieht es bei Continuous Delivery, also der regelmäßigen und häufigen Auslieferung neuer Iterationen, anders aus.

Bei agil entwickelter und ausgelieferter Software empfiehlt NSIDE einen gemischten Ansatz aus vollständigen und inkrementellen Penetrationstests. Das bedeutet:

  1. Wenn noch kein Penetrationstest durchgeführt wurde, sollte ein vollständiger Penetrationstestaller Softwarekomponenten durchgeführt werden.
  2. Wenn sich seit dem letzten Penetrationstest sehr viele oder fast alle Softwarekomponenten geändert haben oder wenn die Architektur einer Anwendung grundlegend geändert wurde, sollte erneut ein vollständiger Penetrationstestdurchgeführt werden
  3. Wenn innerhalb eines oder mehrerer Sprints, die in ein neues Deployment einfließen, nur bestimmte Komponenten neu entwickelt oder erweitert wurden, wird ein inkrementeller Penetrationstestdurchgeführt. Dieser betrachtet nur die neu entwickelten oder abgeänderten Komponenten. Ein inkrementeller Penetrationstest setzt aber voraus, dass zuvor bereits ein vollständiger Penetrationstest durchgeführt wurde, da sonst das Ergebnis nicht aussagekräftig ist.

Ebenfalls ergeben sich unterschiedliche Empfehlungen zur Vorgehensweise abhängig davon, ob vor einem großen bzw. dem ersten Release getestet werden soll, oder ob im Rahmen von Continuous Delivery regelmäßig getestet werden soll.

Penetrationstests vor dem ersten Release oder vor einem neuen Major Release

Auch wenn Software agil entwickelt wurde: Wenn zu einer größeren neueren Version ein Penetrationstest durchgeführt werden soll, sollte man wie mit „klassisch“ entwickelter Software umgehen: Es handelt sich um einen vollständigen Sicherheitsabnahmetest, der den Zustand, der live gehen soll, abprüft. Dieser sollte die gesamte neue Major-Version betrachten. Ausnahme ist, wenn die neue Major-Version wirklich nur an bestimmten Stellen Änderungen oder Erweiterungen aufweist – dann können diese separat geprüft werden. Vor dem allerersten öffentlichen Release einer Software sollte natürlich ein vollständiger Penetrationstest durchgeführt werden.

Penetrationstests nach dem ersten Release oder während Continuous Delivery

Im Rahmen von Continuous Delivery bzw. dem Ausliefern kleinerer Iterationen sollte primär auf inkrementelle Penetrationstests gesetzt werden. Voraussetzung ist natürlich wiederum, dass auf einen vergangenen vollständigen Penetrationstest aufgebaut werden kann.

Zeitliche Planung: Häufigkeit und Release-Synchronisierung

Eine wichtige Frage beim Thema Penetrationstests im agilen Entwicklungsprozess ist außerdem die zeitliche: Wann und wie oft soll getestet werden? Wichtig ist hierbei zu verstehen, dass man genügend Zeit zwischen Test und Release-Datum einplanen muss, damit die Entwickler alle gefundenen Sicherheitsprobleme beheben können. Gleichzeitig sollte man auch nicht zu viel Zeit zwischen Test und Release verstreichen lassen, da man sonst unwirtschaftlich handelt und eventuell nicht alle Funktionalität, die in den neuen Release fließt, mittesten lassen konnte.

Generell empfehlen wir bei größeren Releases (Major Releases), circa 4 Wochen Bearbeitungszeit zwischen Delivery/Deployment und Ende der Penetrationstests zu planen. Bei kleineren Releases bzw. bei Continuous Delivery/Continuous Deployment empfehlen wir mindestens eine, besser zwei Wochen zwischen Ende des Penetrationstests und dem Release.

An diesen zeitlichen Empfehlungen sieht man auch, wie oft ungefähr getestet werden sollte: Wöchentlich den jeweiligen Sprint zu testen ist nicht sinnvoll, da ansonsten zu oft und mit zu viel zeitlichem Abstand zwischen Test und Release gerechnet werden muss. Bei inkrementellen Tests empfehlen wir, mehrere Sprints zusammenzufassen.

Erfahrungswerte zur Testhäufigkeit in agiler Entwicklung

Aus unserer Erfahrung empfehlen sich je nach Projekt und Entwicklungsgeschwindigkeit folgende zeitliche Abstände für die Testtypen:

  • Vollständige Penetrationstests: Alle 6 bis 12 Monate
  • Inkrementelle Penetrationstests: Alle 3 bis 6 Monate; je größer der Zeitraum zwischen Inkrementierungen, desto umfangreicher wird auch der Penetrationstest

Sicherheit zwischen den Penetrationstests bei Continuous Delivery/Continuous Deployment

Zusätzlich zu Penetrationstests sollte im Falle von häufigen, kleinen Auslieferungen auch automatisiertes Sicherheitstesten in die CI/CD-Pipeline integriert werden. Hier gibt es verschiedene automatisierte Sicherheitstools, die man integrieren sollte, zum Beispiel:

  • SAST-Tools (Static Application Security Testing Tools)
  • Secrets-, Entropie- und Key-Scanner
  • Dependency-Checker
  • automatisierte Sicherheits-Scans
  • ggfs. Fuzzing

Abschluss

Penetrationstests in der agilen Softwareentwicklung sind eine Abwägung, ein sogenannter Trade-Off. Permanente, tägliche oder wöchentliche Tests sind nicht wirtschaftlich oder sinnvoll. Daher möchten wir abschließend noch ein paar Leitsätze mit auf den Weg geben:

  • So spät wie möglich, so früh wie nötig testen. Heißt: So viel Zeit wie nötig für Behebungen (Fixes) lassen, aber so viel Code wie möglich in den Test mit aufnehmen.
  • Das testen, was sich ändert; das, was gleic bleibt, ignorieren.
  • Nicht zu oft testen, sonst wird es unwirtschaftlich; nicht zu selten testen, sonst wird die Software unsicher.

Sie brauchen Unterstützung bei Penetrationstests bei Ihrer Softwareentwicklung? Sie wünschen Unterstützung beim Aufbau automatisierter Sicherheitstests für Ihre CI/CD-Pipeline? Melden Sie sich gerne bei uns!