Die meisten Mobile-Security-Programme in Unternehmen haben dasselbe Problem: Sie testen mobile Apps noch immer auf physischen Geräten. Und da Apple den Zugriff auf aktuelle iOS-Geräte einschränkt, bringen viele gängige Ansätze Sicherheitsteams keinen klaren Blick mehr auf das Laufzeitverhalten. Damit wird es schwieriger, Sicherheitskontrollen zu überprüfen, Befunden auf den Grund zu gehen und belastbare Beweismittel ans Tageslicht zu bringen. 

Dieses Problem ist deshalb so relevant, weil heute viele sensible Abläufe, regulierte Daten und letztlich das Kundenvertrauen über mobile Apps verwaltet werden. Für die meisten Organisationen ist die mobile App daher nicht mehr nur ein weiterer Kanal: Sie ist ein geschäftskritisches System. Sicherheitsverantwortliche müssen die Risiken im Mobile-Bereich mitdenken, doch traditionellen Testmethoden für mobile Apps bieten nicht mehr dasselbe Maß an Validierung – besonders auf modernen iOS- und iPadOS-Geräten. 

Dieser Beitrag zeigt auf, wo die verschiedenen Ansätze scheitern und wie umfassende mobile Sicherheitstests tatsächlich aussehen sollten.

Steigende Anforderungen für Teams in EMEA

Die Validierungslücke ist ein globales Problem, doch Organisationen in Europa, dem Nahen Osten und Afrika stehen nicht nur technisch, sondern auch regulatorisch unter Druck: 

  • DORA: verpflichtet EU-Finanzunternehmen, ihre digitale operative Resilienz durch regelmäßige Tests nachzuweisen, wobei für bedeutende Institute bedrohungsgeleitete Penetrationstests (TLPT) – ausgerichtet an Rahmenwerken wie TIBER-EU – erwartet werden. 
  • Artikel 32 DSGVO: verlangt von Organisationen, die Wirksamkeit ihrer Sicherheitsmaßnahmen regelmäßig zu testen, zu bewerten und zu evaluieren – was sich ohne Laufzeit-Sichtbarkeit nur schwer nachweisen lässt. 
  • NIS2: weitet die Pflichten zum Cybersicherheits-Risikomanagement und zur Meldung von Vorfällen auf wesentliche und wichtige Einrichtungen in der gesamten EU aus – einschließlich vieler Organisationen, deren mobile Apps regulierte Abläufe verarbeiten. 

Punktuelle Berichte und statische Befunde lassen sich vor europäischen Aufsichtsbehörden und Prüfern zunehmend schwer verteidigen. Die wiederholbare, nachweisproduzierende Validierung wird zur Erwartung, nicht zur Ausnahme. 

Das iOS-Problem, das zu groß ist, um es zu ignorieren

Jahrelang betrachteten viele Sicherheitsteams gejailbreakte physische Geräte als praktische Behelfslösung für tiefere iOS-Tests. Sie kauften ältere Telefone auf dem Sekundärmarkt, bewahrten bestimmte Betriebssystemversionen auf und nutzten sie, um den nötigen Zugang zu erhalten und so Dateien zu inspizieren, Verhalten zu überwachen und Sicherheitsbefunde zu untersuchen. 

Doch diese Behelfslösung skaliert nicht mehr. Geräte müssen oft zwischen Teammitgliedern rund um die Welt verschickt werden, was Tests um Tage oder gar Wochen verzögern kann. Und wird ein Gerät „gebrickt“ (unbrauchbar gemacht), aktualisiert oder anderweitig verändert, ist es für Tests möglicherweise gar nicht mehr verwendbar. 

Zudem nutzen Anwender aktuelle iOS-Versionen, während viele Testumgebungen in Unternehmen hinterherhinken. Mit jedem neuen Apple-Release vergrößert sich diese Lücke und erschwert es, das App-Verhalten in den wichtigsten Umgebungen zu validieren. 

Das Testen auszulagern, mehr Hardware hinzuzufügen oder mehr Scans durchzuführen kann die Aktivität ausweiten, löst aber das Kernproblem nicht: Das moderne iOS begrenzt die Laufzeit-Sichtbarkeit, die Teams benötigen, um das tatsächliche Verhalten einer App zu validieren. Mehr Tests bedeuten nicht automatisch mehr Nachweise. 

Wo jeder gängige Ansatz zu kurz greift

Die meisten Teams ignorieren die mobile Sicherheit nicht. Sie nutzen Werkzeuge und Dienste, die seit Jahren sinnvoll sind: ausgelagerte Penetrationstests, physische Gerätelabore sowie statische und/oder dynamische Scans. Jeder dieser Ansätze kann echte Probleme aufdecken. Das Problem ist jedoch, dass keiner für sich allein den Teams vollständige, wiederholbare Sichtbarkeit dafür bietet, wie die App mit Daten umgeht. 

Binäranalyse kann Muster finden, aber das Laufzeitverhalten nicht belegen

Die Binäranalyse ist nützlich, um wahrscheinliche Risiken aufzuzeigen, validiert das Laufzeitverhalten aber nicht vollständig. Sie kann das Anwendungspaket inspizieren, aber nicht zuverlässig zeigen, wie die App über die Laufzeit mit Gerätediensten, System-APIs, sensiblen Daten oder Schutzmechanismen auf Betriebssystemebene interagiert. 

Wie das zu Fehlalarmen führt 

Binäranalysewerkzeuge können verdächtige Muster in einer ausgelieferten mobilen App erkennen, aber nicht vollständig validieren, wie sich die App im laufenden Betrieb verhält. Dadurch erhalten Sicherheitsteams zwar Erkenntnisse über potenzielle Risiken, verfügen jedoch nicht über genügend Laufzeitkontext, um beurteilen zu können, ob ein Risiko tatsächlich besteht, unter welchen Bedingungen es auftritt oder wie es reproduziert und behoben werden kann. Das Ergebnis: mehr manuelle Validierungsarbeit, mehr Fehlalarme und weniger Vertrauen in die abschließende Bewertung. 

Häufige Gründe: 

  • Unzureichender Laufzeitkontext: Binärscans zeigen, was im App-Paket enthalten ist, nicht, wie sich die App im laufenden Betrieb verhält. 
  • Höheres Risiko von Fehlalarmen: Werkzeuge können riskant wirkende Muster kennzeichnen, doch fehlt ihnen der Kontext, um zu bestimmen, ob diese eine reale Gefährdung widerspiegeln. 
  • Höherer manueller Ermittlungsaufwand: Befunde erfordern oft Nacharbeit, um zu bestätigen, ob sie im konkreten Fall relevant sind. 

Begrenzter Geräte- und OS-Kontext: Scans validieren nicht, wie sich die App während der Ausführung über Gerätedienste, betriebssystemspezifisches Verhalten, Berechtigungen, Sitzungen und die Aktivität von Dritt-SDKs hinweg verhält. 

Ausgelagerte Penetrationstests bieten Fachwissen, aber keine kontinuierliche Validierung 

Externe Penetrationstester bringen tiefes Fachwissen mit, können aber nur punktuell eingesetzt werden. Mobile Tester verbringen oft Tage mit der Vorbereitung von Geräten und Umgebungen, bevor die fortgeschrittenen Tests beginnen, was die verbleibende Zeit für tiefere Untersuchungen begrenzt. Ein Telekommunikationskunde beschrieb, dass die Einrichtung Tage dauerte und die gesamte Pentest-Zeit 115 Stunden pro App überstieg. Nach Abschluss des Auftrags besitzt die Organisation einen Bericht, aber keine interne Validierungsfähigkeit – obwohl sich die App vor der nächsten Bewertung vielfach ändern kann. 

Häufige Gründe: 

  • Release-Drift: Wird eine App jährlich oder periodisch getestet, kann sich die Codebasis vor der nächsten Bewertung vielfach ändern. Das schafft eine wachsende Lücke zwischen der bewerteten Version und der, die Anwender tatsächlich nutzen. 
  • Hoher Einrichtungsaufwand: Mobile Pentests erfordern oft manuelle Gerätevorbereitung, Zertifikatseinrichtung, App-Beschaffung und Umgebungskonfiguration, bevor die tieferen Tests beginnen. 
  • Weniger Zeit für erweiterte Tests: Wenn so viel Zeit für die Vorbereitung der Umgebung aufgewendet wird, bleibt weniger Zeit für die höherwertige Arbeit, für die Käufer zu zahlen glauben.

Physische Gerätelabore verursachen Abdeckungsprobleme und operativen Ballast 

Physische Gerätelabore bieten Teams direkten Zugang zu echter Hardware, was für gezielte Tests über Gerätemodelle und Betriebssystemversionen hinweg nützlich sein kann. Doch diese Kontrolle hat ihren Preis. Geräte müssen beschafft, konfiguriert, aktualisiert, zurückgesetzt, geteilt und ersetzt werden, und kleine Unterschiede im Gerätezustand oder in der Einrichtung können die Ergebnisse verändern. 

Das Ergebnis: mehr operativer Aufwand, weniger Konsistenz zwischen Untersuchungen und ein Test-Workflow, der sich mit der Zeit schwerer reproduzieren und skalieren lässt. Dadurch werden Befunde schwerer erneut testbar und teamweit validierbar. 

Wie physische Geräte Lücken schaffen: 

  • Hoher Betriebsaufwand: Geräte müssen beschafft, konfiguriert, aktualisiert, zurückgesetzt, gelagert, geteilt und ersetzt werden, bevor Teams überhaupt mit dem Testen beginnen können. 
  • Uneinheitliche Umgebungen: Unterschiede bei Telefonmodellen, Betriebssystemversionen und Geräteeinstellungen können zu unterschiedlichen Ergebnissen zwischen Testern und Untersuchungen führen. 
  • Schwache Replizierbarkeit: Physische Geräte erschweren es, exakt dieselben Testbedingungen über die Zeit oder teamweit wiederherzustellen. 
  • Langsamere Zusammenarbeit: Das Teilen von Hardware zwischen Teammitgliedern, besonders standortübergreifend, verursacht Verzögerungen und erschwert die Skalierung der Tests. 

Wie diese Lücken zum Risiko werden: 

  • Unvollständige Transparenz: Sicherheitsteams verschwenden Zeit mit der Jagd nach Fehlalarmen und riskieren dennoch, das Wichtigste zu übersehen. 
  • Inkonsistente Umgebungen: Befunde variieren je nach Gerät, Betriebssystem und Einrichtung, was das Vertrauen in die Ergebnisse mindert. 
  • Schwache Replizierbarkeit: Wenn Teams dieselben Bedingungen nicht wiederherstellen können, dauern erneutes Testen und Behebung länger als nötig. 
  • Begrenzte Beweiskraft: Wenn Teams das Verhalten nicht direkt überprüfen können, erhalten Führung, Prüfer und Regulierungsbehörden weniger Nachweise und mehr Mutmaßungen. 

Was Teams brauchen, um die mobile Validierungslücke zu schließen 

Um diese Lücken zu schließen, brauchen Sicherheitsteams mehr als ein weiteres Testwerkzeug. Sie brauchen eine kontrollierte Umgebung, in der sie einen direkten Einblick in das Verhalten mobiler Apps erhalten, Bedingungen verlässlich repliziert werden können und die Abhängigkeit von knapper physischer Hardware sinkt. 

Das beginnt mit drei Dingen: 

  • Aktueller Geräte- und OS-Zugriff: Teams brauchen die Möglichkeit, echte iOS-, iPadOS- und Android-Umgebungen bei Bedarf hochzufahren – einschließlich aktueller Versionen –, ohne das passende Telefon suchen zu müssen oder von einem alternden, jailbreakbaren Gerät abhängig zu sein. 
  • Mehr Einblick ohne die Einschränkungen physischer Geräte: Teams brauchen Zugang zu Low-Level-Komponenten eines Mobilgeräts, um das Laufzeitverhalten zu inspizieren, zu analysieren, wie Apps mit Gerätediensten und sensiblen Daten interagieren, und Befunde auf eine Weise zu untersuchen, die physische Geräte nicht mehr zuverlässig unterstützen. 
  • Replizierbare Tests und verwendbare Beweismittel: Teams brauchen stabile Umgebungen, die sie über Untersuchungen, Tester und Releases hinweg wiederherstellen können, und die dabei Nachweise erbringen, die in Verfahren genau wie in Compliance-Fragen und bei Prüfungen durch die Unternehmensführung Bestand haben. 

Mobile Sicherheitsvalidierung ist entscheidend für eine umfassende Lösung

Ohne diese drei Dinge bleiben Teams im selben Kreislauf gefangen: 

  • Sie vergeuden Zeit mit der Verwaltung von Geräten, statt das Verhalten zu untersuchen. 
  • Sie haben Schwierigkeiten, Befunde über Tester und Releases hinweg zu reproduzieren. 
  • Sie müssen sich auf eine lediglich partielle Transparenz verlassen, auch wenn es für riskante Entscheidungen mehr Nachweise bräuchte.

Skalieren Sie die mobile Sicherheitsvalidierung ohne die Grenzen physischer Geräte 

Viper gibt Sicherheitsteams die Umgebung, die sie benötigen, um zu analysieren, wie sich mobile Apps über die Laufzeit tatsächlich verhalten. MATRIX™ liefert Sicherheitsteams Risikoanalysen und -Reporting-Funktionen, um diese Befunde in nutzbare Sicherheitsnachweise zu verwandeln. 

In Kombination helfen sie Teams: 

  • zu beobachten, wie Anwendungen während der Ausführung mit sensiblen Daten, Sitzungen, Netzwerkverkehr und Sicherheitskontrollen umgehen. 
  • Tests über Gerätemodelle, Betriebssystemversionen und Untersuchungen hinweg konsistenter zu reproduzieren. 
  • technische Befunde in Framework-konforme Berichte für Sicherheits-, Audit- und Compliance-Teams zu übersetzen. 
  • stärkere Nachweise zu erzeugen, dass mobile Anwendungen Kontrollen durchsetzen und sensible Daten wie beabsichtigt schützen. 
  • Genau das ermöglicht es Organisationen, vom mobilen Testen zur mobilen Sicherheitsvalidierung überzugehen. 

Die Ergebnisse haben hohen Praxiswert: AppSec-Teams können mobile Apps auf aktuellen Betriebssystemversionen validieren. Sicherheits- und Compliance-Teams können auf Abruf stärkere Nachweise erbringen. DevSecOps-Teams können das Testen näher an den Release rücken, und Pentester können Befunde in einer stabilen Umgebung untersuchen, ohne auf knappe physische Geräte angewiesen zu sein. 

Erhalten Sie in weniger als fünf Minuten iOS-Einblicke auf einem virtualisierten Gerät. 

Starten Sie jetzt die kostenlose Testversion – keine Hardware erforderlich.