Die AppExchange Security Review im ersten Anlauf bestehen

TL;DR: Die Salesforce Security Review Checkliste ist die Sammlung von Kontrollen, die das Product-Security-Team von Salesforce prüft, bevor ein Managed Package auf AppExchange live geht: durchgesetzte CRUD/FLS und Sharing, keine Injection-Fehler, verschlüsselte Daten, dokumentierte Datenflüsse und saubere Scanner-Berichte. Bestehen Sie im ersten Anlauf, indem Sie die erforderlichen Scans ausführen, jede behebbare Verletzung beheben und den Rest dokumentieren. Unten finden Sie die praktische Checkliste und die Fehler, die eine erneute Einreichung auslösen.

Was ist die Salesforce Security Review?

Die Security Review ist ein obligatorisches Audit, das Salesforce für jedes Managed Package durchführt, bevor es auf AppExchange gelistet werden darf. Sie kombiniert statische Codeanalyse, dynamische Anwendungstests und eine manuelle Prüfung durch das Product-Security-Team von Salesforce. Die Einreichungsgebühr beträgt 999 $ für kostenpflichtige Lösungen (kostenlose Listings zahlen nichts), und eine Lösung braucht typischerweise 4 bis 5 Wochen für den Prozess. Scans müssen nicht zu 100% sauber sein; Sie führen sie aus, beheben, was Sie können, und erklären den Rest.

Was steht auf der Salesforce Security Review Checkliste?

Jeder Punkt unten entspricht etwas, das ein Prüfer aktiv zu brechen versucht. Behandeln Sie ihn als Tor vor der Einreichung, nicht als Wunschliste.

1. Setzen Sie CRUD und FLS durch. Jede Query und jede DML-Operation muss die Objekt- und Feldberechtigungen des ausführenden Benutzers respektieren. Verwenden Sie WITH USER_MODE bei SOQL und AccessLevel.USER_MODE bei Database-Aufrufen, dazu Security.stripInaccessible() für Payloads, die Sie selbst filtern. Handgeschriebene isAccessible()/isUpdateable()-Ketten bleiben leicht unvollständig.
2. Respektieren Sie Sharing. Deklarieren Sie with sharing für Apex-Klassen, die Datensätze berühren, und erweitern Sie niemals den Zugriff, um eine Sharing-Regel zu umgehen.
3. Beseitigen Sie Injection. Verwenden Sie Bind-Variablen statt String-Verkettung in SOQL und SOSL. Escapen Sie alles Dynamische.
4. Verschlüsseln Sie Daten. AES-256 für ruhende Daten, TLS 1.2 oder höher bei der Übertragung.
5. Schützen Sie Secrets. Speichern Sie Anmeldedaten in Named Credentials oder geschützten Custom Metadata, niemals fest codiert in Apex oder einer Komponente.
6. Nutzen Sie OAuth für jede Verbindung zu einem externen System, statt rohe Benutzernamen und Passwörter zu speichern.
7. Härten Sie das Frontend. Setzen Sie Security-Header und markieren Sie Cookies als Secure und HttpOnly.
8. Führen Sie die Scanner aus und dokumentieren Sie False Positives. Ein False Positive ohne Erklärung liest sich wie eine ungelöste Schwachstelle.
9. Dokumentieren Sie alles. Architektur, Datenfluss-Diagramme zwischen Ihrer Org und jeder externen Site, API-Callouts und funktionierende Testzugangsdaten.

Welche Scanner verlangt Salesforce von Ihnen?

Für ein Managed Package müssen Sie Berichte des Salesforce Code Analyzer hochladen. Erzeugen Sie sie mit dem AppExchange-Regelsatz:

sf code-analyzer run --rule-selector AppExchange --rule-selector Recommended:Security --output-file CodeAnalyzerReport.html

Salesforce führt außerdem statische Analysen mit Checkmarx und dynamische Tests mit Werkzeugen wie OWASP ZAP oder Burp Suite durch. (Der ältere Chimera-Scanner wurde eingestellt.) Denken Sie daran: Die Anforderung ist, dass Sie die Scans ausgeführt und behoben haben, was möglich war, nicht dass jede Regel besteht.

Warum scheitern Apps an der Security Review?

Die meisten Fehlschläge im ersten Anlauf drehen sich um eine kurze Liste von Problemen:

• Fehlende CRUD- oder FLS-Prüfungen bei einem einzelnen Objekt oder Feld.
• Apex, das without sharing läuft, wo es das nicht sollte.
• SOQL-Injection über dynamische Abfragen.
• Sensible Daten, die im Klartext gespeichert oder protokolliert werden.
• Undokumentierte False Positives in den Scanner-Berichten.

Nichts davon ist exotisch. Diese Fehler rutschen durch, weil sie spät entdeckt wurden, nachdem der Code geschrieben war, statt durchgesetzt zu werden, während das Package sich weiterentwickelte.

Wie beschleunigt die Qualität Ihrer Einreichung die Prüfung?

Ein Mensch prüft Ihre Einreichung, und die Qualität dessen, was Sie ihm übergeben, bestimmt, wie schnell sie durchgeht. Alles vorab zu übergeben - vollständige Datenfluss-Diagramme, ein klares False-Positive-Protokoll, reaktionsschnelle Ansprechpartner und Testzugangsdaten, die wirklich funktionieren - beseitigt das Hin und Her, das eine Prüfung um Wochen verlängert. Derselbe Instinkt, der guten Kundenservice ausmacht, die nächste Frage des Gegenübers vorwegzunehmen, verkürzt genau eine Security Review.

Die Teams, die reibungslos bestehen, behandeln die Prüfung als fortlaufende Disziplin: Sie verankern CRUD/FLS-Durchsetzung und Scanner-Läufe in ihrer Release-Pipeline, sodass das Package in jedem Sprint prüfbereit ist und nicht in der Woche vor der Einreichung zusammengeschustert wird. Das ist die DevOps-Haltung, die wir bei Tekunda mit Kunden aufbauen.

FAQ

Wie viel kostet die Salesforce Security Review?

Die Einreichungsgebühr beträgt 999 $ pro Versuch für kostenpflichtige Lösungen, einschließlich jeder erneuten Einreichung nach einem Fehlschlag. Für kostenlose Listings fällt die Gebühr nicht an.

Wie lange dauert die Security Review?

Eine Lösung braucht typischerweise 4 bis 5 Wochen durch die Prüfung, länger, wenn sie zur Behebung zurückkommt.

Müssen meine Scanner-Berichte zu 100% bestehen?

Nein. Sie müssen die Scans ausführen, jede behebbare Verletzung beheben, sie erneut ausführen und verbleibende False Positives dokumentieren.

Ist die Security Review ein einmaliges Ereignis?

Nein. Salesforce verlangt periodisch eine erneute Prüfung, und jede neue Funktion, die Sie ausliefern, muss denselben Maßstab erfüllen, daher ist die Checkliste ein fortlaufender Standard.