Interview mit Stephan Kaps

„Wer Software kontinuierlich ausliefern will, muss auch kontinuierlich testen“

Redaktion JAXenter

Stephan Kaps

Continuous Delivery ist in aller Munde – und das zu Recht, bietet es doch ganz neue Möglichkeiten, agil auf Änderungen am Markt zu reagieren. Will man allerdings qualitativ hochwertige Software kontinuierlich ausliefern, müssen auch kontinuierlich Sicherheitstests durchgeführt werden. Wir haben uns mit Stephan Kaps, Softwarearchitekt und Sprecher auf der DevOpsCon, über die Herausforderungen unterhalten, die Security Tests in CD-Szenarien mit sich bringen.

JAXenter: Continuous Delivery klingt erst mal super, sowohl für den Kunden, der immer auf dem neusten Stand ist, als auch für die Entwickler, die so greifbare Etappenziele haben. Welche Herausforderungen erwarten aber einen Tester?

Stephan Kaps: Automate everything. Bei sehr vielen Auslieferungen in der Woche oder sogar am Tag, ist keine Zeit mehr für manuelles exploratives Testen. Alles was getestet werden soll, muss automatisiert werden: Unit-Tests, Integrations-Tests, UI-Tests, Performance-Tests und eben auch Security-Tests.

Früher wurden Anwendungen entwickelt und im Anschluss getestet. Penetrationstests fanden kurz vor Produktionsaufnahme statt und haben ein Release um Tage oder Wochen verzögert. Die Herausforderung ist nun, Sicherheits-Checks deutlich früher und regelmäßig im Entwicklungsprozess durchzuführen.

JAXenter: Du sprichst in deiner Session von “Continuous Security Testing”. Müssen hier Entwickler und Tester noch enger zusammenarbeiten? Wie läuft das bei dir im Unternehmen dann ab?

Bei Continuous Delivery müssen Entwickler sich mehr mit Testen beschäftigen.

Stephan Kaps: Ja. Grundsätzlich müssen bei Continuous Delivery die Tester ein wenig programmieren lernen und die Entwickler sich mehr mit Testen beschäftigen. Ich habe gute Erfahrungen mit Behaviour Driven Development gemacht. Das Business und die Tester verstehen die Spezifikation und können sie am besten auch selbst formulieren. Die Entwickler können diese Akzeptanzkriterien 1:1 mit Testklassen bzw. Methoden versehen.

Für den in meinem Talk vorgestellten speziellen Fall müssen auch Security-Experten hinzukommen. So sind wir auch vorgegangen. Ich habe mich mit einem Sicherheitsexperten zusammengetan, und wir haben gemeinsam bekannte Verwundbarkeiten, Risiken, Attacken und Schwachstellen diskutiert. Daraufhin haben wir 10 für uns relevante Regeln formuliert und Kurzanleitungen zur Behebung aufgestellt. Zudem haben wir automatisierte Prüfungen in den Build-Prozess integriert und die Entwickler sensibilisiert.

DevOps Docker Camp 2017

Das neue DevOps Docker Camp – mit Erkan Yanar

Lernen Sie die Konzepte von Docker und die darauf aufbauende Infrastrukturen umfassend kennen. Bauen Sie Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf!

JAXenter: Welche Tools helfen euch bei der Umsetzung dieser Ziele?

Tools spielen eine ganz entscheidende Rolle. Wir verwenden ausschließlich OpenSource-Tools. Begonnen haben wir mit statischen Analysen. Dabei sind Werkzeuge wie FindSecurityBugs oder der Dependency Check von OWASP einfache aber wertvolle Helfer. Für dynamische Analysen setze ich auf den Zed Attack Proxy von OWASP. Es gibt aber einige Alternativen wie den Arachni Scanner.

JAXenter: Jede Umstellung ist erst mal schwer: Konnte man früher länger in die Zukunft planen, kommt mit CD deutlich mehr Tempo in den Entwicklungsprozess. Welche Umstellung ist dir persönlich am schwersten gefallen?

Es war schwierig, Fachbereiche und IT-Betrieb von Continuous Delivery zu überzeugen.

Schwer gefallen ist mir dabei ehrlich gesagt gar nichts, denn es fühlte sich immer alles logisch und sinnvoll an. Länger in die Zukunft planen hat bisher ohnehin meist nicht funktioniert.

Es war natürlich teilweise schwierig, Fachbereiche und den IT-Betrieb von diesem Vorgehen zu überzeugen und in den notwendigen Flow zu kommen.

JAXenter: Und für welchen Vorteil von CD bist du besonders dankbar?

Für die schmerzfreien Releases, unabhängig von z.B. der Verfügbarkeit von bestimmten Personen. In Kombination mit Feature Toggles hat man z.B. die Möglichkeit, zu beliebiger Zeit ein neues Feature zugänglich zu machen. Wenn gewollt auch erst für einen Bruchteil der User. Der Code ist ohnehin schon in der Produktion, intensiv automatisiert getestet.

Ein großer positiver Nebeneffekt ist, dass man sich deutlich mehr Gedanken zur Architektur eines Systems machen muss, um Continuous Delivery zu ermöglichen. Modularität, Testbarkeit, Robustheit, Wartbarkeit, Zero Downtime und vieles mehr haben inzwischen einen viel höheren Stellenwert und eine große Bedeutung beim Design von Anwendungen, die regelmäßig ausgeliefert werden sollen.

JAXenter: Was ist die Kernbotschaft deiner Session? Was sollte jeder Besucher mit nach Hause nehmen? 

Meine Session beantwortet die Fragen:

  • Wie startet man ein Secure-Coding-Projekt?
  • Wie beginnt man mit Security Testing?
  • Was sind geeignete Tools?
  • An was muss man noch alles denken?

Und die Kernbotschaft ist:

Nur wenn sich Security Testing nahtlos in den Entwicklungs-Workflow integriert, indem Security Bugs genauso aufgespürt, verwaltet und behoben werden wie andere Bugs, dann wird dieses Instrument auch von Entwicklern akzeptiert und die Art und Weise, wie sichere Software entwickelt wird, positiv beeinflusst.

JAXenter: Vielen Dank für dieses Interview!

Hu_3YQlUStephan Kaps arbeitet als Softwarearchitekt, Entwickler und technischer Projektleiter. Weitere Schwerpunkte liegen in der Konzipierung und Optimierung von Softwareentwicklungsprozessen (Continuous Delivery), dem Application Lifecycle Management und BizDevOps. Zudem hat er langjährige Erfahrung als Java- und Hostentwickler. Seine Leidenschaft sind neue Technologien und Methoden.
Geschrieben von
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.