LaunchLint Academy
Die kurze Antwort
- Mobile Sicherheit beginnt nicht mit einem einzelnen automatische Prüfung. Lege anhand deines Daten- und Bedrohungsmodells fest, welche Kontrollen für Speicherung, Kryptografie, Authentifizierung, Netzwerk, Plattform, Code und Datenschutz gelten.
- Eine statische Projektdateien-Prüfung findet wichtige Hinweise früh. Sie ersetzt weder Laufzeittests noch Backend-Prüfung oder einen risikogerechten Penetrationstest.
- Arbeite die Checkliste nicht erst am Tag der Einreichung ab. Lege sie als Release-Gate im Projekt an, verknüpfe jeden Punkt mit dem zuständigen Commit oder Store-Feld und wiederhole betroffene Prüfungen nach jeder Änderung an Abhängigkeiten, Berechtigungen, Umgebungswerten oder Metadaten. Speichere keine Secrets oder personenbezogenen Testdaten im Nachweis. Für die finale Freigabe sollten Entwicklung, Produkt und die Person mit Zugriff auf die Store-Konsole denselben Build beurteilen. So wird aus einer einmaligen Kontrolle ein reproduzierbarer Prozess, der auch nach einer Ablehnung oder bei einem späteren Update erklärt, welcher Stand tatsächlich geprüft wurde.
1. Daten und Bedrohungen erfassen
Klassifiziere Zugangsdaten, persönliche Inhalte, Standort, Zahlungen und Geschäftsgeheimnisse sowie mögliche Angreifer und Schäden.
Prüfe daten und bedrohungen erfassen nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für daten und bedrohungen erfassen festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
2. Secrets aus dem Client halten
Private API-Schlüssel, Service Credentials und Signiermaterial dürfen nicht im mobilen Bundle oder in öffentlich erreichbarer Konfiguration landen.
Prüfe secrets aus dem client halten nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für secrets aus dem client halten festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
3. Sichere lokale Speicherung
Tokens und sensible Werte gehören in Plattform-Keychain beziehungsweise Keystore statt Logs, AsyncStorage, SharedPreferences oder Klartextdateien.
Prüfe sichere lokale speicherung nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für sichere lokale speicherung festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
4. Authentifizierung und Autorisierung
Der Server prüft Sitzung und Berechtigung für jede sensible Aktion; lokale UI-Sperren sind keine Zugriffskontrolle.
Prüfe authentifizierung und autorisierung nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für authentifizierung und autorisierung festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
5. Netzwerk absichern
TLS, Zertifikatsprüfung, produktive Endpunkte und Verbote für unnötigen Klartextverkehr müssen in beiden Plattformen zusammenpassen.
Prüfe netzwerk absichern nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für netzwerk absichern festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
6. Plattformgrenzen kontrollieren
Deep Links, exportierte Android-Komponenten, URL Schemes, WebViews, Zwischenablage und Screenshots können Daten über App-Grenzen tragen.
Prüfe plattformgrenzen kontrollieren nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für plattformgrenzen kontrollieren festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
7. Abhängigkeiten und Updates
Pakete, native SDKs und Build-Konfiguration werden inventarisiert, aktualisiert und auf unnötige Funktionen sowie bekannte Risiken geprüft.
Prüfe abhängigkeiten und updates nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für abhängigkeiten und updates festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
8. Security-Gate betreiben
Statische Findings, Laufzeittests, Backend-Kontrollen, Datenschutz und Incident-Verantwortung werden vor jedem Release gemeinsam abgenommen.
Prüfe security-gate betreiben nicht als isolierten Haken. Ordne die Aussage dem exakten Release-Build, einer verantwortlichen Person und einem überprüfbaren Nachweis zu. Wiederhole den Ablauf auf einem sauberen Gerät und dokumentiere Abweichungen, bevor du die Store-Einreichung fortsetzt.
Belastbarer Abnahmenachweis
- Produktionswert für security-gate betreiben festgehalten
- Betroffene Datei oder Store-Einstellung verlinkt
- Erwartetes und beobachtetes Verhalten verglichen
- iOS- und Android-Unterschiede bewusst geprüft
- Offene Unsicherheit mit Owner und Termin versehen
- Release bei einem blockierenden Widerspruch gestoppt
Häufige Fragen
Ist OWASP MASVS nur für Banken?
Nein. Die Kontrollgruppen lassen sich risikogerecht auf kleine und große Apps anwenden.
Kann ein Prüfung der Projektdateien alle Sicherheitslücken finden?
Nein. Laufzeit, Server, Geschäftslogik und echte Artefakte brauchen weitere Prüfungen.
Darf ein öffentlicher API-Key in die App?
Nur wenn er ausdrücklich als öffentlicher Client-Identifier gedacht und serverseitig wirksam begrenzt ist.
Führt LaunchLint einen Pentest durch?
Nein. LaunchLint ist eine statische, release-orientierte Prüfung und keine vollständige Penetrationsprüfung.