Warum Ihr automatisierter Scan von 2024 Ihrer Jetpack-Compose-App um 5 Jahre hinterherhinkt

Wofür automatisierte Scans gut sind

Fairerweise zuerst: Automatisierte Scans haben ihren Platz verdient. Sie sind schnell, wiederholbar und bei jedem Build günstig auszuführen.

Stark sind sie bei Problemen mit bekannten Mustern: veraltete Abhängigkeiten, schwache Transportkonfiguration, fehlende Hardening-Flags, offensichtliche Fehlkonfigurationen. Wenn Sie keinen Scanner einsetzen, fangen Sie damit an. Nichts in diesem Artikel spricht dagegen.

Das Problem ist nicht die Werkzeugklasse. Es ist das, was wir einem sauberen Bericht unterstellen.

Der Wandel: von Seiten zu State

Viele Scan-Ansätze wurden um ein einfaches Modell herum entworfen: Eine Anwendung ist eine Menge von Seiten oder Endpunkten, und ein Crawler findet sie, indem er Links folgt und Eingaben absendet.

Jetpack-Compose-Apps funktionieren nicht so. Die UI ist eine Funktion des States. Was die Nutzerin oder der Nutzer sieht und was die App erlaubt, hängt davon ab, wer angemeldet ist, was geladen wurde, was gerade ausgewählt war und was die letzte Antwort enthielt.

In einer typischen Compose-App ist ein Screen weniger ein Ziel als eine Darstellung des aktuellen States. Auch die Navigation ist oft State. Manche Zustände existieren nur nach einer bestimmten Abfolge, mit bestimmtem Timing und bestimmten Daten.

Ein Crawler, der Screens erkundet, sieht die Screens, die er erreicht. Von den übrigen hat er keinen Anlass zu wissen.

Ein synthetisches Beispiel

Stellen Sie sich eine Abo-App vor, deren Premium-Funktion über einen State Holder freigeschaltet wird. Die Freigabe wird geprüft, wenn der Screen erstmals angezeigt wird. Ein späterer Zustandswechsel, etwa ein Tarifwechsel gefolgt von einem erneuten Versuch nach einer fehlgeschlagenen Anfrage, lässt die Funktion sichtbar, während die zugrunde liegende Prüfung nicht mehr durchgesetzt wird.

Nichts davon ist exotisch. Jeder Schritt ist normales Produktverhalten. Die Schwäche liegt in der Kombination, und die Kombination tritt nur auf einem geordneten Pfad durch das Zustandsmodell auf.

Ein Scan Seite für Seite kann jeden Screen dieser App besuchen und nichts melden. Der entscheidende Zustand wurde ihm nie präsentiert.

Warum das wichtig ist

Das sind die typischen Fehlerbilder: Logikfehler, Autorisierungsprüfungen, die in der UI-Schicht liegen, statt konsequent durchgesetzt zu werden, und Fehlerpfade, die niemand durchlaufen hat. Sie zeigen sich meist genau in den Abläufen, die Vertrauen tragen: Zahlungen, Kontoänderungen, personenbezogene Daten.

Die geschäftlichen Folgen sind am ersten Tag selten dramatisch. Sie sind leiser:

• Reibung im Deal. Die Security-Prüfung eines Käufers fragt, wie die App getestet wurde, und „wir setzen einen automatisierten Scan ein“ provoziert Nachfragen.

• Vertrauen und Abwanderung. Nutzer lesen keine Scan-Berichte. Sie merken, wenn sich Zugriff oder Daten anders verhalten als erwartet.

• Roadmap-Risiko. Befunde, die spät eintreffen, kurz vor einem Launch oder einer Due Diligence, werden unter Druck behoben und verdrängen andere Arbeit.

Nichts davon bedeutet, dass der Scan falsch war. Er hat eine engere Frage beantwortet als die, die eine Gründerin oder ein CTO stellt. „Ist die App frei von bekannten Mustern?“ und „Lässt sich das Produkt über seine eigene Logik missbrauchen?“ sind verschiedene Fragen, und nur die erste lässt sich leicht automatisieren.

Ein sauberer Scan ist eine nützliche Information. Er ist kein Beleg für Abdeckung bei zustandsabhängigen Abläufen.

Wirkungsbox

Wie gutes Testen aussieht

Zustandsbewusstes Testen geht davon aus, wie sich die App tatsächlich verhält, nicht von einer Liste von Screens. Auf hoher Ebene heißt das dreierlei.

• Abläufe und Zustände kartieren. Die relevanten Journeys und die Zustände, die sie durchlaufen, identifizieren, auch die ungewöhnlichen.

• Daten durch State Holder verfolgen. Sensible Daten und Entscheidungen von der Quelle über ViewModels und State bis zu dem verfolgen, was dargestellt und was durchgesetzt wird.

• Freigaben und Fehlerpfade testen. Prüfen, dass Route- und Feature-Freigaben über Übergänge, Wiederholungen, Fehler und Wiederherstellungen hinweg halten und dass die Durchsetzung nicht allein von der UI abhängt.

Für Fixes gilt dieselbe Sichtweise. Entscheidungen dort durchsetzen, wo die Daten liegen, nicht nur dort, wo der Screen rendert, und Zustandsmodelle so klein halten, dass sich jeder Übergang nachvollziehen lässt.

Automatisierte Werkzeuge helfen weiterhin bei der Schicht der bekannten Muster. Die zustandsabhängige Schicht braucht jemanden, der die Architektur versteht und darüber urteilen kann.

Was Sie einen Anbieter fragen sollten

Drei Fragen helfen, oberflächliches Testen von echter Arbeit zu unterscheiden. Eine vierte betrifft das, was Sie am Ende erhalten.

Gute Antworten sind konkret und nennen Abläufe, Rollen und Belege. Vage Antworten zu „voller Abdeckung“ verdienen eine Nachfrage.

Wo Sie anfangen

Wenn Sie schnell ein aussagekräftiges Bild möchten, beginnen Sie mit dem Security Health Check. Er konzentriert sich vor Ihrem nächsten Meilenstein auf die wenigen Abläufe, die am meisten zählen, und gibt Ihrem Team einen priorisierten Plan zum Umsetzen und Verifizieren.

Fragen zu Ihrem Produkt? Hinterlassen Sie Ihre E-Mail-Adresse, wir melden uns innerhalb von 1–2 Werktagen.