Geschrieben von Luuk Paans, Innovationsvisionär.

Luuk Paans ist ein Innovationsvisionär mit Fokus auf die Sicherstellung der Einhaltung regulatorischer Vorgaben und den Schutz der Datenintegrität. Er verfügt über umfassende Kenntnisse von Sicherheitsprotokollen und setzt sich dafür ein, Risiken durch die Prüfung kleinster Details zu minimieren.

In diesem Artikel teilt Luuk seine Einblicke dazu, wie nicht-technische Einkaufsteams die richtigen Sicherheitsfragen an Mobile-App-Anbieter stellen können, um Vertrauen aufzubauen und die Datenintegrität sicherzustellen.

Abgrenzung: Die Inhalte basieren auf direkter Expertise in der Sicherheit digitaler Systeme, mit Fokus auf praktische Fragen für nicht-technische Teams.

Sicherheitsfragen für Mobile-App-Anbieter

Nicht-technische Einkaufsteams können die Sicherheit von Mobile-App-Anbietern wirksam bewerten, indem sie gezielte Fragen stellen. Das hilft, Vertrauen aufzubauen und die Datenintegrität sicherzustellen, ohne technisches Fachwissen zu benötigen.

  • Fordern Sie die Einhaltung des OWASP-MASVS-Standards im Vertrag, um Sicherheitsanforderungen konkret zu machen.
  • Fragen Sie nach konkreten Nachweisen für sichere Datenspeicherung, etwa durch die Nutzung von iOS Keychain und Android Keystore.
  • Prüfen Sie, wie die Kommunikation zwischen App und Backend (API) abgesichert ist, zum Beispiel über TLS mit Certificate Pinning.
  • Treffen Sie klare Vereinbarungen über regelmäßige Sicherheitsupdates und Wartungsverantwortlichkeiten nach dem Launch.
  • Bitten Sie um einen aktuellen, anonymisierten Penetrationstest-Bericht als Nachweis externer Sicherheitsvalidierung.

Sicherheitserwartungen bei ausgelagerter Mobile-App-Entwicklung

Sicherheit bleibt vage, sobald ein Anbieter nur allgemeine Beruhigung bietet und den Vereinbarungen kein fester Standard zugrunde liegt. Bei ausgelagerter Mobile-App-Entwicklung beginnt eine brauchbare Erwartung daher nicht mit einzelnen Versprechen, sondern mit einer überprüfbaren Grundlage dafür, was unter Sicherheit fällt. In diesem Kontext übernimmt OWASP MASVS diese Rolle: Es macht Sicherheitsanforderungen vertraglich konkret, sodass Gespräche über Authentifizierung, Autorisierung, API-Sicherheit und Datenverarbeitung nicht in allgemeinen Formulierungen stecken bleiben.

Ohne eine solche gemeinsame Grundlage entsteht schnell Interpretationsspielraum zwischen Auftraggeber und Anbieter. Dann kann die eine Partei davon ausgehen, dass Sicherheit Teil der vereinbarten Lieferung ist, während die andere sie als zusätzlichen Umfang oder spätere Ausarbeitung betrachtet. OWASP MASVS schafft hier Abgrenzung, indem Sicherheitsanforderungen im Vorfeld benennbar werden. Für viele mobile Apps gilt dabei Level 1 als Mindeststandard. Das beantwortet nicht automatisch jedes Projektdetail, verhindert aber, dass die Untergrenze in Angebot, Vertrag und Umsetzung unausgesprochen bleibt.

Security Ownership gehört in dieselbe Diskussion, weil ein Standard allein keine Verantwortlichkeit regelt. Bei Auslagerung muss klar sein, wer dafür verantwortlich ist, Sicherheitsanforderungen in die Lieferung zu übersetzen, und wer beteiligt bleibt, nachdem die App live ist. Gerade Updates nach dem Launch machen diese Unterscheidung sichtbar: Wenn Wartung und Sicherheitsupdates nicht ausdrücklich zugewiesen sind, bleibt unklar, wer neue Sicherheitsanforderungen oder Anpassungen nach dem Launch nachverfolgt. Dann verschiebt sich Sicherheit von einem vereinbarten Lieferbestandteil zu einem offenen Ende.

Für nicht-technische Teams liegt der Kern daher nicht darin, Code selbst zu bewerten, sondern darin, Ansprüche auf einen Standard und auf Verantwortlichkeit zurückführen zu können. Ein Anbieter, der OWASP MASVS als vertragliche Grundlage akzeptiert und Klarheit über Security Ownership und Updates nach dem Launch schafft, macht die Sicherheitserwartung überprüfbar. Fehlt diese Verknüpfung, bleibt auch nach der Auswahl unklar, ob die minimale Sicherheitsgrundlage tatsächlich vereinbart wurde und wer verantwortlich bleibt, sobald die App im Einsatz ist.

Risiken durch versäumte Kontrollen bei der Anbieterauswahl

Sicherheitsverantwortlichkeiten, die nach dem Go-live nicht festgelegt sind, hinterlassen eine direkte Lücke in der Wartung einer mobilen App. Dann bleibt unklar, wer Sicherheitsupdates übernimmt, wer Abweichungen nachverfolgt und wer haftet, wenn personenbezogene Daten durch vermeidbare technische Fehler offengelegt werden. Dadurch verschiebt sich ein Auswahlgespräch von überprüfbaren Vereinbarungen zu Annahmen, während die operativen Folgen erst sichtbar werden, wenn die App bereits im Einsatz ist.

Ein zweites Risiko entsteht, sobald ein Anbieter anhand allgemeiner Beruhigung statt anhand überprüfbarer Sicherheitskontrollen bewertet wird. In dieser Situation fehlt auf Käuferseite die technische Validierung, eine breite Behauptung wie Security-by-Design erhält zu viel Gewicht, und es bleibt verborgen, was tatsächlich in die mobile App aufgenommen wurde. Die Fehlerkette ist konkret: Fehlende Validierung führt zu Vertrauen in allgemeine Aussagen, danach können hartcodierte API-Schlüssel im mobilen Code verbleiben, woraufhin unautorisierter Zugriff auf Backend-Systeme möglich wird. Für ein nicht-technisches Team ist genau das der schwierige Punkt: Die Präsentation wirkt überzeugend, aber die tatsächliche Kontrolle fehlt.

Dieser Mangel an Abgrenzung beeinträchtigt auch das Vertrauen in den Anbieter während der Shortlist-Phase. Solange Security Ownership nicht ausdrücklich mit Datenspeicherung, API-Sicherheit und langfristiger Wartung verknüpft ist, bleibt unklar, ob Sicherheit Teil der Lieferung ist oder später als offener Punkt zurückkommt. Dadurch werden Angebote und Gespräche schwer vergleichbar. Die eine Partei verkauft Vertrauen mit allgemeiner Sprache, während die andere möglicherweise konkreter arbeitet, ohne dass dieser Unterschied sichtbar wird, wenn die Kontrollen nicht im Vorfeld festgelegt sind.

Bei Apps, die personenbezogene Daten verarbeiten, wird daraus kein abstraktes Risiko, sondern ein Governance- und Finanzproblem. Wenn ein vermeidbarer technischer Fehler zu einem Datenleck führt, kann das in rechtlicher Haftung und Bußgeldern nach DSGVO/GDPR enden. Genau deshalb wirkt sich eine vage Anbieterauswahl bis nach der Übergabe aus: Unklare Updates nach dem Launch auf der Vorderseite enden auf der Rückseite in unklarer Verantwortlichkeit, verzögerter Wartung und Haftung bei einem Datenleck.

Wesentliche Sicherheitsaspekte zur Verifizierung

Sicherheitsbehauptungen bleiben vage, wenn ein Mobile-App-Anbieter nicht konkret macht, wie Zugriffe abgeschirmt werden und wie Daten unterwegs geschützt bleiben. In der Shortlist-Phase geht es bei der Verifizierung daher nicht darum, Quellcode zu lesen, sondern um überprüfbare Sicherheitsaspekte und eine erkennbare Grundlage für die Bewertung. OWASP MASVS bietet dafür einen brauchbaren Referenzpunkt für Sicherheitsanforderungen an mobile Apps, während NIST SP 800-163 hilft, diese Bewertung strukturiert anzugehen. Für nicht-technische Teams macht das den Unterschied zwischen allgemeiner Beruhigung und einem Anbieter, der seinen Ansatz entlang überprüfbarer Linien erklären kann.

Authentifizierung und Autorisierung sollten dabei als getrennte Kontrollpunkte auf dem Tisch liegen. Ein Anbieter kann nur dann glaubwürdig über Sicherheit sprechen, wenn klar wird, wie der Zugang zur App festgestellt wird und wie Rechte danach begrenzt werden. Diese Unterscheidung verhindert, dass „eingeloggt sein“ mit „überall Zugriff haben“ verwechselt wird. Für ein Einkaufs- oder Operations-Team ist das vor allem eine Verifizierungsfrage: Kann der Anbieter in verständlicher Sprache erklären, welche Sicherheitsebene bestimmt, wer hineinkommt, und welche Ebene bestimmt, was danach zugänglich ist? Fehlt diese Unterscheidung in Gesprächen oder Angeboten, bleibt unklar, ob die Zugriffskontrolle wirklich durchdacht ist oder nur als allgemeine Eigenschaft präsentiert wird.

API-Sicherheit verlangt eine ebenso direkte Verifizierung, weil die mobile App und die dahinterliegenden Systeme über diese Verbindung Daten austauschen. Die relevante Kontrolle ist hier nicht ein technisches Detail für sich, sondern die Frage, ob der Anbieter nachweisen kann, dass diese Kommunikation bei kritischen mobilen Transaktionen über TLS mit Certificate Pinning abgesichert wird. In der Praxis entsteht das Risiko in dem Moment, in dem eine App Daten an ein Backend sendet und diese Schutzschicht nicht ausdrücklich Teil des Sicherheitsansatzes ist. Dann bleibt ein Kernbestandteil der mobilen Kette von Vertrauen statt von nachweisbarer Abschirmung abhängig, obwohl genau dort sensibler Austausch stattfindet.

Die Datenverarbeitung sollte aus demselben Grund ausdrücklich verifiziert werden. ENISA ordnet Mobile-App-Sicherheit ausdrücklich in den Kontext des Datenschutzes ein, und das macht den Umgang mit Daten zu mehr als einer technischen Nebensache. Ein Anbieter sollte also nicht nur sagen, dass Daten sicher sind, sondern auch zeigen, dass Datenschutz Teil der Art und Weise ist, wie die App bewertet und abgegrenzt wird. In Kombination mit OWASP MASVS und NIST SP 800-163 ergibt sich damit eine praktische Untergrenze für die Anbieterauswahl: Authentifizierung, Autorisierung, API-Sicherheit und Datenverarbeitung müssen jeweils separat benannt und überprüfbar sein. Sobald einer dieser Bestandteile implizit bleibt, verschiebt sich die Bewertung von verifizierbaren Sicherheitsaspekten zu nicht belegten Annahmen über den Mobile-App-Anbieter.

Checkliste mit Sicherheitsfragen an Mobile-App-Anbieter

Sicherheitsbehauptungen bleiben vage, sobald ein Anbieter keinen überprüfbaren Standard nennt, wodurch Gespräche in der Shortlist schnell bei beruhigenden Formulierungen ohne harte Vergleichsbasis stehen bleiben. Nutzen Sie diese Checkliste daher als festen Satz von Sicherheitsfragen an Mobile-App-Anbieter, mit Schwerpunkt auf OWASP MASVS, sicherer Speicherung und Nachweisen aus aktuellen Penetrationstests.

  • Fragen Sie, welches Niveau von OWASP MASVS als Standard für das Projekt angewendet wird. Diese Frage macht sichtbar, ob der Anbieter Sicherheit als vertragliche Anforderung statt als loses Versprechen behandelt. Eine konkrete Antwort verweist auf OWASP MASVS als Grundlage für die Sicherheitsanforderungen der mobilen App. Bleibt die Antwort allgemein, fehlt oft der feste Maßstab, anhand dessen Umfang, Bewertung und Lieferung später geprüft werden können.
  • Fragen Sie, ob OWASP MASVS ausdrücklich in Angebot, Scope oder Vertrag aufgenommen wird. Dadurch wird klar, ob Sicherheit im Vorfeld festgelegt wird oder erst später zum Diskussionsthema wird. Sobald diese Grundlage nicht ausdrücklich benannt ist, entsteht Raum für unterschiedliche Interpretationen während der Umsetzung. Für nicht-technische Teams ist dies eine brauchbare Kontrollfrage, weil sie keinen Code bewerten müssen, um dennoch zu erkennen, ob der Anbieter mit einem erkennbaren Standard arbeitet.
  • Fragen Sie, wie sensible Daten innerhalb der App gespeichert werden. Eine glaubwürdige Antwort verweist auf plattformspezifische sichere Speichermethoden wie iOS Keychain und Android Keystore. Das zeigt, dass der Anbieter sich nicht mit allgemeiner Sprache über Datenverarbeitung begnügt, sondern erklären kann, welche Speichermethoden für sensible Daten verwendet werden. Wird dies nicht klar benannt, bleibt unklar, ob sensible Informationen angemessen abgeschirmt werden.
  • Fragen Sie, wie API-Schlüssel und Benutzertokens innerhalb des App-Codes abgesichert werden. Diese Frage knüpft an dieselbe Kontrolle rund um sichere Speicherung an. Der Anbieter muss hier keine technische Tiefe liefern, sollte aber klar machen, dass sensible Daten nicht lose behandelt werden und derselben Sicherheitsdisziplin unterliegen wie andere sensible Daten in der App. Eine vage Antwort ohne Verweis auf konkrete Speichermethoden erschwert den Vergleich zwischen Anbietern.
  • Bitten Sie um einen aktuellen, anonymisierten Penetrationstest-Bericht zu einem vergleichbaren mobilen Projekt. Dies ist ein direkter Nachweis, der über eine Präsentation oder einen allgemeinen Sicherheitstext in einem Angebot hinausgeht. Ein Anbieter, der einen solchen Bericht vorlegen kann, zeigt, dass Sicherheit auch extern oder formal geprüft wurde. Fehlt dieses Beispiel vollständig, basiert die Bewertung vor allem auf Erklärungen und nicht auf nachweisbarer Kontrolle.
  • Fragen Sie, wie der Anbieter diese drei Punkte gemeinsam dokumentiert. Die Kombination aus einem festen Standard wie OWASP MASVS, einer konkreten Erklärung zur sicheren Speicherung über iOS Keychain oder Android Keystore und einem aktuellen Penetrationstest-Bericht liefert ein deutlich brauchbareres Vergleichsbild als einzelne Beruhigungen. Sobald einer dieser Bestandteile fehlt, wird es schwieriger, Sicherheitsbehauptungen zwischen Mobile-App-Anbietern konsistent nebeneinanderzulegen.

Häufige Fehler beim Überspringen von Sicherheitskontrollen

Hartcodierte API-Schlüssel im mobilen Code bleiben bei der Anbieterauswahl oft unsichtbar, wenn Sicherheitskontrollen durch allgemeine Beruhigung ersetzt werden. Dadurch verschiebt sich die Bewertung von überprüfbarer Sicherheit zu Vertrauen in Verkaufssprache, während der tatsächliche Fehler erst sichtbar wird, nachdem die App bereits mit Backend-Systemen verbunden ist.

  • Ein häufiger Fehler ist das Vertrauen auf breite Behauptungen wie Security-by-Design ohne technische Validierung dessen, was damit gemeint ist. In dieser Situation kann ein Anbieter API-Schlüssel hartcodiert in den mobilen Code aufnehmen. Die Kette ist dann direkt: Der Schlüssel befindet sich in der App, die App kommuniziert mit Backend-Systemen, und unautorisierter Zugriff rückt in Reichweite. Für ein nicht-technisches Team ist dies genau die Art von Risiko, die in der Angebots- und Auswahlphase verborgen bleibt, weil die Erklärung überzeugend klingen kann, während die zugrunde liegende Kontrolle fehlt.
  • Der Schaden einer solchen versäumten Kontrolle bleibt nicht auf einen technischen Mangel beschränkt. Sobald personenbezogene Daten auf diesem Weg durch einen vermeidbaren technischen Fehler offengelegt werden, verschiebt sich das Problem zu rechtlicher Haftung und möglichen Bußgeldern nach DSGVO/GDPR. Das macht die Anbieterwahl nicht nur zu einer Frage des Vertrauens, sondern auch zu einer Governance- und finanziellen Exponierung.
  • Ein zweiter Fehler entsteht nach dem Go-live: Security Ownership für Updates nach dem Launch wird nicht festgelegt. Dann gibt es keine klare Wartungsverantwortung, sobald neue OS-Schwachstellen auftreten. Die App läuft weiter auf modernen Geräten, aber ohne Patches verschiebt sich die Situation von funktionsfähig zu unsicher. Dieser Verlust klarer Verantwortlichkeit wirkt sich auf den täglichen Betrieb aus, weil niemand mehr eindeutig benennen kann, wer für die Behebung neuer Sicherheitsprobleme verantwortlich ist.
  • Diese Unklarheit hat zwei konkrete Folgen. Nach außen sinkt das Vertrauen der Endnutzer, sobald sich die App auf modernen Geräten nicht mehr sicher anfühlt. Intern steigen die Wiederherstellungskosten, weil grundlegende Sicherheitsfehler im Nachhinein korrigiert werden müssen, die bereits während der Entwicklung oder bei der Auswahl des Anbieters sichtbar hätten sein können. Die Kombination aus aufgeschobener Wartung und nachträglicher Behebung endet dann nicht in einem kleinen Vorfall, sondern in einer unsicheren App auf modernen Geräten.

Synthese von Sicherheitserwartungen und Verantwortlichkeiten

Sicherheit bleibt schwer greifbar, sobald niemand ausdrücklich Eigentümer der Vereinbarungen zu Updates, Schwachstellen und personenbezogenen Daten ist. Dann verschiebt sich Security Ownership vom Angebot in die Umsetzung ohne feste Begrenzung, während das Risiko bei vermeidbaren technischen Fehlern, die zum Abfluss personenbezogener Daten führen, direkt beim Auftraggeber verbleibt. In dieser Situation ist eine beruhigende Erklärung des Anbieters nicht dasselbe wie eine nachweisbare Verantwortung, weil die operativen und rechtlichen Folgen nicht bei der Präsentation bleiben, sondern bei der Live-App und den verarbeiteten Daten.

Diese Spannung wird erst nach dem Go-live wirklich sichtbar. Eine mobile App verändert sich nicht nur während der Entwicklungsphase; auch danach bleiben Software-Updates und das Management von Schwachstellen Teil der Sicherheitserwartung. Wenn die Wartung nach dem Launch implizit bleibt, entsteht Raum für Aufschub, Diskussionen über Verantwortlichkeit und Unklarheit darüber, wer Software-Updates übernimmt. Das ist kein administratives Detail. Genau hier zeigt sich, ob ein Anbieter einen transparenten Prozess für Patch-Management anwendet oder ob Sicherheit in der Praxis von losen Zusagen und ad-hoc-Nachverfolgung abhängig wird.

Für nicht-technische Teams liegt der Kern daher weniger in der Bewertung technischer Tiefe als in der Unterscheidung zwischen klarer Verantwortung und unverbindlicher Formulierung. Security Ownership erhält erst dann Bedeutung, wenn auch die Phase nach der Übergabe abgegrenzt ist: Wer verwaltet Schwachstellen, wer verarbeitet Updates und wer trägt die Folgen, wenn dies zu spät oder unvollständig geschieht? Sobald diese Linie fehlt, verschiebt sich das Risiko unbemerkt vom Anbieter zum Auftraggeber, mit möglicher rechtlicher Haftung und Bußgeldern nach DSGVO/GDPR bei einem Leak personenbezogener Daten durch vermeidbare technische Fehler.

Quellen