Montagmorgen, 8:47 Uhr. Ein Nutzer öffnet seine Banking-App, hält das Smartphone an ein Kartenterminal, tippt auf „Bezahlen bestätigen“. Die App checkt kurz das Security Patch Level des Geräts – grün, alles gut, Transaktion durch. Die App winkt durch – und das Gerät schleppt seit drei Tagen ein kritisches Kernel-Update im Wartezustand mit, von dem die Banking-App nie erfahren hat. Das Geld ist dann nicht „weg wegen Magie“. Sondern weil Pending Update und High-Value-Action gleichzeitig laufen.

Das ist kein Horrorfilm-Szenario. Das ist die Systemlogik, die Millionen Android-Geräte bis vor wenigen Tagen tatsächlich gefahren sind. Und genau hier setzt die neue AndroidX Security State Bibliothek an.

Der Denkfehler, der seit Jahren im System steckt

Google hat am 17. September das Stable Release von AndroidX Security State 1.1.0 sowie Security State Provider 1.0.0 veröffentlicht. Die AndroidX-Release-Notes zu Security-State listen die API-Änderungen für Teams, die die Integration planen. Klingt nach trockener Versionsnummer-Bürokratie. Ist es nicht. Das ist der Moment, in dem Google offiziell zugibt: Das alte Security Patch Level war eine Lüge mit gutem Marketing.

Bisher war die Logik simpel – fast zu simpel. Ein Gerät zeigt ein einziges SPL-Datum an. Zum Beispiel „1. September“. Und dieses Datum sollte suggerieren: Alles, was bis zu diesem Stichtag an Sicherheitslücken bekannt war, ist geschlossen. Punkt.

Das Problem: Diese eine Zahl verschweigt drei völlig unterschiedliche Zustände. Was tatsächlich installiert ist. Was öffentlich bekannt ist. Und was bereitsteht, aber noch nicht drauf ist. Drei Ebenen, ein Label. Das ist, als würde ein Kühlschrank behaupten „alles frisch“, während im hinteren Fach seit einer Woche ein Joghurt abläuft, von dem niemand weiß.

DSPL, PSPL, ASPL – die drei Ebenen im Klartext

AndroidX Security State bricht das Monolith-SPL auf in drei granulare Werte, jeweils pro Komponente:

Device SPL (DSPL): Was tatsächlich auf dem Gerät installiert ist – offline auslesbar, ohne Netzverbindung. Der Ist-Zustand.
Published SPL (PSPL): Was laut offiziellem Security Bulletin öffentlich als „sollte gepatcht sein“ gilt. Der Soll-Zustand laut Google.
Available SPL (ASPL): Was per IPC vom Update-Client gemeldet wird – ein Patch, der bereits heruntergeladen ist, aber auf die Installation wartet. Der „fast da, aber noch nicht“-Zustand.

Und das Ganze nicht nur für das Betriebssystem als Ganzes, sondern granular für drei Komponentenklassen: das System selbst, die System Modules (also Mainline- und Play-System-Updates) und den Kernel, inklusive der LTS-Versionen (Long-Term Support). Drei Komponenten mal drei Zeitstempel – neun Datenpunkte statt eines einzigen Datums.

Das Pikante daran: Genau die Lücke zwischen DSPL und ASPL ist der Zeitraum, in dem ein Gerät angreifbar bleibt, obwohl der Patch längst auf der Platte liegt. Nicht „ungepatcht, weil unbekannt“. Sondern „ungepatcht, weil noch nicht neu gestartet, noch nicht installiert, noch nicht bestätigt“.

Warum ein grünes SPL nichts über Ihre Angriffsfläche sagt

Hier kommt der Plot Twist, der für Fintech- und MDM-Verantwortliche eigentlich schon länger im Raum stand, nur nie so klar benannt wurde: Ein Gerät kann ein „aktuelles“ SPL anzeigen und trotzdem eine offene Flanke haben. Weil das angezeigte Datum sich auf das Published Level bezieht – nicht darauf, ob der entsprechende Patch auch wirklich installiert ist.

Stellen Sie sich vor, Sie prüfen als App-Security-Verantwortliche jedes Gerät vor einer Kreditkartenautorisierung nur auf das grobe SPL. Grün heißt: durchwinken. Aber grün heißt in Wahrheit nur „das Update wurde veröffentlicht“ – nicht „das Update läuft“. Ein Gerät mit veralteter DSPL, aktuellem PSPL und einem seit Tagen wartenden, aber nie angewendeten ASPL-Patch sieht auf den ersten Blick identisch aus wie ein vollständig gehärtetes Gerät. Bis zum nächsten Reboot – oder bis genau diese noch offene Lücke irgendwo scharf wird.

Spoiler: Ein Angreifer, der eine bekannte, öffentlich dokumentierte Schwachstelle ausnutzt, braucht keinen Zero-Day. Er braucht nur ein Gerät, dessen Update-Client seit einer Weile ein Pending-Update mit sich herumträgt, das der Nutzer nie bestätigt hat, weil kein Prompt kam. Genau diese Lücke zwischen „verfügbar“ und „installiert“ ist der eigentliche Blindflug – nicht die Schwachstelle selbst.

Die drei Komponentenklassen – und warum jede einzeln zählt

Wenig überraschend hat Google die Abdeckung nicht auf das Betriebssystem-Kernpatch beschränkt. Drei Bereiche werden separat abgebildet:

System: Der klassische Android-Systempatch, wie man ihn aus den Einstellungen kennt.
System Modules: Mainline-Module und Play-System-Updates – also die Komponenten, die Google seit Jahren nutzt, um Sicherheitsfixes unabhängig vom OEM-Update-Zyklus auszurollen. Genau diese Modularität war eigentlich mal als Antwort auf das Fragmentierungsproblem gedacht. Jetzt bekommt sie ihre eigene, transparente Statusebene.
Kernel: Inklusive der LTS-Versionen (Long-Term Support), die auf vielen Geräten monatelang ohne größere Versionswechsel laufen, aber punktuell Sicherheitspatches erhalten.

Der Clou: Jede dieser drei Klassen kann ihren eigenen DSPL-PSPL-ASPL-Dreiklang haben. Ein Gerät kann beim System topaktuell sein, während der Kernel-Patch seit einer Woche im ASPL-Zustand feststeckt. Genau diese Granularität macht das neue Modell so viel wertvoller als die alte Ein-Zahl-Anzeige – und genauso viel komplexer in der Auswertung.

Die Defense-Logik: DSPL gegen ASPL vor High-Value-Actions

Hier wird’s konkret für alle, die Banking-Apps, Payment-Flows oder Credential-Enrollment-Prozesse auf Android verantworten – und genau diese Leserschaft adressieren wir bei digital-magazin.de im Security-Ressort regelmäßig. Die naheliegende – und aus Sicht von Julia Wolf dringend überfällige – Konsequenz: Vor jeder High-Value-Aktion nicht nur das PSPL abfragen, sondern DSPL gegen ASPL vergleichen.

Das Prinzip in drei Schritten:

Abfrage: Die App liest über die Security State Provider API sowohl den installierten Zustand (DSPL) als auch den verfügbaren, aber noch nicht angewendeten Zustand (ASPL) aus – für System, Module und Kernel.
Vergleich: Klafft eine Lücke zwischen DSPL und ASPL bei einer sicherheitsrelevanten Komponente, ist das ein Signal: Ein Patch liegt bereit, wurde aber nicht installiert.
Reaktion: Statt die Transaktion einfach durchzulassen, blockiert die App den High-Value-Flow – Tap-to-Pay, Kreditkarten-Enrollment, biometrische Neuregistrierung – bis das Update tatsächlich installiert ist. Oder sie erzwingt zumindest einen expliziten Nutzer-Prompt, der auf die Lücke hinweist.

Das ist keine Raketentechnik. Das ist der Unterschied zwischen „wir haben eine Checkbox abgehakt“ und „wir haben tatsächlich verstanden, was diese Checkbox bedeutet“. Und genau dieser Unterschied entscheidet im Ernstfall darüber, ob eine Kompromittierung vor oder nach der Transaktion passiert.

Optional, aber sinnvoll: der CVE-Audit-Layer

Wer es genauer wissen will, kann die reinen SPL-Werte zusätzlich mit Datenbanken wie OSV (Open Source Vulnerabilities) oder dem offiziellen Android Security Bulletin abgleichen. Damit lässt sich nicht nur feststellen, dass eine Lücke zwischen DSPL und ASPL existiert, sondern auch, wie kritisch die betroffenen, noch nicht installierten Patches tatsächlich sind. Ein Pending-Update, das eine niedrig eingestufte Denial-of-Service-Lücke schließt, rechtfertigt vermutlich keinen kompletten Blockade-Flow. Ein Pending-Update, das eine kritische Privilege-Escalation im Kernel adressiert, dagegen schon.

Das ist Feinabstimmung, keine Pflicht. Aber wer im Fintech-Bereich unterwegs ist und regulatorisch ohnehin dokumentieren muss, warum bestimmte Transaktionen geblockt wurden, tut sich mit diesem zusätzlichen Kontext einen Gefallen.

Warum das mehr ist als eine API-Fußnote

AndroidX: Smartphone neben Payment-Terminal — Tap-to-Pay und ausstehendes Systemupdate (Symbolbild)

Man könnte jetzt sagen: Ist doch nur eine neue Bibliothek, Version 1.1.0, wird schon irgendwann in Apps landen. Aber genau diese Haltung ist der Grund, warum Monolith-SPL-Checks jahrelang als ausreichende Härtung galten – obwohl sie es nie waren.

Die unbequeme Wahrheit: Jede App, die bisher nur die grobe SPL-Systemeinstellung ausgelesen hat, hat im Kern eine Vertrauensannahme getroffen, die sie nie überprüft hat. Nämlich, dass „gepatcht laut Bulletin“ gleichbedeutend ist mit „gepatcht auf diesem konkreten Gerät gerade jetzt“. Das war schon immer eine Fiktion. Jetzt gibt es endlich die Werkzeuge, um diese Fiktion aufzulösen – und wer sie nicht nutzt, entscheidet sich aktiv für den Blindflug.

Die Verantwortung wandert Richtung App-Entwicklung

Das Spannende – Verzeihung, das Bemerkenswerte – an dieser Umstellung: Google gibt die Kontrolle über den Sicherheitsstatus nicht mehr allein an das Betriebssystem, sondern reicht sie über eine offene API an die App-Ebene weiter. Fintech-Apps, MDM-Lösungen, Enterprise-Mobility-Management-Systeme – sie alle können jetzt selbst entscheiden, wie streng sie auf Pending-Updates reagieren. Das verschiebt Verantwortung. Wer als App-Betreiber künftig nur noch die alte, grobe SPL-Zahl prüft, kann sich nicht mehr darauf berufen, dass ihm die granulare Information gefehlt hätte. Sie ist jetzt da. Ungenutzt zu bleiben, ist eine Entscheidung – keine technische Notwendigkeit.

Diese Verschiebung ähnelt strukturell dem, was in anderen Bereichen der Identitäts- und Zugriffskontrolle längst passiert ist. Wer schon einmal mit Nutzenden über Android-Security-Patches und dem Delta zwischen Bulletin und Gerät zu tun hatte, kennt das Muster: Neue, granularere Sicherheitsmechanismen bringen zunächst mehr Aufklärungsaufwand mit sich, bevor sie tatsächlich Wirkung entfalten. Der Unterschied zwischen „technisch verfügbar“ und „in der Breite tatsächlich genutzt“ ist bei Security-Features historisch fast immer größer, als man hofft.

Was das für Ihr Patch-Management-Team bedeutet

Für alle, die operativ für Mobile Device Management oder App-Security zuständig sind, ergeben sich aus dem neuen Modell ein paar sehr konkrete To-Dos:

Audit der bestehenden Checks: Prüfen Sie, ob Ihre Banking- oder Payment-App aktuell nur das grobe SPL abfragt – oder bereits differenziert zwischen installiert und verfügbar.
Policy-Definition pro Komponente: Legen Sie fest, wie streng Sie bei System-, Modul- und Kernel-Lücken jeweils reagieren wollen. Nicht jede ASPL-Lücke verdient dieselbe Behandlung.
Prompt statt Stille: Wenn ein Update pending ist, sollte der Nutzer nicht im Dunkeln gelassen werden. Ein klarer Hinweis – „Bitte installieren Sie das verfügbare Sicherheitsupdate, bevor Sie fortfahren“ – ist minimalinvasiv und maximal transparent.
Integration in MDM-Reporting: Enterprise-Flotten sollten die DSPL-ASPL-Lücke als eigene Kennzahl im Fleet-Dashboard führen, nicht nur als Randnotiz im Compliance-Report.

Das klingt nach viel Aufwand für eine scheinbar kleine API-Erweiterung. Ist es auch. Aber der Aufwand steht in einem deutlich besseren Verhältnis zum Risiko als das, was viele Teams bisher an SPL-Prüfung betrieben haben: nämlich fast nichts.

Der Unterschied zwischen Perimeter-Denken und Endpoint-Realität

Wer Zero Trust ernst nimmt – wir bei digital-magazin.de haben das Gerätegesundheit und Patch-Stand als Zugangskriterium schon länger als Pflichtstück diskutiert –, kennt das Grundproblem: Ein System kann formal „aktuell“ gemeldet werden und trotzdem eine offene Flanke haben, weil zwischen Veröffentlichung und tatsächlich installiertem Stand Zeit verstreicht. Bei Mobilgeräten mit Banking-Apps landet dasselbe Zeitfenster direkt im Portemonnaie der Endnutzenden.

Grenzen des Modells – und was es nicht löst

Ehrlicherweise: AndroidX Security State ist kein Wundermittel. Die Bibliothek liefert Transparenz über den Patch-Zustand – sie erzwingt aber nicht automatisch, dass Hersteller schneller patchen, dass Nutzer Updates schneller installieren, oder dass jede App die neuen APIs überhaupt integriert. Ohne aktive Nutzung durch die App-Entwickler bleibt die granulare Information ungenutzt, und das alte Monolith-SPL-Verhalten setzt sich faktisch fort.

Außerdem gilt: Die Abdeckung bezieht sich auf System, Module und Kernel. Drittanbieter-Apps mit eigenen, unabhängigen Sicherheitslücken – etwa in Business-Logik oder Authentifizierungsflüssen – fallen nicht unter dieses Modell. Wer sich beispielsweise mit Identitätsbetrug über synthetische Medien beschäftigt, findet dazu andere Ansätze, etwa im Beitrag über Schutzmaßnahmen gegen Deepfake-basierte Angriffe – ein völlig anderes Bedrohungsmodell, aber mit derselben Grundlektion: Transparenz über den tatsächlichen Zustand ist die Voraussetzung für jede sinnvolle Verteidigungsentscheidung, nicht die Verteidigung selbst.

Die Update-Lücke ist ein Governance-Problem, kein reines Technik-Problem

Das eigentlich Bemerkenswerte an der DSPL-ASPL-Unterscheidung ist, dass sie ein Governance-Thema technisch sichtbar macht, das vorher im Verborgenen lag: Wer trägt die Verantwortung, wenn ein Update verfügbar, aber nicht installiert ist? Der Nutzer, der den Reboot nicht bestätigt hat? Der OEM, der den Rollout gedrosselt hat? Die App, die nie geprüft hat, ob ein Pending-Update existiert?

Mit der neuen API lässt sich diese Frage nicht mehr wegdiskutieren. Die Information ist da. Die Verantwortung liegt jetzt sichtbar bei der App-Ebene – zumindest bei allen Apps, die High-Value-Transaktionen verarbeiten und die neue Bibliothek nicht integrieren. Das ist unbequem für alle, die bisher mit „wir haben das SPL geprüft, war grün“ argumentiert haben. Aber unbequem ist manchmal genau das, was Sicherheitsarchitektur braucht.

Ähnlich verhält es sich mit organisatorischen Reaktionsprozessen bei Kompromittierungen: Auch dort zeigt sich immer wieder, dass die technische Erkennung einer Lücke wenig nützt, wenn die Reaktionskette dahinter fehlt oder zu langsam greift – ein Muster, das sich etwa in den Empfehlungen zur Incident-Response bei Token-Diebstahl nach NIST 8587 wiederfindet. Erkennung ohne Reaktion ist Theater. Reaktion ohne Erkennung ist unmöglich. Beides zusammen ist die eigentliche Härtung.

Ehrlich gesagt: Ich halte die DSPL-ASPL-Abfrage vor Tap-to-Pay und Credential-Enrollment für den ersten echten Reifegrad-Test dieser Bibliothek. Wer sie nur als weiteres Telemetrie-Feld im MDM-Dashboard ablegt, hat den Point verpasst. Security State ist dann Daten. Die Härtung beginnt erst, wenn High-Value-Actions an den Vergleich gebunden werden – und Pending Updates nicht mehr still im Hintergrund mitreisen.

Die pragmatische Einordnung für Security-Teams

Was heißt das jetzt ganz praktisch, ohne Alarmismus? Erstens: Die neue Bibliothek ist ein Werkzeug, kein automatischer Schutzschild. Zweitens: Wer High-Value-Transaktionen auf Android verantwortet – ob Banking, Payment oder Credential-Enrollment –, sollte die Integration der DSPL-ASPL-Prüfung auf die Roadmap setzen, und zwar nicht als „nice-to-have für Q3 nächstes Jahr“, sondern als Kernbestandteil der Transaktionssicherheit. Drittens: Die Granularität nach System, Modulen und Kernel erlaubt endlich eine differenzierte Risikobewertung, statt einer binären „gepatcht oder nicht“-Entscheidung.

Und viertens, vielleicht der wichtigste Punkt: Diese Umstellung ist ein gutes Beispiel dafür, dass echte Härtung selten spektakulär aussieht. Kein neuer Angriffsvektor macht Schlagzeilen, keine kritische Zero-Day-Lücke wird enthüllt. Stattdessen wird eine bestehende, jahrelang stillschweigend akzeptierte Ungenauigkeit endlich sichtbar gemacht – und damit behebbar. Das ist selten glamourös. Aber es ist genau die Art von Arbeit, die den Unterschied macht zwischen einem System, das im Ernstfall standhält, und einem, das nur so aussieht, als würde es das.

Ein grünes SPL war noch nie eine Garantie. Jetzt gibt es endlich die Werkzeuge, um zu prüfen, ob es überhaupt eine Annäherung an die Wahrheit war.