Was ist ein Penetrationstest?

Ein kontrollierter Angriff auf die eigene Software. Jemand versucht mit denselben Mitteln wie ein echter Angreifer, an Daten oder Funktionen zu kommen, an die er nicht kommen soll – und schreibt anschließend auf, was funktioniert hat. Der Zweck ist nicht der Schaden, sondern der Bericht.

Sind meine Daten in Schneespur jetzt sicher?

Ein Penetrationstest ist eine Momentaufnahme, kein Zertifikat und keine Garantie. Er sagt: Diese sieben Dinge waren offen, sie sind jetzt zu. Er sagt nicht, dass nichts mehr offen ist. Was Sie tun können, ist das Naheliegende: Updates einspielen, sobald sie da sind – die Sicherheitsarbeit steht bei jeder Version im Changelog.

Warum veröffentlichen Sie gefundene Schwachstellen überhaupt?

Weil Schneespur Open Source ist und jeder den Quellcode und die Änderungen daran ohnehin einsehen kann. Ein Fehler, über den nicht geschrieben wird, ist deshalb nicht weniger vorhanden – er ist nur schlechter dokumentiert. Veröffentlicht wird, nachdem die Korrektur ausgeliefert ist, also mit Version 1.2.0.

Muss ich als Betreiber nach dem Update etwas tun?

Zwei Kleinigkeiten. Öffnen Sie die Fahrer-App nach dem Update einmal bei bestehender Internetverbindung, damit sich der Offline-Teil einrichten kann. Und wenn Sie das Telegram-Modul nutzen, spielen Sie dessen Update ein, bevor Sie den Kern aktualisieren – sonst bleibt der Fotoversand still liegen.

Von KI gebaut, von KI geprüft: zwei Penetrationstests an Schneespur

Schneespur ist zum größten Teil nicht von mir geschrieben worden, sondern von einer KI. Das habe ich an anderer Stelle schon ausführlich erklärt und halte es für den ehrlicheren Weg, als es zu verschweigen.

Es wirft aber eine Frage auf, die ich mir selbst gestellt habe, lange bevor sie mir jemand anderes gestellt hat: Wer prüft das eigentlich?

Am 3. August 2026 habe ich darauf eine Antwort versucht. Ich habe Schneespur zwei Penetrationstests unterzogen – kontrollierten Angriffen auf die eigene Software. Gefahren hat sie kein Mensch, sondern wieder eine KI. Nur eben nicht dieselbe.

Was Strix ist

Für die Tests habe ich Strix eingesetzt, ein quelloffenes Werkzeug für automatisierte Sicherheitstests. Es ist kein Scanner im herkömmlichen Sinn, der eine Liste bekannter Muster abklappert. Es ist ein Agent: ein Sprachmodell, das Werkzeuge bedienen darf und selbst entscheidet, welches als nächstes.

Diese Werkzeuge sind dieselben, mit denen auch ein menschlicher Tester arbeitet. Ein Abfang-Proxy, der jede Anfrage zwischen Browser und Server mitliest und verändern lässt. Ein Crawler, der die Anwendung selbstständig durchläuft. Statische Quellcode-Analyse. Scanner, die nach versehentlich hinterlassenen Zugangsdaten suchen. Ein Abgleich der eingesetzten Fremdbibliotheken gegen die öffentlichen Schwachstellendatenbanken. Ein echter Browser. Und ein Python-Interpreter, mit dem sich der Agent bei Bedarf sein eigenes Angriffsskript schreibt.

Das Ganze läuft in einem abgeschotteten Container, nicht auf meinem Rechner. Und es läuft nicht als ein Agent, sondern als viele: Ein Leitagent verschafft sich einen Überblick und macht dann für jeden Verdacht einen eigenen Unteragenten auf, der nur dieser einen Sache nachgeht.

Als Sprachmodell lief GPT-5.4. Das ist der Punkt, der mir an dem Aufbau am wichtigsten ist: Geschrieben hat den Code Claude, geprüft hat ihn ein Modell einer anderen Familie. Ein Modell, das seinen eigenen Code prüft, findet vor allem die Fehler, die es beim Schreiben schon für Fehler gehalten hätte.

Wie getestet wurde

Zwei Läufe, zwei völlig verschiedene Blickwinkel.

Lauf 1 lief gegen den Quellcode von Version 1.1.9, mit vollem Einblick – in der Fachsprache ein Whitebox-Test. Der Agent hat das Repository kartiert, Routen und Zugriffsprüfungen durchgesehen, die Vertrauensgrenzen der Anwendung bestimmt, danach eine lokale Instanz hochgezogen und seine Verdachtsfälle dort tatsächlich ausprobiert. Er hat dafür 17 Agenten aufgemacht, mit sprechenden Namen: „Installer Surface Lead“, „Module Surface Lead“, „Composer Dependency CVE Lead“. Dauer: eine Stunde und 31 Minuten, davon rund eine halbe Stunde allein für den Aufbau der Testumgebung.

Lauf 2 lief gegen eine echte, laufende Installation – eine der Wegwerf-Demos, die sich jeder anfordern kann, frisch erzeugt und nach 48 Stunden ohnehin gelöscht. Diesmal ohne Quellcode, nur mit einem Administrator-Zugang, wie ihn ein Angreifer mit gestohlenen Zugangsdaten hätte. Der Agent hat sich die öffentlich erreichbaren Adressen angesehen, sich zusätzliche Konten mit weniger Rechten angelegt, um Rechteprüfungen gegeneinander zu testen, und dann systematisch durchprobiert: Zugriffsrechte, Geschäftslogik, eingeschleuster Code, Datenbankabfragen, gefälschte Formularabsendungen, ausgehende Verbindungen aus den Einstellungen heraus. 12 Agenten, 32 Minuten.

Ich habe in beiden Läufen nichts vorgegeben außer dem Ziel. Keine Hinweise, worauf zu achten wäre, keine Liste bekannter Schwachstellen.

Was gefunden wurde

Nach Prüfung und Zusammenlegung von Doppelmeldungen blieben sieben Befunde. Alle sieben sind in Version 1.2.0 behoben, und zu jedem gibt es einen automatischen Test, der anschlägt, falls der Fehler jemals zurückkommt.

Zwei davon waren ernst.

Der erste: Schritte der Ersteinrichtung waren auf einer fertig installierten Anlage weiter erreichbar. Ohne Anmeldung. Wer die richtige Adresse kannte, konnte die E-Mail-Einstellungen überschreiben. Der Agent hat das nicht vermutet, sondern vorgeführt.

Der zweite: Einsatzfotos lagen in einem öffentlich ausgelieferten Ordner. Wer die Adresse eines Fotos kannte oder erriet, kam ohne Anmeldung heran. Das ist der Befund, der mir am längsten nachgegangen ist, denn auf so einem Foto ist ein Grundstück zu sehen, oft mit Hausnummer, dazu Zeitpunkt und Ort. Genau die Daten also, die ein Winterdienst dokumentiert, um im Streitfall etwas in der Hand zu haben.

Dazu kamen fünf kleinere: eine Datenschutzbelehrung, in der über einen Markdown-Link ausführbarer Inhalt hinterlegt werden konnte. Ein abgeschaltetes Modul, das nach einem Neustart wieder mitlief. Ein manuell angelegter Auftrag, der sich auf jemanden buchen ließ, der gar kein Fahrer ist. Eine Konfigurationsangabe für den Wetterdienst, die Zeilenumbrüche in eine ausgehende Anfrage schmuggeln konnte. Und eine Schnittstelle für Module, die für jedes angemeldete Konto offenstand statt nur für Administratoren.

Der letzte Punkt ist der interessanteste, denn genau diesen Verdacht hat der Agent im ersten Lauf selbst wieder verworfen: Er hat ihn über echtes HTTP nachgeprüft und im Bericht ausdrücklich als nicht bestätigt geführt. Zugemacht habe ich ihn trotzdem. Wenn ein Prüfer bei etwas ins Grübeln kommt, ist das für sich schon ein Grund hinzusehen.

Dazu kam ein Befund außerhalb des eigenen Codes: Die Bibliothek, die Schneespur für die PDF-Berichte einsetzt, hing auf einer Version mit sechs veröffentlichten Sicherheitshinweisen. Sie ist aktualisiert. Und weil dabei auffiel, dass die PDF-Erstellung Inhalte aus dem Netz nachladen durfte, obwohl kein einziger Bericht das braucht, ist das jetzt abgeschaltet – womit mehrere dieser Hinweise ohnehin ins Leere laufen.

Was nicht gefunden wurde

Das gehört genauso in den Bericht wie der Rest, gerade weil es weniger spannend zu lesen ist.

Keine SQL-Injection, obwohl gezielt danach gesucht wurde. Keine umgehbare Absicherung gegen untergeschobene Formularabsendungen. Keine gebrochene Rechteprüfung auf einzelne Datensätze – ein Fahrer kam in den geprüften Abläufen nicht an die Einsätze eines anderen. Der Bericht des zweiten Laufs führt das ausdrücklich als positiven Befund.

Zwei weitere Hypothesen hat der Agent selbst wieder eingesammelt: ein vermuteter Angriff über präparierte Modul-Archive ließ sich auf der tatsächlichen Umgebung nicht nachstellen, und eine Reihe von Meldungen zu einer HTTP-Bibliothek hat er nicht als Befund gewertet, weil sich dafür keine bestätigte Schwachstellennummer finden ließ.

Und ein Befund wurde doppelt gemeldet: Zwei Unteragenten stießen unabhängig voneinander auf das mitlaufende abgeschaltete Modul. Der Abschlussbericht erkennt das und weist ausdrücklich darauf hin, dass es sich um eine Ursache handelt. Das ist keine Kleinigkeit. Der übliche Vorwurf an automatisierte Prüfung lautet, sie produziere Berge von Fehlalarmen; hier hat der Prüfer seine eigene Doppelmeldung erkannt und eingeordnet.

Was es gekostet hat

Die Zahlen finde ich aufschlussreich genug, um sie vollständig hinzuschreiben.

Beide Läufe zusammen
Dauer	rund 2 Stunden
Agenten	29
Anfragen ans Modell	1.070
Gelesene Token	72.571.048
davon aus dem Zwischenspeicher	70.187.264
Geschriebene Token	374.662

Der Löwenanteil entfällt auf den ersten Lauf: 43,1 der 72,6 Millionen gelesenen Token gingen auf das Konto der Quellcode-Prüfung, die auch länger lief und mehr Agenten beschäftigte. Zwei Dinge stechen heraus.

Ein Prüfagent ist fast reiner Leser. Auf jedes geschriebene Token kommen rund 190 gelesene. Was in zwei Stunden entstanden ist – zwei Berichte, dreizehn Einzelbefunde, die Nachweise dazu –, sind gerade einmal 374.662 Token, ein halbes Prozent des Gesamtverbrauchs. Der ganze Rest ist Lesen, Nachschlagen und Wiedervorlage.

Und das meiste davon war schon einmal da. Von den 72,6 Millionen gelesenen Token kamen 70,2 Millionen aus dem Zwischenspeicher, also 96,7 Prozent. Ein Agent, der 500 Züge lang an einem Fall bleibt, schleppt seinen Kontext bei jedem Zug erneut mit. Ohne diesen Zwischenspeicher wäre so ein Lauf schlicht nicht bezahlbar.

Zu den Kosten in Euro kann ich nichts Belastbares sagen: Beide Läufe liefen über ein bestehendes Abonnement, es gab also keine gesonderte Rechnung. Die Token-Zahlen sind das ehrlichere Maß für den Aufwand.

Was ich sagen kann: Ein menschlicher Penetrationstest dieser Tiefe kostet einen vierstelligen Betrag aufwärts. Für ein Projekt, das kostenlos und quelloffen ist und von einer Person betrieben wird, hätte er schlicht nicht stattgefunden. Nicht, weil er unwichtig wäre – sondern weil er nicht drin gewesen wäre. Das ist die eigentliche Veränderung.

Was daraus geworden ist

Version 1.2.0 ist am 9. August erschienen und ist in erster Linie das Ergebnis dieser beiden Tests. Dazu kamen fünf weitere Fehler, die überhaupt erst auffielen, als ich das Release auf gewöhnliches Webhosting gespielt habe statt nur die Testreihe laufen zu lassen – darunter der peinlichste des ganzen Sommers: Die Fahrer-App war nie wirklich offline verfügbar, weil ihr Offline-Teil an der falschen Stelle eingebunden war. Das hat kein Test gefunden. Das findet man, indem man das Handy in den Flugmodus schaltet.

Drei Module sind nachgezogen, alle am selben Tag: Telegram 1.0.5 verschickt Einsatzfotos jetzt als Datei statt als Link, weil Telegrams Server einen Link ohne Anmeldung abholen – was der neue Fotoschutz zu Recht ablehnt. Dokumente 1.0.10 meldet seinen Speicherpfad beim Kern an, damit auch bereits hochgeladene Dokumente in den geschützten Bereich wandern. Und Lager 1.3.0 zieht Mengen, Preise und Datumsangaben auf die neuen Regionsformate nach, die 1.2.0 eingeführt hat.

Was das alles nicht beweist

Ein Penetrationstest ist eine Momentaufnahme. Er sagt: An diesem Tag, mit diesen Werkzeugen, in dieser Zeit waren diese sieben Dinge offen. Er sagt nicht, dass nichts mehr offen ist. Er ist kein Zertifikat, kein Prüfsiegel und ganz sicher keine Zusicherung, dass Ihrer Installation nichts passieren kann.

Zwei Einschränkungen stehen ausdrücklich in den Berichten selbst. Der zweite Lauf hatte nur einen einzigen vorgegebenen Zugang, und der Datenbestand der frischen Demo war dünn – Konstellationen mit vielen Nutzern und vielen Kunden ließen sich damit nur begrenzt durchspielen. Und ein automatisierter Lauf über 500 Züge ist gründlich, aber nicht erschöpfend; er geht den Spuren nach, die er selbst gelegt hat.

Was ich daraus mitnehme, ist trotzdem etwas anderes als vorher. Nicht „die Software ist sicher“ – den Satz schreibe ich nicht. Sondern: Sie ist geprüft worden, von einer Instanz, die nicht ich bin und die nichts davon hat, mir zuzustimmen. Das Ergebnis war unangenehm, und es steht öffentlich im Changelog, Punkt für Punkt.

Für Software, die von einer KI geschrieben wurde, halte ich das für die einzig vertretbare Antwort auf die Frage vom Anfang. Der Quellcode ist offen einsehbar, die Änderungen sind nachvollziehbar, die gefundenen Fehler benannt. Prüfen Sie es nach.