Hallo Dominic. Kannst du kurz erläutern, was InputLab macht und welches Problem ihr lösen möchtet?
Hallo. Klar, gerne. Wir produzieren vollsynthetische Daten, mit denen Software systematisch getestet werden kann – und das datenschutzkonform. Denn bislang haben viele Hersteller:innen in der Entwicklung von Software das Problem, dass sie diese nur mit Produktivdaten testen können. Das sind Daten, die im Echtbetrieb der Software anfallen, wie etwa Adressdaten. Da diese Daten personenbezogene Informationen enthalten, dürfen die Hersteller:innen sie in ihrer eigentlichen Form gar nicht nutzen, da die DSGVO das verbietet. Gleichzeitig brauchen sie aber Daten, die diesen Produktivdaten einigermaßen ähnlich sind, um ihr System auch sinnvoll testen zu können. So weichen viele Unternehmen darauf aus, die Produktivdaten zu nehmen und zu verfremden. Das führt aber leider oft dazu, dass nicht alle möglichen Fehler getestet werden können, weil zum Beispiel Sonderzeichen nicht oder zu selten auftauchen. Was auch häufig passiert ist, dass Fehler, die bei der Eingabe im Echtbetrieb aufgetaucht sind, in der Testung mit den verfremdeten Daten nicht reproduzierbar sind und so das Problem eben auch nicht gelöst werden kann. Wir haben deshalb einen Demonstrator entwickelt, mit dem wir vollsynthetische Testdaten generieren können, die genau zu der zu testenden Software passen. Wer sein System mit unseren Daten testet, kann von nichts mehr überrascht werden.
Wie produziert ihr diese Daten? Mithilfe von künstlicher Intelligenz?
Nein. Denn auch dieser Ansatz bringt das Problem mit, dass ein KI-System, das wirklich sinnvolle Daten produzieren soll, vorher mit echten Daten gefüttert werden muss. Unternehmen, die mit sensiblen Daten umgehen, wie etwa Banken, Versicherungen oder öffentliche Behörden können das natürlich auf keinen Fall tun. Unser Ansatz ist einzigartig und bereits zum Patent angemeldet: Wir arbeiten mit der Beschreibung der Datenformate, die die Unternehmen nutzen und in der Regel sowieso dokumentiert haben. Das können zum Beispiel schemabasierte Datenformate wie XML, JSON oder Datenbanktabellen sein. Diese Beschreibungen konvertieren wir in eine Grammatik, also wir beschreiben sie formal, und können dann mithilfe der von uns entwickelten Spezifikationssprache ISLa basierend auf diesen Regeln wirklich sinnvolle Eingabedaten erzeugen. Damit wir auch komplexe Datenformate aus der Praxis handhaben können, mussten wir darüber hinaus noch einiges an Forschungs- und Entwicklungsarbeit investieren.
Sind Fuzzer nicht Tools, die genau das machen? Also Zufallsdaten produzieren, um Software zu testen?
Ja, das stimmt. Das Problem mit Fuzzern ist allerdings, dass diese häufig nur Daten generieren, die inhaltlich keinen Sinn ergeben. Mit diesen Eingaben lassen sich Programme nicht in der Tiefe testen, weil sie schon in der „ersten Runde“ als Datenmüll aussortiert werden.
Müsst ihr die Beschreibungen der Kunden zu den Datenformaten manuell in eine Grammatik überführen?
Nein, das läuft mit unserem Demonstrator alles schon vollautomatisch. Wir arbeiten derzeit mit drei Pilotpartnern zusammen. Diese Partner bekommen von uns Testdaten und testen damit ihre Systeme. Zwei davon nutzen das schemabasierte Datenaustauschformat XML, ein anderer arbeitet mit einer Open-API-Schnittstelle. Sie geben uns Feedback im Prozess und wir arbeiten mit ihnen an der weiteren Verfeinerung der Daten speziell für ihren Zweck. Noch haben wir Kapazitäten für zwei bis drei weitere Pilotpartner. Später im Jahr freuen wir uns über zahlende Kunden.
Woher wisst ihr, dass euer Ansatz wirklich funktioniert?
Zum einen eben aus dieser Zusammenarbeit mit unseren Pilotpartnern. Zum anderen haben wir gerade mehrere populäre Programme und Code-Bibliotheken mit unseren automatisch generierten Testdaten gefüttert und in wirklich allen von uns getesteten Programmen Fehler gefunden. So versuchte eine Grafikbibliothek, bei einer kleinen Vektorgrafikdatei 133 Terabyte an Speicher als Eingabe zu reservieren. Das kann ein potenzielles Sicherheitsrisiko werden, wenn eine solche Bibliothek beispielsweise auf einem Webserver läuft. Diese eine Bibliothek hat sehr viele Nutzer und ist sogar verhältnismäßig gut getestet. Auch ein Programm zur Verarbeitung elektronischer Rechnungen und ein E-Book-Leseprogramm zeigten in unseren Versuchen Fehlverhalten. In der Praxis kann sowas zu echten Problemen führen.
Hier vielleicht eine kleine Anekdote: Ich habe mit einem potenziellen Pilotpartner geredet, der mit Verlagen zusammenarbeitet. Er hat mir von einem Verlag erzählt, der elektronische Rechnungen erstellt und verschickt. Eine ging an eine Bibliothek, die Bücher von diesem Verlag gekauft hatte. Der Titel des Buches eines internationalen Schriftstellers enthielt Sonderzeichen. Die Rechnung wurde deshalb vom System der Bibliothek nicht richtig eingelesen und so auch nicht verarbeitet. Gemerkt hat die Bibliothek das erst, als die Mahnung eintrudelte. Für kleinere Unternehmen, die deshalb lange auf ihr Geld warten müssen, kann das echt existenzbedrohend sein. Mit unseren Testdaten können Anbieter von Rechnungssoftware solche Fehler finden und ihren Kunden Software anbieten, die funktioniert. Das ist ein echter Wettbewerbsvorteil.
Für wen genau ist eure Lösung interessant?
Eigentlich für alle Unternehmen, die Software herstellen und besonders dann, wenn der Ausfall der hergestellten Software mit großen finanziellen Verlusten einhergehen würde. Das kann zum Beispiel auch bei einer in der Autoindustrie eingesetzten Software der Fall sein. Besonders interessant könnte unsere Arbeit aber eben auch für die bereits erwähnten Banken oder Versicherungen sein, die mit sensiblen Daten arbeiten und die ihre Softwarequalität unbedingt sicherstellen müssen. Wichtig ist, dass die Unternehmen eine ausreichende Teststruktur haben und die von uns gelieferten Daten auch verarbeiten können. Das ist bei sehr kleinen Unternehmen leider oft nicht der Fall.
Wie entstand die Idee zu InpuLab?
Ich habe zwischen 2021 und August 2024am CISPA in der Gruppe von Andreas Zeller als Postdoc geforscht. Dabei habe ich das ISLa-System entwickelt, das jetzt eines unserer technischen Fundamente ist. Andreas hatte die Idee, dass wir basierend auf Technologien wie ISLa ein Unternehmen gründen könnten, dass XML-Testdaten verkauft. Erst im Verlauf des Prozesses wurde uns bewusst, wie groß der Bedarf am Markt tatsächlich ist.
Wie geht es für euch weiter?
Wir sind derzeit noch in der Entwicklungsphase, in der wir erarbeiten, wie unsere Idee technisch umgesetzt und perspektivisch auch zur Marktreife gebracht werden kann. Wir arbeiten solange weiter als Forschende am CISPA. Das Bundesministerium für Bildung und Forschung fördert uns bereits im Rahmen des StartUpSecure-Programmes mit Mitteln für Personal, Ausstattung und andere Kosten. Der CISPA Incubator unterstützt und zusätzlich mit Beratungen, Pitch-Trainings und ähnlichem. Im Frühjahr steht dann die Gründung der GmbH an, aber erst im Herbst 2025 werden wir das CISPA verlassen und auf eigenen Füßen stehen.
Was motiviert dich, diese Innovation immer weiter voran zu treiben?
Ehrlich gesagt: Mich motiviert zu allererst mein Team. Es ist so toll zu sehen, dass wir zusammen so viel Größeres erreichen können, als jeder Einzelne für sich. Wir sind jetzt sechs Vollzeitkräfte und drei Hilfswissenschaftler – leider bislang nur Männer. Dieses Team ist wirklich großartig und die Arbeit macht richtig Spaß. Ich lerne ständig Neues, das ist sehr bereichernd. Natürlich gibt es Höhen und Tiefen, aber derzeit überwiegen die Höhen deutlich.
So soll es bleiben. Ich bin gespannt, von euch zu hören. Danke für das Gespräch, Dominic.
