Auch 2023 wollen wir am 1. und 2. September wieder das QS[Bar]camp in Hamburg bei oose veranstalten – das Format bleibt: Barcamp, also
Wer auf dem Laufenden bleiben möchte, gerne bei LinkedIn der Gruppe QS Barcamp beitreten.
Security Testing durch Instrumentierung verspricht bei DevSecOps bessere und schnellere Ergebnisse als gängige Scan-Verfahren. Erfahren Sie in Theorie und Praxis, was hinter der Methode steckt.
Scannen Sie noch oder instrumentieren Sie schon? Denn neue Test-Methoden können die Anwendungssicherheit während der Entwicklung und im laufenden Betrieb effizient steigern. Hören Sie nicht nur die Theorie vom Hersteller, sondern auch den Praxisbezug des QA-Spezialisten Jörg Sievers von der Ponton GmbH in Hamburg und seine Erfahrungen mit neuen Security-Testmethoden aus Anwendersicht.
Quellcode zu scannen (Static Application Security Testing, SAST) und Anwendungen dynamisch zu testen (Dynamic Application Security Testing, DAST) sind wichtige Bestandteile funktionierender DevSecOps-Prozesse, generieren jedoch zu viele Falschmeldungen oder liefern nicht ausreichend Ergebnisse. Weiterhin ist Scanning mittels SAST sehr zeitintensiv oder DAST benötigt Experten zum Vorbereiten von Tests und deren Interpretation. Manuelles Pentesting kommt schon aus Zeitgründen nicht jedes Mal zum Einsatz.
Für DevOps, die ShiftLeft-Methodology und mehrfaches Deployment am selben Tag sind Interactive Application Security Testing (IAST) und Runtime Application Self-Protection (RASP) wesentlich besser geeignet. IAST und RASP ermöglichen zeitnah akkurat Ergebnisse für unterschiedliche Anwenderrollen in den jeweils präferierten Werkzeugen.
Wir freuen uns auf Ihre Teilnahme!
Ihre Referenten:
Mirko Brandner Jörg Sievers
Senior Sales Engineer / QA Specialist
Technical Evangelist Ponton GmbH
Contrast Security
Quelle: https://www.security-insider.de/agile-applikationssicherheit-in-echtzeit-fuer-devops-v-41422-12645/
(Testen: Die Zukunft von Softwaretestern – einePrognose; iX 12/2018, S. 88)
Wenn man sich in das Rollenmodell des IT-Testers einarbeitet, das zusammen vom German Testing Board und der Gesellschaft für Informatik entwickelt wurde, sieht man, wie ein expliziter Tester den Informatikern zur Seite stehen kann. Die Vielfältigkeit der dort beschriebenen Aufgaben auf die Entwickler abzuwälzen, wäre so, als würde ein Industriearbeitnehmer alle Aufgaben von der Produktplanung bis zur Auslieferung bei EDEKA selbst erledigen – das ist wohl eher nicht wünschenswert, da man dafür viele unterschiedlichste Kompetenzen in einer Person vereinigen müsste. Der einstige „Bughunter“ ist sicherlich schon länger passé, aber der Tester, der die Entwickler besser macht, ist etwas, was es auch in den nächsten Jahrzehnten noch geben wird. Ich suche immer nach Parallelen aus meinem alten Job in der Lebensmittelindustrie, und da geht nichts, ohne dass nicht die Qualität stimmt. Und weil gerade Querschnittsthemen in der agilen Welt ein Problem darstellen können, hilft der Kommunikator oder „die Bauchspeicheldrüse“ des Projekts (Alex Schladebeck),die die Dinge zusammenführen kann.
Informatiker lernen in ihrer Ausbildung selten etwas über Grenzwerte, Sicherheitstests, Akzeptanztests – so meine Erfahrung in 20 Jahren … und das gerade bei Sicherheit nur auf Sourcecode zu beziehen, kann sehr gefährlich sein, wenn man bspw. SAST-Tools mal anschaut, die viele Entwickler kennen und die beim OWASP-Benchmark gerade mal etwa 30 % aller Sicherheitsfehler finden. Wenn da nicht ein Sicherheitstester noch andere Wege aufzeigt, um Einfallsvektoren zu bestimmen, ist Ihr Start-up schneller gehackt, als Sie die Worte „Sicherheitstests wären gut“ sagen können. Agile Testing / More Agile Testing (zwei Standardwerke, d. Red.) beschreiben die Dinge, die in die agilen Strukturen mittlerweile aufgegangen sind, und beschreiben ziemlich gut, wie sich die Berufswelt des Testers veränderte. Wir würden andere Produkte, wie Autos,Zahnpasta, Brot, Gemüse, nicht kaufen,wenn wir nicht wüssten, dass sich jemand um die versprochene Qualität des Produktes bemüht. Warum manche Informatiker denken, ihre Welt funktioniert anders als die restliche, wird mir ewig ein Rätsel bleiben. Denn die Projekte, die meinten, nicht auf Qualität zu setzen, gibt es oftmals nicht mehr. Die, die wussten, welchen Fehler sie gemacht haben, lehren andere Gründer auf Qualität zu setzen.
JÖRG SIEVERS, AHRENSBURG
