Hallo Giancarlo. Vielleicht gleich zum Einstieg die wichtigste Frage: Was ist die Vision deines Projekts TESTABLE?
Wir machen mit TESTABLE im Grunde das, was wir schon immer tun: Wir suchen Schwachstellen in Computer-Programmen. Diese sollen nicht mit Problemen oder Sicherheitslücken an Nutzer:innen weitergegeben werden. Es gibt schon viele Tools und Techniken, mit denen wir den Code und die Programmfunktionen untersuchen und so Fehler und Schwachstellen finden können. Diese Tools stoßen aber ständig an Grenzen und Hindernisse. Es sieht so aus, als ob wir uns mit den existierenden Lösungen langsam in einer Sackgasse befinden. Deshalb verfolgen wir mit TESTABLE einen ganz neuen Ansatz. Wir haben uns gefragt, woran es liegt, dass die Tools noch so viele Schwachstellen übersehen. Eine Ursache konnten wir klar identifizieren: die Art wie Entwickler:innen den Code schreiben. Wir bauen daher im Projekt eine Datenbank auf, in der solche Problemfälle gesammelt sind. In einem nächsten Schritt könnte man sich dann anschauen, wie sich der Code besser schreiben lässt.
Jetzt muss ich es doch genauer wissen. Was genau sind denn im Code versteckte Hindernisse für die Tools?
Ok, ich versuche mal, das anhand eines Beispiels zu erklären: JavaScript – eine Programmiersprache, die hauptsächlich zum Erstellen von Websites verwendet wird – hat zum Beispiel eine Anweisung, die dem Computer mitteilt, einen String als Teil des Codes zu behandeln, nicht als Daten. Diese Anweisungen machen es für Sicherheitstest-Tools sehr schwierig, den Quellcode zu untersuchen und zu identifizieren, wo die Schwachstelle liegt. Entwickler:innen verwenden diese Anweisungen oft auch, um Schwachstellen in ihren Programmen zu beheben. In TESTABLE erkunden wir alternative Möglichkeiten, Code zu schreiben, um Entwickler:innen zu helfen, problematische Anweisungen zu vermeiden – die wir Testbarkeitsmuster nennen – und stattdessen Alternativen zu verwenden.
Damit eure Arbeit Früchte trägt, müsstet ihr also die Entwickler:innen bitten, ihren Code anderes als gewohnt zu schreiben. Das dürfte schwer werden.
(Lacht) Ja, das wäre der nächste Schritt, aber dafür müssten erst einmal Alternativen für die problematischen Code-Teile gelistet werden.
Soweit ich weiß, schreibt doch heute fast niemand ein Programm von Grund auf selbst. Ich habe von codegenerativen Sprachmodellen gehört, die wie ChatGPT natürliche Sprache ausspuckt, auch auf Knopfdruck Programmcode schreiben können. Könntet ihr die mit euren Daten nicht einfach so trainieren, dass sie gleich „besseren“ Code produzieren?
Das wäre eine Idee, wenn wir dafür die entsprechenden Daten haben und davon auch möglichst viele. Im Moment bauen wir aber erstmal eine Datenbank auf, die eine Liste von Signaturen enthält, nach denen wir suchen können. Dann können wir sagen: Wenn der Code diese Signatur hier enthält, dann könnte es für Werkzeug XY kompliziert werden. Dieser Schritt zeigt uns, wo die Probleme mit dem bisherigen Code liegen. Wir bräuchten für ein solches Training ja vor allem auch Daten darüber, wie der Code besser geschrieben werden kann. Diesen Teil können wir leider in diesem Projekt nicht behandeln. Wir sind bereits am Ende des zweiten Jahres angelangt. Wir haben noch ein Jahr, im August 2024 ist TESTABLE erst einmal abgeschlossen.
Was denkst du, wo ihr dann stehen werdet?
Unser Hauptziel ist es, die Datenbank so weit wie möglich voranzutreiben. Wir haben ein Repository auf GitHub, an dem jede:r teilnehmen und beitragen kann. Ein weiteres Ziel ist es, eine Gemeinschaft von Entwickler:innen und Sicherheitstest-Expert:innen aufzubauen, damit wir diesen selbsttragenden Mechanismus für das Testbarkeitsmusterprojekt haben, das auch ein offizielles Projekt innerhalb der OWASP-Community ist. Aber wir arbeiten auch weiterhin daran, den Stand der Technik im Bereich der Testwerkzeuge voranzutreiben. Und wir sind bemerkenswert effizient darin, besonders am CISPA. Mein Doktorand Soheil Khodayari forscht genau in demselben Bereich, den CISPA im Rahmen von TESTABLE unterstützt, und er erzielt erstaunliche Ergebnisse. Erst kürzlich erhielt er einen Best-Paper-Award für eine seiner Arbeiten.
In diesem Projekt kollaborieren viele europäische Institutionen aus Forschung und Industrie. Spielt die Internationalität der Teilnehmenden eine Rolle für den Erfolg?
Europäische Projekte geben einem die konkrete Möglichkeit, zusammenzuarbeiten und sind gut für die Vernetzung und den Erfahrungsaustausch. Innerhalb des großen Ganzen gibt es viele kleine Projekte, zum Beispiel zwischen CISPA, SAP und der TU Braunschweig, aus denen dann Paper entstehen. Die Projekttreffen sind das Hauptelement, das es uns ermöglicht, diese Zusammenarbeit aufzubauen. Wir treffen uns, halten Workshops ab, stellen unsere Ergebnisse vor, präsentieren frische Ideen und suchen konstant Möglichkeiten, zusammenarbeiten.
Wenn Forschende mit Industriepartnern wie Norton oder SAP zusammenarbeiten, wie funktioniert diese Kooperation?
Wir haben einen gemeinsamen Plan, wie wir Programme sicherer machen können. Jeder Partner trägt auf seine eigene Weise zu diesem übergeordneten Ziel bei. CISPA treibt beispielsweise den Stand der Technik im Bereich der automatisierten Sicherheitstests voran. UC3M tut dasselbe, jedoch im Bereich Privacy und Datenschutz. Eurecom leitet die Erstellung des Datensatzes für Testbarkeitsmuster. Pluribus One kümmert sich um maschinelles Lernen. SAP, Shiftleft, IMQ Minded Security und Norton sind unsere Industriepartner – sie liefern uns Fallstudien und betreiben auch selbst Forschung, alles mit erstklassigen Forschenden. Shiftleft ist dafür verantwortlich, potenzielle industrielle Anwendungsfälle für die von uns entwickelten Technologien zu identifizieren. Norton konzentriert sich auf die Datenschutzanforderungen der Benutzer, und SAP auf Sicherheitstests. Shiftleft stellt Testwerkzeuge her, die wichtig sind, um unsere neu entwickelten Ansätze zu testen. IMQ Minded Security übernimmt eine beratende Rolle. Sie sind am ehesten in der Lage, uns mitzuteilen, wie unsere Konzepte in der Industrie umgesetzt werden können. Jeder Partner leistet seinen eigenen Beitrag.
Du scheinst mit dem Projekt und wie es läuft sehr zufrieden zu sein.
Es gibt zwei Gründe, warum es so gut läuft: Erstens sind wir alle eng miteinander verbunden und zweitens sind wir alle Spitzenforschende. Das heißt hier arbeiten Menschen zusammen, die aus eigener Kraft nach Erfolg streben. Das sind zwei Zutaten, die meine Arbeit als wissenschaftlicher Koordinator sehr vereinfachen.
Ich wollte dich eigentlich fragen, was die Herausforderungen bei einer solchen Zusammenarbeit sind. Aber was du mir bisher erzählt hast, klingt sehr angenehm.
Glücklicherweise gibt es nicht viele. Wenn ich eine auswählen müsste... könnte ich dir von der größten erzählen: die Entscheidung über den Ort für das nächste Projektmeeting! Wir haben Partner aus vielen schönen Orten in Europa, wie zum Beispiel Sophia Antipolis im Süden Frankreichs, Madrid in Spanien, Cagliari und Mailand in Italien und Berlin in Deutschland. Wir entscheiden immer strategisch, basierend darauf, wie das Wetter sein wird. Unser letztes Treffen war in Madrid, eine fantastische Stadt!
Giancarlo, danke für das Gespräch.
