Automatisiertes Software Security-Testing

Transkript

1 ERFA-Tagung Automatisiertes Software Security-Testing Prof. Dr. Marc Rennhard Institut für angewandte Informationstechnologie InIT ZHAW Zürcher Hochschule für Angewandte Wissenschaften Dr. Ralf Hauser CEO PrivaSphere AG Marc Rennhard, , ERFA_ASTF.pptx 1

2 Inhalt und Ziele Inhalt Motivation für das Projekt, Ziele Projektablauf Grundlegender Ansatz des entwickelten Testing-Frameworks Einsatz des Testing-Frameworks Entwicklungen der jüngeren Zeit Integrierte Testing-Tools Demonstration Zusammenfassung Ziele Sie erhalten einen Einblick in das von uns entwickelte Testing-Framework Sie erkennen den Mehrwert des Frameworks Marc Rennhard, , ERFA_ASTF.pptx 2

3 Über PrivaSphere AG Erster Schweizer Anbieter einer öffentlichen sicheren Mailplattform Zehntausende Benutzer von Finanzdienstleister und öffentlichen Verwaltungen, sowie Gesundheitsbehörden und mittelständische Betriebe Ausgedehntes Technologie-, Integrations- und Distributionspartnernetzwerk und technische Zusammenarbeit mit ETH und Hochschulen Aktionariat: mehrheitlich Management - weitere Aktionäre: z.b. Hasler Stiftung Mezzanine-Darlehen der ZKB für Startup-Phase - 100% getilgt, bankenunabhängig Ausgezeichnet mit CTI Startup Label im 2004 und Preisträger des Swiss Technology Awards ISO27001 Zertifizierung Einzige offizielle Zustellplattformtechnologie anerkannt für die Bundesverwaltung Marc Rennhard, , ERFA_ASTF.pptx 3

4 Motivation für das Projekt Online-Applikationen haben oft restriktive Sicherheitsanforderungen Unterstützung im SWE-Prozess durch entsprechende automatisierte Security-Testing-Tools ist nur limitiert vorhanden Diverse Tools existieren, sind aber heterogen in der Benutzung Aufruf erfolgt meist manuell nach Bedarf keine Kontinuität Tools sind meist nicht integriert in den SWE-Prozess Resultierende Probleme: Sicherheitskritische Komponenten werden unregelmässig, ungenügend (Regressionen) oder mit hohem personellem Aufwand getestet Mangelhafte Softwarequalität/-sicherheit oder hohe Kosten für den Hersteller der Applikation Das Problem verstärkt sich bei Applikationen, die ständig weiterentwickelt werden (kurze Release Zyklen, Continuous Build ) Marc Rennhard, , ERFA_ASTF.pptx 4

5 Projektziele Primäres Ziel: Entwicklung eines Testing-Frameworks, mit welchem die Softwarequalität/-sicherheit erhöht werden kann Erlaubt es, Online-Applikationen weitgehend automatisiert bezüglich ihrer Sicherheit zu testen Automatisiert = Durchführbarkeit ohne menschliche Interaktion und eindeutige Reproduzierbarkeit Framework integriert mehrere Security Testing-Tools und soll deren einheitliche Benutzung in versch. SWE-Projekten ermöglichen Testing-Framework soll in den SWE-Prozess integriert sein: Qualitätskontrolle, Benachrichtigung von Entwicklern... Ergebnis: Automated Security Testing Framework (ASTF) Marc Rennhard, , ERFA_ASTF.pptx 5

6 Beitrag von ASTF über den State-of-the-Art hinaus Integration von bestehenden Software- und Security-Testing-Tools, die sehr heterogen bezüglich Bedienung und generiertem Output sind, in einem Framework Bedienung und Darstellung im Framework sind weitgehend einheitlich Verfolgung des Qualitätsverlaufs von Softwareprojekten über die Zeit und Setzen von realistischen Zielen Ziele können jederzeit gesetzt und angepasst werden Analyse und Vergleich einer grossen Zahl von Testing-Tools das Framework integriert die wirklich guten und geeigneten Tools Entwicklung von neuartigen Security-Testing Tools bzw. verbessern von bestehenden Tools Marc Rennhard, , ERFA_ASTF.pptx 6

7 Projektablauf (1) 1. KTI-Projekt zwischen PrivaSphere und InIT (07/ /2008) Konzipierung und Entwicklung des Frameworks Analyse und Integration diverser Testing-Tools Eingesetzt von PrivaSphere im Rahmen der eigenen Softwareentwicklung Vorstellung an einzelne Interessenten Schlussfolgerungen: Proof-of-Concept, dass es funktioniert Diverse Firmen zeigten Interesse Aber auch Limitierungen / Erweiterungspotential Performance bei grossen Reports (z.b Nachrichten) Keine Möglichkeit, mehrere Scanner parallel zu integrieren Entwicklung eigener Testing-Tools bzw. Erweiterung bestehender Tools Marc Rennhard, , ERFA_ASTF.pptx 7

8 Projektablauf (2) 2. KTI-Projekt (Folgeprojekt) zwischen PrivaSphere und InIT (seit 11/2009) mit diversen Zielen: Professionalisierung des Frameworks (Usability, Stabilität) Bessere Skalierbarkeit (Verteilung auf mehrere Komponenten) Verbesserung der Performance Eigene Entwicklung von Testing-Tools (vor allem im Rahmen von Master- Studentenprojekten) Durchführen von Pilotprojekten mit Partnerfirmen Marc Rennhard, , ERFA_ASTF.pptx 8

9 ASTF Grundlegender Ansatz (1) Die grundlegenden Eigenschaften von ASTF wurden wie folgt definiert: ASTF baut auf bereits vorhandenen Testing Tools auf Wenn möglich Verwendung von Open-Source Testing-Tools Integration beliebiger Tools ist aber prinzipiell möglich PMD... Checkstyle JMeter ASTF Core FindBugs w3af Nmap OpenVAS Wieso Fokus auf Open-Source Testing-Tools? Vielzahl an mächtigen Tools bereits vorhanden Bei Bedarf sind Erweiterungen relativ einfach möglich Benutzung/Weitergabe von ASTF wird stark vereinfacht Marc Rennhard, , ERFA_ASTF.pptx 9

10 ASTF Grundlegender Ansatz (2) Der primäre Mehrwert von ASTF besteht in der Integration dieser heterogenen Tools, um diese als vereinigten Service anzubieten Einheitliche Verwendung der Testing-Tools im Rahmen eines Software- Entwicklungsprojekts Einheitliche Zuweisung der Tools zu einem Projekt Scheduling über die verschiedenen Testing-Tools Einheitliches Reporting über alle Testing-Tools Benutzerfreundliche Bedienung mittels Webinterface Management View, um einen schnellen Überblick über mehrere Projekte zu erhalten Testing-Tools erhalten eine sinnvolle Basiskonfiguration Diese sind im Rahmen von ASTF out-of-the-box einsetzbar Dies ist insbesondere bei Code-Analysis und Scanning Tools möglich Bei komplexeren Tests (z.b. sicherheitskritische Abläufe) müssen die entsprechenden Testcases mit den Testing-Tools selbst kreiert werden Marc Rennhard, , ERFA_ASTF.pptx 10

11 ASTF Grundlegender Ansatz (3) ASTF enthält eine detaillierte Reporting-Komponente, die auch zur Qualitätssicherung dient Generiert Reports, die über die gefundenen Fehler informieren Erlaubt das Browsen von Reports, um die Fehler schnell zu lokalisieren Erlaubt bei Source-Code Analysis-Tools das betrachten des fehlerverursachenden Code-Segments Ermöglicht die Verfolgung des Verlaufs des Outputs eines Testing-Tools über die Zeit (nehmen die Fehler z.b. zu oder ab) Versendet s an verantwortliche Personen/Entwickler, um unmittelbar nach den Tests über die Ergebnisse zu informieren Marc Rennhard, , ERFA_ASTF.pptx 11

12 ASTF Grundlegender Ansatz (4) ASTF soll als integraler Teil der Projektentwicklung eingesetzt werden Führt regelmässig Tests der Applikation durch (z.b. nightly) Kann bereits sehr früh in der Entwicklungsphase eingesetzt werden (mit Verwendung einiger weniger Testing-Tools) Kann dank dem Baseline-Konzept aber auch noch sehr spät in der Entwicklungsphase eingesetzt werden (graduelle Verbesserung dank Setzen von inkrementellen Zielen) Weitere Testing-Tools können jederzeit aktiviert werden Marc Rennhard, , ERFA_ASTF.pptx 12

13 ASTF Einsatz Marc Rennhard, , ERFA_ASTF.pptx 13

14 ASTF Einsatz (verteilt) Marc Rennhard, , ERFA_ASTF.pptx 14

15 ASTF Jüngste Entwicklungen (1) Detaillierte Analyse zu Beginn des 2. KTI-Projekts bezüglich der zu verwendenden Framework-Basis Wahl fiel auf Hudson ( Hudson ist ein continuous software building/testing tool Wieso Hudson? Es bietet gewisse Grundfunktionen, die in ASTF auch gefordert sind: Projektverwaltung, Testing-Tool-Verwaltung, Scheduling-Mechanismus Ist bereits verteilt einsetzbar Etabliertes, reifes Produkt; wird von vielen Unternehmen verwendet Open Source und erweiterbar Es wäre sehr viel Aufwand, das bestehende ASTF bezüglich dieser Grundfunktionen auf einen vergleichbaren Level wie Hudson zu bringen Aber: Die innovativen Ideen von ASTF waren in Hudson weitgehend nicht vorhanden Diesbezüglich musste/muss Hudson erweitert werden Marc Rennhard, , ERFA_ASTF.pptx 15

16 ASTF Jüngste Entwicklungen (2) Integration der bestehenden Testing-Tools in Hudson Ergebnisse eines Tests werden in einer Datenbank gespeichert deutlich bessere Performance bei der Darstellung der Ergebnisse Bis Ende September sollten alle Testing-Tools integriert sein Management View, um schnell eine konsolidierte Ansicht zu erhalten Ansicht ist für alle Projekte und Tools identisch Bedingt eine gewisse Normalisierung der Reports, z.b. auf einheitliche Prioritäten Weiterentwicklung des Baseline / Acceptance Criteria-Mechanismus Ermöglicht die Spezifikation des erwünschten Qualitätsverlauf, z.b. Keine High-Priority-Nachrichten sind erlaubt Innerhalb der nächsten 100 Tage möchte ich von 100 Meldungen auf höchstens 20 Meldungen kommen Erlaubt das Setzen von realistischen Zielen Marc Rennhard, , ERFA_ASTF.pptx 16

17 ASTF Jüngste Entwicklungen (3) Markieren von False Positives Einige der automatisierten Testing-Tools werden zwangsläufig False Positives (fälschlich gemeldete Fehler) melden Code analysis tools, Web application vulnerability scanner ASTF bietet die Möglichkeit, diese Nachrichten zu markieren Die gleichen False Positives werden in den folgenden Testläufen dann nicht mehr gemeldet und sie zählen auch nicht bei der Berechnung der Qualitätskriterien Erzeugung von Graphen, um den Qualitätsverlauf visuell darzustellen Auch im Vergleich zu den Acceptance Criteria Marc Rennhard, , ERFA_ASTF.pptx 17

18 ASTF Jüngste Entwicklungen (4) Analyse verfügbarer Code Analysis Tools Es gibt hunderte von Source Code Analysis Tools für ganz verschiedene Programmiersprachen ASTF sollte eine geeignete Auswahl davon integrieren Im Rahmen einer Master-Projektarbeit haben wir viele dieser Tools analysiert Fokus auf Open-Source Tools Decken die gängigen Web-Sprachen ab (Java, JavaScript, PHP, Ruby, ActionScript, Perl,.NET) Ergebnis: Nur sehr wenige (< 10) dieser Tools wurden als gut befunden Wir wissen jetzt, welche Tools sinnvollerweise integriert werden sollen Derzeitiger Fokus liegt auf Java, kann jederzeit erweitert werden Marc Rennhard, , ERFA_ASTF.pptx 18

19 ASTF Jüngste Entwicklungen (5) Entwicklung eines kombinierten Black-/White-Box Web Application Vulnerabiliy Scanners Web Application Security Testing Framework (WASTF) Motivation: Heute verwendete automatische Scanning-Tools verwenden praktisch immer einen reinen Black-Box Ansatz Dabei interagiert der Scanner mit der Applikation, hat aber keinen Zugriff auf Informationen wie Quell-Code oder interne Zustandsinformation Nur anhand der direkt sichtbaren Antwort einer Applikation ist es oft schwierig, eine Aussage über eine vorhandene Schwachstelle zu machen führt zu einer grossen Zahl von False Positives In einer Master-Projektarbeit haben wir überlegt, wie man diese Situation mit etwas mehr White-Box Information verbessern kann Daraus entstanden diverse Vorschläge, einen davon haben wir umgesetzt Marc Rennhard, , ERFA_ASTF.pptx 19

20 ASTF Jüngste Entwicklungen (6) Erste Version kann SQL Injection Vulnerabilities in Web Applikationen zuverlässiger und schneller detektieren als reine Black-Box Scanner Problem bei reinem Black-Box Ansatz: Unklar, welche gesendeten Werte überhaupt in einer DB-Query resultieren Erfolg einer Attacke ist anhand der Antwortseite kaum feststellbar Um dieses Problem zu lösen, verwendet WASTF das Database Query Log als White-Box Komponente Alle gängigen Datenbanken erzeugen ein Database Query Log Das Database Query Log ist eine Datei oder eine Tabelle, die alle SQL Statements enthält, welche von der Datenbank verarbeitet werden Marc Rennhard, , ERFA_ASTF.pptx 20

21 ASTF Jüngste Entwicklungen (7) Marc Rennhard, , ERFA_ASTF.pptx 21

22 ASTF Jüngste Entwicklungen (8) WASTF läuft nun mehrstufig ab: Die Webapplikation wird gecrawlt, um alle Möglichkeiten für Benutzereingaben (GET/POST Parameter) zu finden Bei allen Parametern wird nun ein bestimmter Wert gesendet und im Query Log wird nachgeschaut, welche Parameter in einer Query resultieren nur diese Parameter werden weiterverfolgt Anschliessend werden in SQL Injection Attacken typischerweise verwendete Strings gesendet, z.b. ', ", SELECT etc. Eine weitere Inspektion des Query Logs zeigt uns, welche Zeichen bei welchen Parametern zugelassen sind Je nach zugelassenen Zeichen können wir für einzelne Parameter SQL Injection Strings konstruieren entspricht einer Schwachstelle Marc Rennhard, , ERFA_ASTF.pptx 22

23 ASTF Jüngste Entwicklungen (9) Die ersten Ergebnisse sind sehr positiv, WASTF ist: Schneller ist als reine Black-Box Scanner und......ermöglicht präzisere Aussagen (mehr gefundene Schwachstellen, weniger False Positives) Der grundlegende Ansatz lässt sich vermutlich auf weitere Arten von Schwachstellen ausweiten Folgearbeit ist wahrscheinlich Marc Rennhard, , ERFA_ASTF.pptx 23

24 ASTF Jüngste Entwicklungen (10) Entwicklung eines Black-Box Fuzzers (im Rahmen von zwei Master- Studentenarbeiten), als Plugin in w3af Das Ziel ist es, die Robustheit einer Webapplikation zu testen Der entwickelte Fuzzer ist flexibler als verfügbare Fuzzer und deckt neue Bereiche ab: Enthält einem Satz von Teststrings (Payloads) als Basis, auch sehr lange und leere Strings und solche mit ASCII control caracters Diverse Möglichkeiten, diese Strings zu codieren (ASCII, Unicode...) Parameter können wegelassen oder verdoppelt, auch der Name des Parameters kann manipuliert werden Automatische Erkennung von Problemen anhand Fehlermeldungen, serverseitigem Programmcode, auffälligen HTTP Response codes, Pfadangaben des Servers, privaten IP-Addressen... TBD: Erkennung von Problemen durch Clustering Marc Rennhard, , ERFA_ASTF.pptx 24

25 ASTF Jüngste Entwicklungen (11) Es konnten bereits einige Fehler in Real-World Applications gefunden werden: Marc Rennhard, , ERFA_ASTF.pptx 25

26 ASTF Integrierte Testing-Tools Sicherheitsaspekte von Applikationen Derzeit integrierte Testing- Tools bzw. in Planung Applikatorische Sicherheitsfunktionen (z.b. Login-Prozess) JMeter Typische Schwachstellen in Online- Applikationen (z.b. XSS, SQL Injection) w3af, WASTF Serverkonfiguration (z.b. schwache SSL Cipher, offene Ports) OpenVAS, Nmap Allgemeine Programmierfehler und Vulnerabilities (z.b. unhandled Exceptions, missing input validation) Checkstyle, FindBugs, PMD Marc Rennhard, , ERFA_ASTF.pptx 26

27 Demonstration Startseite Die Einstiegsseite zeigt alle derzeit konfigurierten Projekte (hier 3) Der blaue/rote Punkt zeigt an, ob der letzte Testlauf gemäss den gesetzten Qualitätskriterien accepted oder not accepted war Marc Rennhard, , ERFA_ASTF.pptx 27

28 Demonstration Neues Projekt kreieren (1) New Job erzeigt ein neues Projekt Ein Projekt erhält einen Namen z.b. den des zutestenden SW-Projekts Marc Rennhard, , ERFA_ASTF.pptx 28

29 Demonstration Neues Projekt kreieren (2) Die Konfiguration beinhaltet z.b. das Scheduling (autom. Testausführung) und das zu verwendende Code-Repository Marc Rennhard, , ERFA_ASTF.pptx 29

30 Demonstration PMD-Test hinzufügen Konfiguration für einen PMD-Test Benötigt Code Location und das zu verwendende PMD Ruleset Acceptance criteria werden auf Default- Werten belassen Marc Rennhard, , ERFA_ASTF.pptx 30

31 Demonstration FindBugs-Test hinzufügen Konfiguration für einen FindBugs-Test Benötigt Bytecode Location und Angabe des Effort Levels (Testintensität) Acceptance criteria werden auf Default- Werten belassen Marc Rennhard, , ERFA_ASTF.pptx 31

32 Demonstration ERFA-Tool Projekt kreiert Neues Projekt ist jetzt in der Übersicht enthalten Marc Rennhard, , ERFA_ASTF.pptx 32

33 Demonstration Testlauf manuell ausführen Ein Klick auf Build Job führt einen kompletten Testlauf durch Es werden die konfigurierten Tests verwendet Der Testlauf wird in der Build History eingetragen Marc Rennhard, , ERFA_ASTF.pptx 33

34 Demonstration Übersicht der Ergebnisse Ein Klick auf den fertigen Testlauf in der Build History zeigt eine Übersicht der Ergebnisse Man sieht, dass der Testlauf not accepted ist (roter Punkt) Ebenfalls werden die Zahl der gefundenen Nachrichten angezeigt Marc Rennhard, , ERFA_ASTF.pptx 34

35 Demonstration Detailergebnisse (1) Ein Klick PMD Test Results zeigt die PMD-Ergebnisse im Detail Es werden eine Übersicht (Summary) und Details zu den gefunden Nachrichten angezeigt Marc Rennhard, , ERFA_ASTF.pptx 35

36 Demonstration Detailergebnisse (2) Ein Klick auf den Filename zeigt die Codestelle an, basierend auf welcher die Nachricht generiert wurde Marc Rennhard, , ERFA_ASTF.pptx 36

37 Demonstration Baseline setzen Der Report wird als Baseline gesetzt (dasselbe bei FindBugs machen) Ziel: Zukünftige Reports sind akzeptiert, wenn sie nicht schlechter als dieser Report (die Baseline) sind Marc Rennhard, , ERFA_ASTF.pptx 37

38 Demonstration Nächster Testlauf Report ist jetzt akzeptiert Ein erneuter Testlauf wird nun akzeptiert (blauer Punkt), da die generierten Nachrichten identisch sind wie die eben gesetzte Baseline das ist gut genug Marc Rennhard, , ERFA_ASTF.pptx 38

39 Demonstration Konfiguration Acceptance Criteria Acceptance Criteria können sehr flexibel konfiguriert werden, für jedes ausgewählte Testing-Tool und jede Priorität separat Mit relativen Kriterien kann man Ziele vorgeben, z.b. von der aktuellen Baseline auf 0 Meldungen in 180 Tagen Marc Rennhard, , ERFA_ASTF.pptx 39

40 Demonstration w3af-test hinzufügen Konfiguration für einen w3af-test Benötigt ein w3af Script, in welchem der Testablauf definiert ist Marc Rennhard, , ERFA_ASTF.pptx 40

41 Demonstration Erneuter Testlauf (not accepted), Betrachten der w3af-ergebnisse Der w3af-test resultiert in zwei Nachrichten Der Tester identifiziert diese als False Positives und markiert diese als solche Marc Rennhard, , ERFA_ASTF.pptx 41

42 Demonstration Als False Positives markieren, Testlauf erneut ausführen (accepted) Testlauf erneut ausführen und w3af- Ergebnisse anzeigen Report ist nun accepted, weil zwar wieder die beiden Nachrichten erzeugt werden, dies aber nun als False Positives behandelt werden und nicht mehr auftauchen Marc Rennhard, , ERFA_ASTF.pptx 42

43 Demonstration PMD-Test ein zweites Mal hinzufügen (unabhängig vom ersten PMD-Test) Ein Test-Tool kann mehrere Male in einem Projekt verwendet werden (mehrere Instanzen) Marc Rennhard, , ERFA_ASTF.pptx 43

44 Demonstration Management View (1) Die Management View gibt einen schnellen Überblick über den Zustand aller Projekte Es werden Status, gemeldete Nachrichten und Differenz des letzten zum vorletzten Testlauf angezeigt (in Klammern) Marc Rennhard, , ERFA_ASTF.pptx 44

45 Demonstration Management View (2) Ein Klick auf eines der Projekte zeigt summarische Informationen zu den verwendeten Testing-Tools an Ein Klick auf eines der Testing-Tools geht zur Detailansicht des neuesten Testlaufs Marc Rennhard, , ERFA_ASTF.pptx 45

46 Demonstration Management View (3) Es können auch Trend-Graphen über beliebige Zeiträume dargestellt werden Dabei wird angezeigt, wann ein Report accepted oder nonaccepted war und wie die Acceptance Criteria jeweils gesetzt waren Marc Rennhard, , ERFA_ASTF.pptx 46

47 Demonstration Management View (4) Über einen längeren Zeitraum können sehr anschauliche Graphen erzeugt werden In diesem Beispiel wurde die Baseline (medium) zuerst auf 500 Messages gesetzt Als diese Qualität erreicht wurde, wurde sie auf 100 Messages gesetzt und auch dies konnte dann unterschritten werden Marc Rennhard, , ERFA_ASTF.pptx 47

48 Demonstration Management View (5) Die Angabe eines kleineren Ausschnittes erlaubt es quasi, hinein zu zoomen Marc Rennhard, , ERFA_ASTF.pptx 48

49 Demonstration Testläufe mit sehr vielen Messages ASTF kann auch mit grossen Datenmengen umgehen Hier z.b. ein PMD-Report mit über und ein FindBugs-Report mit über Messages Das Ausführen dieser Tests dauert natürlich einige Zeit das findet aber ja typischerweise in der Nacht statt Das anzeigen solcher grosser Reports dauert aber nur wenige Sekunden Dies liegt vor allem daran, dass wir nicht die originalen Reports einlesen, sondern diese nach einem Testlauf in einer Datenbank ablegen Marc Rennhard, , ERFA_ASTF.pptx 49

50 Zusammenfassung Nutzen und Vorteile (1) Konsequentes, vollständiges und effizientes Testen Durch die Automatisierung wird umfassend getestet und nicht nur dann, wenn es die personellen Ressourcen zulässt Es ist zwar ein Aufwand bei der Definition eines Testcases notwendig, dies wird durch die automatisierte Ausführung aber bei weitem kompensiert Die Reproduzierbarkeit von Tests wird stark verbessert Vermutlich der einzige Ansatz, der mit einer Continuous Build-Philosophie und wachsender Softwarekomplexität vereinbar ist Zeitnahes Testen Durch das Nightly-Testing werden Fehler unmittelbar und nicht erst beim nächsten Integrations-/Funktionstest gefunden Fehler fallen damit kurz nach deren Implementierung auf, was deren Behebung vereinfacht und Folgeeffekte mindert Das Nightly Testing zwingt die Entwickler auch, die Testcases jeweils an die Änderungen im Programm anzupassen Marc Rennhard, , ERFA_ASTF.pptx 50

51 Zusammenfassung Nutzen und Vorteile (2) Umfassendes Reporting und Qualitätskontrolle Standardisierte Reports erlauben das kontinuierliche Monitoring der Softwarequalität während des Entwicklungsprozesses Das Konzept mit der Baseline und den Acceptance Criteria ermöglichen das Setzen von realistischen Zielen bezüglich Software-Qualität Reports ermöglichen das schnelle Lokalisieren der Fehler Die Management View erlaubt, sehr schnell einen Überblick über den aktuellen Stand zu erhalten Einheitliche Bedienung durch Webinterface Die Einheitlichkeit bezüglich Tool-Konfiguration / -Zuweisung und Anzeige der generierten Nachrichten erhöhen die Usability im Vergleich zur direkten Benutzung der einzelnen Tools massiv Marc Rennhard, , ERFA_ASTF.pptx 51

52 Zusammenfassung Nutzen und Vorteile (3) Flexibel im Einsatz Ab der ersten Codezeile oder erst im Laufe des Entwicklungsprozesses Testing-Tools können jederzeit hinzugefügt oder entfernt werden Im Prinzip natürlich auch für non-security-related Testing verwendbar Fast jedes denkbare Testing-Tool kann integriert werden Stabilität, Performance und Skalierbarkeit Mit dem Wechsel auf Hudson steht ASTF auf einer technologisch soliden und etablierten Basis Die konsequente Ablage der Reports in einer Datenbank hat die Performance insbesondere bei grossen Reports massiv verbessert Bei sehr grossen Projekten kann ASTF selbst auf mehrere Komponenten verteilt werden Marc Rennhard, , ERFA_ASTF.pptx 52

53 ASTF Nächste Schritte Komplettierung der Grundfunktionen: Integration aller geplanter Testing-Tools Berechtigungssystem Automatische Benachrichtigung Umfassendes Testen von ASTF Usability, Perfomance, Stabilität... Durchführen von Pilotprojekten Erste Kontakte bestehen Interessenten können sich aber gerne bei uns melden! Marc Rennhard, , ERFA_ASTF.pptx 53

54 Zusammenfassung ASTF ermöglicht kontinuierliches, umfassendes und weitgehend automatisiertes Testen von Online-Applikationen bezüglich Sicherheit ASTF integriert verschiedene, zumeist Open Source Testing-Tools unter einer gemeinsamen Benutzeroberfläche ASTF ist insbesondere für Applikationen, die ständig weiterentwickelt werden, geeignet (Continuous Build) ASTF kann jederzeit ob sehr früh oder spät im SWE-Prozess eingesetzt werden ASTF eignet sich sehr gut zur Qualitätskontrolle, auch über mehrere Projekte hinweg Marc Rennhard, , ERFA_ASTF.pptx 54