Heruntergeladene macOS-App vor dem ersten Start prüfen

Eine Sicherheits-App erhält konstruktionsbedingt ungewöhnlich weitreichenden Zugriff. Sie kann Netzwerkverkehr lesen, eine Systemerweiterung hinzufügen, einen privilegierten Helfer installieren, Dateien prüfen oder nach Berechtigungen für Bildschirmaufnahmen und Bedienungshilfen fragen. Ihren ersten Start wie die Installation einer beliebigen App zu behandeln, ist ein vermeidbarer Fehler.

Eine gründliche Prüfung erfordert kein Reverse Engineering des gesamten Produkts. Du musst feststellen, ob du das gewünschte Artefakt erhalten hast, ob die Identität des Herausgebers deinen Erwartungen entspricht, ob der Inhalt weiterhin dem signierten Release entspricht und ob macOS die App unter seinen normalen Schutzmechanismen akzeptiert. Erledige das, bevor die App Berechtigungen, Zugangsdaten oder ein Administratorkennwort erhält.

Diese Prüfung ist bewusst wiederholend. Genau das macht sie zuverlässig. Ein einmaliges Ritual, das sich nach der jeweiligen Warnung von macOS richtet, lässt sich leicht umgehen. Eine kurze Dokumentation derselben Prüfungen für jede neue Sicherheits-App ist schwerer auszutricksen und lässt sich leichter an einen anderen Entwickler weitergeben.

Der Dateiname ist nicht der Herausgeber

Eine Datei namens Acme Security.app sagt fast nichts aus. Ein kopiertes Symbol, ein vertrauter Produktname und eine professionell wirkende Download-Seite lassen sich leicht nachahmen. Entscheidend ist die Identität, die in der Signatur hinterlegt ist. Vergleiche sie anschließend mit Informationen, die du unabhängig vom Herausgeber erhalten hast.

Beginne bei der Quelle. Bevorzuge die eigene Release-Seite des Herausgebers oder einen Veröffentlichungsort, den er in seiner Dokumentation nennt. Vermeide Download-Aggregatoren, Dateispiegel und Links aus Chatverläufen, wenn du das Original-Release direkt beziehen kannst. Wenn dir ein Kollege die Datei schickt, frage, woher er sie hat, statt seinen Besitz als Herkunftsnachweis zu betrachten.

Hier geht es um zwei unterschiedliche Fragen:

• Ist diese Datei von dem Ort eingetroffen, den ich verwenden wollte?
• Entspricht der Herausgeber, der diese ausführbare Datei signiert hat, dem Herausgeber, dem ich vertrauen wollte?

Diese Fragen werden oft zu einer einzigen zusammengefasst. So kann ein kompromittierter Download-Bereich eines Anbieters eine oberflächliche Prüfung bestehen. Ebenso kann eine App mit einer gültigen Apple Developer ID allein deshalb Vertrauen gewinnen, weil ihr Name einem bekannten Anbieter ähnelt.

Lege deine Erwartung fest, bevor du die Datei prüfst. Notiere Produktname, Version, erwarteten Dateityp, Namen des Herausgebers sowie einen veröffentlichten Team Identifier oder Angaben zum Signierzertifikat. Wenn der Anbieter nie eine stabile Kennung veröffentlicht hat, nutze mehrere unabhängige Signale: seine Dokumentation, sein Quell-Repository, ein früheres Release, dem du bereits vertraust, und eine Antwort des Supports über einen bekannten Kontakt. Die Betreffzeile eines Zertifikats reicht nicht aus, wenn du bisher keinen Grund hattest, sie mit diesem Anbieter zu verbinden.

Bei einer App, die andere Software schützen soll, erwarte ich, dass der Herausgeber diese Prüfung erleichtert. Ein Anbieter, der dich auffordert, Gatekeeper zu deaktivieren, eine curl-Ausgabe direkt an eine Shell weiterzuleiten oder eine Abweichung ohne genaue Erklärung zu ignorieren, ist bei der Installationsprüfung bereits durchgefallen.

Prüfe das heruntergeladene Artefakt, bevor du es öffnest

Prüfe den heruntergeladenen Container, bevor du eine App in den Programme-Ordner ziehst oder einen Installer startest. Der Container bestimmt, welche Befehle relevant sind und was als Nächstes passieren kann.

Eine .dmg ist ein Disk-Image. Beim Einbinden wird ihr Inhalt sichtbar, die enthaltene App sollte dadurch aber nicht selbst gestartet werden. Eine .pkg ist ein Installer-Paket und kann Systemänderungen vornehmen, sobald du den Installer autorisierst. Eine .zip ist ein Archiv, das normalerweise ein App-Bundle oder einen anderen Container enthält. Eine reine .app ist bereits ein App-Bundle.

Lass den ursprünglichen Download bis zum Ende der Prüfung unverändert. Der Finder entpackt ZIP-Dateien häufig automatisch. Das ist praktisch, erschwert aber die Zuordnung zu genau dem Artefakt, dessen Hash der Anbieter veröffentlicht hat. Wenn der Herausgeber eine SHA-256-Prüfsumme für die ZIP-Datei bereitstellt, prüfe die ZIP-Datei vor dem Entpacken. Gibt er eine Prüfsumme für das Disk-Image an, prüfe das Disk-Image vor dem Einbinden.

Verwende im Terminal einen vollständig in Anführungszeichen gesetzten Pfad. Wenn du eine Datei aus dem Finder in das Terminal ziehst, wird dieser Pfad sicher eingefügt.

shasum -a 256 "$HOME/Downloads/VendorSecurity.dmg"

Die Ausgabe sieht so aus:

9fd1...e84c  /Users/you/Downloads/VendorSecurity.dmg

Vergleiche alle 64 Hexadezimalzeichen mit dem Wert des Herausgebers. Vergleiche nicht nur die ersten Zeichen und erkläre die Prüfung dann für abgeschlossen.

Eine Prüfsumme ist nur dann ein starker Nachweis, wenn du den erwarteten Digest über einen anderen Weg als die heruntergeladene Datei erhältst. Die beste einfache Kombination ist ein Installer von der Release-Seite des Anbieters und eine Prüfsumme in einer signierten Release-Notiz, einem Release eines Quell-Repositorys oder einer separat gepflegten Sicherheitsseite. Ein Hash direkt neben der Download-Schaltfläche erkennt zwar versehentliche Beschädigungen, schützt dich aber nicht, wenn ein Angreifer sowohl diese Seite als auch die Datei kontrolliert.

Wenn der Anbieter keine Prüfsumme veröffentlicht, erzeuge keine falsche Gewissheit. Führe die Prüfungen von Signatur und Notarisierung trotzdem durch und gewichte die Überprüfung des Herausgebers stärker. Wenn die App für deine Umgebung besonders wichtig ist, bitte den Anbieter um einen signierten Digest oder ein Release-Manifest. Das ist eine angemessene Anforderung.

Bei einem Disk-Image kannst du macOS zusätzlich bitten, dessen interne Struktur zu prüfen:

hdiutil verify "$HOME/Downloads/VendorSecurity.dmg"

Eine erfolgreiche Prüfung besagt, dass die Struktur des Images und die Prüfsummenblöcke intern konsistent sind. Sie identifiziert nicht den Herausgeber und ersetzt keine vom Anbieter bereitgestellte SHA-256-Prüfsumme.

Eine gültige Signatur beweist Integrität, nicht Vertrauenswürdigkeit

Die Codesignatur beantwortet eine enge, aber nützliche Frage: Hat sich das signierte Bundle verändert, seit der Signierer es freigegeben hat? Sie zeigt außerdem die Signaturkette und den Team Identifier. Sie sagt nicht, ob die App gut entwickelt ist, ob der Herausgeber dein Vertrauen verdient oder ob der angeforderte Zugriff sinnvoll ist.

Nachdem du das Disk-Image eingebunden oder das Archiv entpackt hast, prüfe das App-Bundle direkt. Dieser Befehl verifiziert die Codesignatur und prüft verschachtelten signierten Code im Bundle:

codesign --verify --deep --strict --verbose=4 "/Volumes/Vendor Security/Vendor Security.app"

Bei Erfolg wird oft kaum etwas ausgegeben. Der Exit-Status des Terminals ist das Ergebnis. Eine ruhige Rückkehr zur Eingabeaufforderung nach diesem Befehl ist daher normal. Bei einem Fehler nennt codesign eine veränderte Datei, eine ungültige Signatur oder eine verschachtelte Komponente, die nicht validiert werden kann.

Gib anschließend die Signaturdetails aus:

codesign -dvvv "/Volumes/Vendor Security/Vendor Security.app" 2>&1 | \
  egrep "^(Identifier|TeamIdentifier|Authority|Timestamp)="

Die Ausgabe sieht ungefähr so aus:

Identifier=com.vendor.security
TeamIdentifier=ABCDE12345
Authority=Developer ID Application: Vendor, Inc. (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Timestamp=Jan 16, 2026 at 14:32:09

Der tatsächliche Name des Anbieters, die Bundle-ID und der Team Identifier müssen deinen Erwartungen entsprechen. Notiere den Team Identifier. Er ist deutlich stabiler und eindeutiger als ein App-Symbol oder ein Anzeigename. Außerdem kannst du ihn bei späteren Updates konkret vergleichen.

Interpretiere das Wort Authority nicht über. Eine Developer-ID-Signatur bedeutet, dass Apple das Zertifikat einem registrierten Entwickler ausgestellt hat und der Code anhand dieser Kette validiert wird. Sie bedeutet nicht, dass Apple das Produkt empfiehlt. Apples eigene Dokumentation macht die verwandte Unterscheidung deutlich: Notarisierung ist eine automatisierte Prüfung auf Malware und gültige Signierung, keine App-Prüfung durch Apple.

Apples Leitfaden zur Codesignatur warnt Entwickler außerdem davor, komplexe Software mit codesign --deep zu signieren, weil die Optionen zu umfassend angewendet werden. Diese Warnung betrifft das Erstellen von Signaturen. Für eine Prüfung durch den Benutzer ist --deep nützlich, weil codesign damit auch verschachtelten Code validiert. Der Befehl prüft trotzdem nicht jedes Skript und jede Konfigurationsdatei auf schädliche Absichten.

Wenn die App einen Helfer, ein Kommandozeilenprogramm oder eine Erweiterung enthält, ist die Bundle-Prüfung der erste Schritt und nicht das letzte Wort. Bei der später beschriebenen Prüfung des ersten Starts vergleichst du diese Komponenten mit dem, was die App nach eigenen Angaben benötigt.

Die Gatekeeper-Bewertung prüft das Release, das macOS ausführen wird

Führe auch dann eine Gatekeeper-Bewertung der App durch, wenn die Signatur korrekt aussieht. spctl bewertet das Element anhand der Systemrichtlinie, die zum Ausführungszeitpunkt gilt. Das kommt der Frage näher: «Akzeptiert dieser Mac die App unter den normalen Schutzmechanismen?»

Verwende:

spctl --assess --type execute --verbose=4 \
  "/Volumes/Vendor Security/Vendor Security.app"

Ein gutes Ergebnis enthält häufig Zeilen wie diese:

/Volumes/Vendor Security/Vendor Security.app: accepted
source=Notarized Developer ID
origin=Vendor, Inc. (ABCDE12345)

Der genaue Wortlaut hängt von der macOS-Version ab. Entscheidend sind eine akzeptierte Bewertung, bei einem direkten Download eine Quelle vom Typ «Notarized Developer ID» und eine Herkunft, die du erkennst.

Diese Prüfung erkennt einen Fehler, den eine Prüfsumme nicht aufdecken kann: Du könntest eine unveränderte Datei vom falschen Herausgeber heruntergeladen haben. Sie erkennt außerdem einen anderen Fehler, der bei der alleinigen Prüfung des Zertifikats übersehen werden kann: Eine gültig signierte App erfüllt möglicherweise nicht die aktuelle Gatekeeper-Richtlinie.

Apple beschreibt Gatekeeper als eine Prüfung heruntergeladener Software auf einen identifizierten Entwickler, Notarisierung und Veränderungen. Das ist ein nützlicher Sicherheitsmechanismus, aber weiterhin eine Bewertung durch das Betriebssystem. Sie sollte deine Entscheidung unterstützen, nicht die Frage ersetzen, ob der Herausgeber und die angeforderten Berechtigungen sinnvoll sind.

Unterdrücke eine fehlgeschlagene Bewertung nicht, indem du Attribute entfernst oder vor dem Verständnis des Grundes eine Finder-Ausnahme verwendest. Bewahre den Fehlertext in deinen Prüfnotizen auf. Ein widerrufenes Zertifikat, eine abgelaufene oder fehlerhafte Signatur, ein fehlendes Notarisierungsergebnis und eine von der Organisation verwaltete Einschränkung erfordern unterschiedliche Reaktionen. Jede Warnung als lästiges Hindernis zu behandeln, führt dazu, dass Ausnahmen zum normalen Installationsweg werden.

Ein angehängtes Ticket ist hilfreich, aber nicht die gesamte Notarisierungsprüfung

Notarisierung und das Anhängen eines Tickets hängen zusammen, sind aber nicht dasselbe. Bei der Notarisierung verarbeitet Apples Notardienst die eingereichte Software und stellt nach seinen automatisierten Prüfungen ein Ticket aus. Beim Stapling wird dieses Ticket an eine App, ein Disk-Image oder ein Installer-Paket angehängt. Gatekeeper kann ein Ticket auch online finden.

Wenn die Xcode Command Line Tools installiert sind, prüfe, ob ein Ticket angehängt ist:

xcrun stapler validate "/Volumes/Vendor Security/Vendor Security.app"

Eine erfolgreiche Validierung bestätigt, dass das Ticket physisch an diesem Bundle hängt. Das ist hilfreich bei einem Laptop, auf dem die App möglicherweise erstmals ohne Netzwerkverbindung gestartet wird.

Lehne eine App nicht allein deshalb ab, weil dieser Befehl meldet, dass kein Ticket angehängt ist. Apple dokumentiert, dass Gatekeeper ein Notarisierungsticket online finden kann, auch wenn der Benutzer die App heruntergeladen hat, bevor die Notarisierung abgeschlossen war. Ein ZIP-Archiv kann selbst ebenfalls kein angehängtes Ticket tragen. Der Herausgeber muss die enthaltenen Elemente stapeln und anschließend ein neues Archiv erstellen.

Verwende die Prüfungen in dieser Reihenfolge:

1. Prüfe den SHA-256-Digest, wenn ein unabhängig veröffentlichter Digest vorhanden ist.
2. Prüfe die App-Signatur und den Team Identifier.
3. Führe die Gatekeeper-Bewertung aus.
4. Validiere ein angehängtes Ticket, wenn das Tool verfügbar ist und ein erster Offline-Start wichtig ist.

Lasse den Mac beim ersten normalen Start mit dem Internet verbunden, sofern der Herausgeber nicht ausdrücklich einen Offline-Bereitstellungsprozess dokumentiert. So kann Gatekeeper seine normalen Online-Abfragen durchführen, einschließlich der Prüfung des Zertifikatsstatus. Interpretiere ein angehängtes Ticket nicht als Zusage, dass die App immer akzeptiert bleibt, wenn ihre Signieridentität später widerrufen wird.

Die Grenzen der Notarisierung sollte man klar benennen. Sie ist keine vollständige Prüfung des Verhaltens einer App. Sie bestätigt nicht, dass der Cloud-Dienst einer App Daten sicher verarbeitet, dass ihr Updatesystem zuverlässig ist oder dass eine neue Version nur angemessene Berechtigungen anfordert. Sie sagt, dass das eingereichte Artefakt den automatisierten Prozess von Apple bestanden hat, und gibt Gatekeeper ein Ticket zur Verwendung.

Die Quarantäne liefert Hinweise zur Herkunft, also lass sie bestehen

Das erweiterte Attribut com.apple.quarantine hält fest, dass macOS ein Element über einen Kanal erhalten hat, der es als heruntergeladen oder übertragen markiert hat. Es hilft Gatekeeper zu erkennen, dass dies ein erster Start ist, der geprüft werden sollte. Es ist keine Malware-Kennzeichnung.

Prüfe die Attribute mit:

xattr -l "/Volumes/Vendor Security/Vendor Security.app"

Bei einem heruntergeladenen Element kann die Ausgabe Folgendes enthalten:

com.apple.quarantine: 0083;...;Safari;...

Flags und Zeitstempelformat sind Implementierungsdetails. Die nützliche Schlussfolgerung ist, dass das Element seine Download-Herkunft bewahrt. Eine App ist nicht allein deshalb verdächtig, weil sie dieses Attribut besitzt. Die meisten Browser-Downloads sollten es haben.

Das Fehlen der Quarantäne macht eine App ebenfalls nicht sicher. Dateien können erweiterte Attribute verlieren, wenn sie durch Archivprogramme, Netzwerkfreigaben, Wechselmedien oder den Kopiervorgang eines Kollegen weitergegeben werden. Apple erklärt außerdem, dass macOS Software beim ersten Öffnen unabhängig von ihrer Herkunft auf bekannte schädliche Inhalte prüft. In der Praxis liefern erhaltene Herkunftsinformationen Gatekeeper und deinem Prüfprozess trotzdem einen besseren Kontext.

Die verbreitete Lösung für eine App, die sich nicht öffnen lässt, lautet:

xattr -dr com.apple.quarantine "/Applications/Vendor Security.app"

Mach das nicht zu einem normalen Bestandteil der Installation. Der Befehl entfernt ein Kontrollsignal, weil dir das Ergebnis der Kontrolle nicht gefällt. Er repariert keine defekte Signatur, bestätigt nicht die Identität des Herausgebers und macht eine nicht notarialisierte App nicht sicherer. Wenn die veröffentlichten Anweisungen eines Anbieters diesen Befehl verlangen, halte an und kläre, warum der Anbieter kein Release liefern kann, das Gatekeeper akzeptiert.

Ein verwalteter Mac kann über die Geräteverwaltung strengere Regeln durchsetzen. In diesem Fall kann eine Ausnahme aus gutem Grund nicht verfügbar oder verboten sein. Frage den Administrator nach dem vorgesehenen Richtlinienweg, statt die Einschränkung als technisches Rätsel zu behandeln.

Pakete müssen geprüft werden, bevor der Installer ein Passwort erhält

Eine .pkg verdient mehr Aufmerksamkeit als ein App-Bundle, weil Apples Installer nach deiner Autorisierung außerhalb deines Benutzerordners schreiben kann. Sicherheitsprodukte benötigen manchmal Pakete, um einen privilegierten Helfer, eine Systemerweiterung, einen Netzwerkfilter oder unterstützende Komponenten zu installieren. Das kann legitim sein. Es bleibt trotzdem eine folgenreiche Aktion.

Prüfe die Signaturinformationen eines Pakets, bevor du es doppelt anklickst:

pkgutil --check-signature "$HOME/Downloads/VendorSecurity.pkg"

Ein typisches Ergebnis nennt den Signaturstatus des Pakets, das Developer-ID-Installer-Zertifikat und die Zertifikatskette. Vergleiche den Namen des Anbieters und, sofern verfügbar, den Team Identifier mit der Identität, die du für die App notiert hast, oder mit den veröffentlichten Installationsunterlagen des Anbieters.

Bitte Gatekeeper anschließend, das Paket als Installer zu bewerten:

spctl --assess --type install --verbose=4 \
  "$HOME/Downloads/VendorSecurity.pkg"

Ersetze die Paketprüfung nicht durch eine App-Prüfung. Es handelt sich um unterschiedliche Artefakte, die in vielen Releases mit unterschiedlichen Zertifikatstypen signiert werden und beim Öffnen unterschiedliche Folgen haben.

Bevor du ein Administratorkennwort eingibst, stelle fest, was der Installer angeblich hinzufügt. Ein guter Anbieter erklärt, ob er einen privilegierten Helfer, eine Systemerweiterung, ein Anmeldeobjekt, ein Konfigurationsprofil oder eine Netzwerkkomponente installiert. Vage Formulierungen wie «erforderlicher Systemzugriff» reichen bei Software nicht aus, die sicherheitsrelevante Teile des Mac steuern will.

Wenn das Paket zusätzlich eine App installiert, prüfe die installierte App vor dem Start. Ein signiertes Paket kann legitim ein App-Bundle enthalten. Die Signatur des Pakets macht die Prüfung der Ausführungssignatur dieses Bundles nicht überflüssig.

Der erste Start ist eine Prüfung der Freigaben, kein Wettlauf zum Klick auf «Erlauben»

Nachdem das Artefakt die Prüfungen bestanden hat, verschiebe die App an ihren vorgesehenen Ort und starte sie normal, während du anwesend bist. Bewahre den ursprünglichen Download und deine aufgezeichneten Ergebnisse auf, bis die App ihre Ersteinrichtung abgeschlossen hat. Gewähre nicht gleich jede Berechtigung, nur weil die App ein Sicherheitsprodukt ist.

Lies jede macOS-Abfrage als Beschreibung dessen, was die App tun möchte. Typische Anforderungen betreffen Mitteilungen, vollständigen Festplattenzugriff, Bedienungshilfen, Bildschirmaufnahmen, Netzwerkfilter, eine Systemerweiterung oder einen von einem Administrator freigegebenen Helfer. Jede Anforderung sollte einen konkreten Bezug zur Aufgabe des Produkts haben.

Eine App zur Netzwerkprüfung kann beispielsweise sinnvollerweise eine Netzwerk-Erweiterung anfordern. Ein Gateway für Zugangsdaten-Aktionen kann die Berechtigung benötigen, seinen eigenen Tresor zu verwalten und eine Verbindung zu benannten Diensten herzustellen. Für diese Aufgabe sollte es aber keinen uneingeschränkten Zugriff auf Bildschirmaufnahmen benötigen. Ein Festplatten-Scanner kann vollständigen Festplattenzugriff brauchen, sollte aber erklären, was er liest und welche Daten lokal bleiben. Die Produktkategorie ist kein Freibrief.

Nutze diese kurze Prüfung beim ersten Start:

• Ordne jede Abfrage einer dokumentierten Funktion zu, die du tatsächlich verwenden willst.
• Halte bei einer unerwarteten Anforderung an und prüfe die Dokumentation des Anbieters, bevor du sie freigibst.
• Verweigere Administratorrechte, bis du den Namen und Zweck der zu installierenden Komponente kennst.
• Prüfe nach der Einrichtung die Systemeinstellungen auf neu aktivierte Anmeldeobjekte, Profile, Erweiterungen oder Hintergrundelemente.
• Dokumentiere App-Version, Team Identifier, Download-Hash und Berechtigungsentscheidungen zusammen mit dem Release.

Der zweite und dritte Punkt sind wichtig, weil die folgenreichste Freigabe oft keine App-Berechtigung ist. Es ist eine von einem Administrator freigegebene Komponente, die über das App-Fenster hinaus bestehen bleibt und möglicherweise mehr Zugriff hat als die App selbst.

Bei einer Bereitstellung im Team solltest du diese Prüfung in ein einfaches Aufnahmeformular übernehmen. Es sollte den Quellort, das Datum, den Datei-Hash, die Signieridentität, das Gatekeeper-Ergebnis, das Notarisierungsergebnis, installierte Komponenten, freigegebene Berechtigungen und den Namen des Prüfers enthalten. Dadurch wird die Prüfung eines späteren Updates deutlich schneller. Außerdem fällt eine überraschende Änderung der Signieridentität auf, bevor sie alle Entwickler-Laptops erreicht.

Verwechsle eine saubere Installation nicht mit einem vertrauenswürdigen Betriebsmodell

Eine saubere Signatur, eine akzeptierte Gatekeeper-Bewertung und ein angemessener Berechtigungssatz sind ein guter Ausgangspunkt. Sie beweisen nicht, dass die App nach dem Start sichere Entscheidungen trifft. Du musst weiterhin prüfen, wo sie Geheimnisse speichert, wie sie Updates authentifiziert, welche Daten sie vom Mac überträgt und ob ein kompromittierter Prozess seine Berechtigungen missbrauchen kann.

Bei Sicherheitswerkzeugen, die für Agents bestimmt sind, solltest du auf einer Grenze bestehen, die auch bei einem Fehler des Agents erhalten bleibt. Der Agent sollte keine wiederverwendbaren Zugangsdaten erhalten, nur weil er eine Aktion ausführen muss. Stattdessen sollte er die Aktion über einen lokalen Kontrollpunkt anfordern, der eine menschliche Freigabe verlangen und einen Audit-Trail speichern kann.

Denselben Installationsstandard wende ich auch bei Sallyport an: Zuerst prüfe ich das signierte Release, anschließend bewerte ich seine tatsächliche Grenze. Sallyport bewahrt Zugangsdaten in seinem verschlüsselten Tresor auf und führt freigegebene HTTP- oder SSH-Aktionen selbst aus, statt Geheimnisse an einen Agent-Prozess weiterzugeben.

Die nützliche Gewohnheit ist einfach: Lass eine App nicht allein deshalb weitreichende Befugnisse erhalten, weil sie als Sicherheitssoftware bezeichnet wird. Sie soll ihre Herausgeberidentität, ihren unveränderten Inhalt, ihren Gatekeeper-Status und den genauen gewünschten Zugriff nachweisen. Wenn sie diese Prüfung nicht besteht, darf sie die Berechtigungen, die eine Sicherheits-App leistungsfähig machen, nicht erhalten.