App-Entwicklung3 Min. Lesezeit

Was Ihr MobSF-Score Ihnen wirklich sagt

Ein MobSF-Score ist kein Sicherheitsurteil. Wie Build-Typ, False Positives und blinde Flecken ihn verzerren und wie aus dem Bericht echte Befunde werden.

Ein Security-Partner, ein Auditor oder Ihr eigenes Team lässt MobSF über Ihre App laufen, und heraus kommt eine Zahl: sagen wir 48 von 100. Die naheliegende Reaktion ist die Frage, wie man auf 80 kommt. Die bessere Frage lautet, woraus sich die 48 eigentlich zusammensetzen.

In diesem Artikel erklären wir, was ein MobSF-Score misst, auf welche drei Arten er in die Irre führt und wie aus einem Scanner-Bericht Befunde werden, die jemand verantworten und beheben kann – mit echten Zahlen aus einem Audit einer Banking-App, das wir durchgeführt haben.


Was MobSF misst

MobSF (Mobile Security Framework) analysiert die Binärdatei einer App statisch. Es liest das Manifest, dekompiliert den Code, listet die Bibliotheken auf und prüft die Konfiguration anhand eines Regelwerks. Jede Regel, die fehlschlägt, senkt den Score.

Das macht MobSF schnell, reproduzierbar und nützlich. Es bedeutet aber auch, dass der Score Muster in der Binärdatei widerspiegelt – nicht, wie sicher die App im Einsatz ist.

📌 Kernaussage:

Ein MobSF-Score beantwortet die Frage „Wie viele Regeln hat diese Binärdatei verletzt?“ – nicht „Wie schwer ist diese App anzugreifen?“


Drei Arten, wie der Score in die Irre führt

1. Der Build-Typ verändert den Score

Debug-Builds enthalten Einstellungen, die in Release-Builds nichts zu suchen haben: Debuggable-Flags, Testkonfiguration, ausführliches Logging und mehr. Wer den falschen Build scannt, bewertet etwas, das Ihre Nutzer nie installieren.

Bei der Banking-App, die wir auditiert haben, gingen 6–7 der 52 fehlenden Punkte allein auf den Build-Typ zurück. Noch bevor jemand eine Zeile Code geändert hatte, lag ein Teil des Problems schlicht darin, welche Datei gescannt worden war.

2. „Sicher“ ist nicht immer sicher

Statische Regeln gleichen Muster ab. Sieht Code wie eine korrekte Implementierung aus, gilt die Regel als erfüllt – selbst wenn die Schutzmaßnahme nicht so funktioniert, wie es scheint. Im selben Audit waren zwei als sicher markierte Prüfungen False Positives. Ein grüner Haken ist eine Behauptung, die es zu überprüfen gilt, keine Schlussfolgerung.

3. Der Scanner sieht die Logik nicht

Einige der gravierendsten Schwachstellen mobiler Apps stecken in der Logik, nicht in der Konfiguration:

  • Ein Authentifizierungsablauf, der einem clientseitigen Flag vertraut.

  • Ein biometrischer Login, der nur einen Erfolgs-Callback prüft.

  • Sensible Daten, die an einer Stelle gespeichert werden, die die Regeln nicht prüfen.

Nichts davon verändert einen statischen Score zuverlässig. Dafür braucht es eine Prüfung durch einen Menschen.


So lesen Sie einen MobSF-Bericht richtig

  1. Reproduzieren Sie den Score mit dem Release-Build. Ohne reproduzierbare Ausgangsbasis lässt sich keine Verbesserung belegen.

  2. Teilen Sie die verlorenen Punkte in Kategorien auf: Rauschen durch den Build-Typ, echte Konfigurationslücken und Befunde, die Kontext erfordern.

  3. Überprüfen Sie die grünen Haken bei allem, was sicherheitskritisch ist.

  4. Führen Sie ein manuelles Audit anhand der OWASP Mobile Top 10 (2024) durch, um abzudecken, was der Scanner nicht sieht.

  5. Bewerten Sie jede echte Lücke mit CVSS, damit sich die Prioritäten nach dem Schweregrad richten und nicht nach der Menge.


Score vs. Befunde

Aspekt Reiner MobSF-Score Auditierte Befunde
Was gezählt wird Von der Binärdatei verletzte Regeln Echte, verifizierte Schwachstellen
Rauschen durch den Build-Typ Enthalten Entfernt
Fälschliche „sicher“-Haken Verborgen Identifiziert
Logikfehler Größtenteils unsichtbar Durch manuelle Prüfung abgedeckt
Priorisierung Keine CVSS-Score pro Lücke

Wie Mobian unterstützt

Bei Mobian begann das Audit hinter diesen Zahlen mit einem Score von 48/100 und endete mit 48 nach CVSS bewerteten Lücken und 124 nachverfolgten Fixes. Wenn Sie bereits einen MobSF-Bericht haben, erhalten Sie von uns eine einseitige Einschätzung: was darin echt ist, was Rauschen ist und was einen zweiten Blick verdient. Für das vollständige Bild ergänzt unser zweiwöchiger Mobile Security Teardown ein manuelles OWASP-Audit und einen Maßnahmenplan mit Kostenschätzung.

Fazit

MobSF ist ein gutes Werkzeug, das für die falsche Aufgabe eingesetzt wird, wenn man seinen Score als Urteil behandelt. Scannen Sie den Release-Build, trennen Sie Rauschen von Befunden, überprüfen Sie die grünen Haken und auditieren Sie die Logik von Hand. Die Zahl ist weniger wichtig als die Liste echter, bewerteter Lücken, die dabei herauskommt.

Häufige Fragen

Was ist MobSF?

MobSF (Mobile Security Framework) ist ein Open-Source-Tool, das Binärdateien von Android- und iOS-Apps analysiert. Die statische Analyse prüft Manifest, Code, Bibliotheken und Konfiguration und erstellt einen Bericht mit einem Security Score von 0 bis 100.

Warum hat sich mein MobSF-Score zwischen zwei Scans derselben App verändert?

Der häufigste Grund ist der Build-Typ. Ein Debug-Build enthält Einstellungen wie Debuggable-Flags und Testkonfiguration, die ein Release-Build nicht hat, und der Scanner zieht dafür Punkte ab. In einem unserer Audits gingen 6–7 der 52 Punkte, die eine App verlor, allein auf den Build-Typ zurück. Scannen Sie immer den Build, den Ihre Nutzer installieren.

Kann eine MobSF-Prüfung, die als sicher markiert ist, falsch sein?

Ja. Statische Analyse gleicht Muster ab; sie versteht keine Absicht. Bei einem Audit einer Banking-App waren zwei Prüfungen, die der Scanner als sicher meldete, False Positives. Jede wichtige Prüfung, ob bestanden oder nicht, verdient einen manuellen Blick.

Was erkennt MobSF nicht?

Ein statischer Scan sieht die Binärdatei, nicht die Geschäftslogik. Er kann nicht beurteilen, ob sich ein Authentifizierungsablauf umgehen lässt, ob ein biometrischer Login an einen Schlüssel gebunden ist oder ob sensible Daten im jeweiligen Kontext korrekt gespeichert werden. Dafür braucht es ein manuelles Audit, zum Beispiel anhand der OWASP Mobile Top 10 (2024).

Kann Mobian unseren MobSF-Bericht erklären?

Ja. Wenn Sie uns Ihre eigene APK oder Ihren MobSF-Bericht schicken, erhalten Sie eine einseitige Einschätzung: was echt ist, was Rauschen durch den Build-Typ ist und was ein fälschliches „sicher“ sein könnte. Wir tun das nur auf Wunsch des App-Inhabers – die öffentliche App eines Unternehmens scannen wir nie ungefragt.

Kostenlose Einschätzung · unverbindlich

Sie planen ein Projekt mit diesem Stack?

Wir haben mit den Tools gearbeitet, über die wir schreiben. Erzählen Sie uns von Ihrem Projekt und holen Sie sich eine Zweitmeinung von Engineers, die damit Produkte ausgeliefert haben.

  • 1Wir sehen uns Ihr Produkt, Ihren Tech-Stack und Ihre Roadmap an
  • 2Wir benennen Risiken, die wir aus ähnlichen Projekten kennen
  • 3Innerhalb von 48 Stunden erhalten Sie eine Teamaufstellung und einen groben Zeitplan

Erzählen Sie uns von Ihrem Projekt

Lieber zuerst sprechen? 30-Minuten-Gespräch buchen