Jede App liefert Bibliotheken aus, die niemand im Team geschrieben hat: Analyse, Werbung, Absturzberichte, Push, Zahlungen, Session Replay. The Squad listet jedes SDK im ausgelieferten Build auf und zeigt, wann es startet, was es erhebt und mit welchen Servern es spricht.
Der Check trennt Bibliotheken, die im Paket nur liegen, von solchen, die handeln. Diese Klassen dokumentieren wir:
Wir dekompilieren den Build und lesen ihn. Das Manifest zeigt deklarierte Provider, Receiver, Services und Berechtigungen. Die dekompilierten Klassen zeigen, welches SDK dahintersteckt und wie groß es ist: ein Bericht zählt 315 Klassen für ein Push-SDK, ein anderer 3.622 Klassen für eine Messaging-Plattform. Die Klassenzahl trennt einen Platzhalter von einem voll integrierten SDK.
Jede Bibliothek wird über unser gesamtes Korpus geprüfter Apps korreliert. Ein Befund kommt deshalb mit Kontext: wer dasselbe SDK noch ausliefert, in welcher Version und was es dort getan hat.
Der Zeitpunkt entscheidet über das rechtliche Gewicht eines Befunds. Der Check hält fest, ob ein SDK beim Prozessstart über das Manifest initialisiert, ob es auf die Einwilligung wartet und ob es nach einem Neustart des Geräts zu arbeiten beginnt, bevor die App je geöffnet wurde. Ein Standort-Marketing-Werkzeug, das beim Booten startet, und ein Content Provider, der vor dem Einwilligungsbildschirm initialisiert, sind verschiedene Befunde mit verschiedenen Folgen.
Ein neuer Build wird gegen die zuletzt geprüfte Version abgeglichen, Berechtigung für Berechtigung und SDK für SDK. Apps verändern ihren Stack mit jedem Release, und ein Tracker, der in der letzten Version fehlte, kann in dieser vorhanden sein. Der Vergleich macht das sichtbar.
Einen schriftlichen Bericht mit einem Eintrag je SDK: Name, Version, Klassenzahl, Auslöser, Endpunkte und Datenkategorien, jeweils mit dem Beleg aus dem Binary. Menschliche Fachleute kontrollieren jeden Befund erneut. Der Basis-Knowledge-Graph im Bericht verknüpft SDKs, Endpunkte und Befunde. Für Teams, die dieselbe Sicht über viele Apps brauchen, baut das Data-Angebot SDK- und Tracker-Graphen. Umfang und Pläne stehen auf der Seite Zugang.
Das öffentliche Verzeichnis führt 387+ geprüfte Apps und 262+ kritische Befunde. Diese vollständigen Berichte zeigen SDK-Befunde in echten Apps:
Der kostenlose Check untersucht eine Domain von außen: ausschließlich lesend, von einer europäischen IP-Adresse aus, ohne Login und ohne Payloads. Ein Researcher sieht Ihre Anfrage durch und meldet sich innerhalb eines Werktags. Der Check ist eine erste externe Einschätzung und ergänzt das SDK-Inventar einer vollständigen Prüfung, ohne es zu ersetzen.
Die Pläne für eine vollständige Prüfung stehen auf der Seite Zugang.
Pläne und Preise ansehen → · The Squad kennenlernen → · Standards und Rahmenwerke →
Der erste Check erfolgt ausschließlich lesend, von einer europäischen IP-Adresse aus, ohne Login und ohne Payloads. Ihre Systeme bleiben dabei unverändert.
Bevor die Prüfung beginnt, sieht ein Researcher Ihre Anfrage durch und meldet sich innerhalb eines Werktags. Sie erhalten einen kurzen schriftlichen Report mit unseren Funden, möglichen Angriffsszenarien, dem wirtschaftlichen Schaden und klaren nächsten Schritten, dazu einen Knowledge Graph zu allen Funden. Alles kostenlos.
Analyse, Attribution, Werbung, Session Replay, Push, Tag-Manager-Tags und Werbe-APIs. Jede Bibliothek im Build wird aufgeführt, und der Bericht markiert die, die auf Nutzerdaten wirken.
Ein gebautes Paket genügt. Sie können auch einen GitHub-Link, ein Repository-Archiv oder eine API-Spezifikation senden.
Dann hält der Bericht das fest. Eine geprüfte KI-Assistenten-App zeigt null Tracking-SDKs von Drittanbietern, null hartkodierte Zugangsdaten und keine Initialisierung vor der Einwilligung, und der Bericht listet genau das.
Befunde werden den einschlägigen Artikeln der DSGVO und der ePrivacy-Richtlinie zugeordnet. Die Seite zur DSGVO-Prüfung für Apps beschreibt diesen Teil im Detail.
App-Sicherheitsprüfung · DSGVO-Prüfung für Apps · NIS2 für Softwareanbieter