Salesforce Security Review Checkliste: was Sie beheben, und in welcher Reihenfolge

Die meisten AppExchange-Einreichungen scheitern an einer kurzen, vorhersehbaren Liste, und die Zugriffskontrolle steht ganz oben. Arbeiten Sie diese Checkliste der Reihe nach ab, zuerst die Durchsetzung von Zugriffsrechten im User Mode, dann die Triage der Scanner-Findings, dann die Einreichungsunterlagen, und Sie beseitigen die meisten Gründe, aus denen ein Reviewer ein Package zurückschickt. Salesforce nennt 4 bis 5 Wochen für eine typische Prüfung, eine Ablehnung kostet also einen Release-Zyklus und nicht einen Nachmittag.

Tekunda hat Managed Packages im Gesundheitswesen, in der Logistik und in der Fertigung durch die AppExchange Security Review gebracht. Was folgt, ist die Reihenfolge, in der wir arbeiten, keine Beschreibung des Prozesses.

Woran scheitert eine Salesforce Security Review?

Arbeiten Sie von oben nach unten. Die oberen Punkte sind zugleich die häufigsten Findings und die teuersten, wenn man sie nachträglich einbaut. Genau deshalb kostet es einen ganzen Zyklus, sie bis zum Schluss aufzuschieben.

1. Zugriffskontrolle, die nicht im User Mode durchgesetzt wird. Jede Query und jede DML-Operation in Ihrem Package muss die Objektrechte, die Feldberechtigungen und das Sharing des ausführenden Benutzers respektieren. Nutzen Sie WITH USER_MODE in SOQL und AccessLevel.USER_MODE bei Database-Aufrufen statt selbst gebauter isAccessible()-Ketten, die leicht unvollständig bleiben.
2. Sharing an den falschen Klassen deklariert. Eine Apex-Klasse ohne Sharing-Keyword erbt das Sharing ihres Aufrufers, sodass ein Helper, der aus einer @AuraEnabled-Methode aufgerufen wird, unbemerkt ohne Sharing laufen kann. Deklarieren Sie with sharing ausdrücklich an jeder Klasse, auch an inneren Klassen und Utility-Klassen.
3. Dynamisches SOQL aus Eingaben zusammengebaut. Verwenden Sie Bind-Variablen. Muss eine Query wirklich als String entstehen, escapen Sie jeden eingesetzten Wert und lassen Sie dieses Escaping in derselben Methode sichtbar, denn dort liest es der Reviewer.
4. Nicht escapte Ausgabe. Alles, was über escape="false", lwc:dom="manual" oder innerHTML auf die Seite gelangt, muss vorher bereinigt sein, nicht danach.
5. Secrets und Kundendaten am falschen Ort. Fest verdrahtete Schlüssel in Apex, Tokens in Custom Settings, ein Datensatz mit personenbezogenen Daten in System.debug. Named Credentials und Protected Custom Metadata sind das, was Reviewer stattdessen erwarten.
6. Daten, die unverschlüsselt bleiben, im Ruhezustand oder bei der Übertragung. AES-256 für alles, was Sie außerhalb der Plattform speichern, TLS 1.2 oder höher auf jedem Hop. Ein Callout, der noch eine ältere TLS-Version aushandelt, ist ein Finding, auch wenn die Nutzlast harmlos ist.
7. Externe Systeme, die sich mit gespeichertem Benutzernamen und Passwort anmelden. Nutzen Sie OAuth für jede Verbindung, die Ihr Package zu einem Dienst von Ihnen oder vom Kunden aufbaut. Gespeicherte Anmeldedaten sind für sich genommen ein Finding und machen das Datenflussdokument schwerer zu verteidigen.
8. Eine Composite Site ohne die Grundlagen. Bringt Ihre Lösung eine Weboberfläche außerhalb der Org mit, braucht sie Security-Header, und ihre Cookies brauchen Secure und HttpOnly. Reviewer prüfen die Site, die Sie ihnen übergeben, nicht die, die Sie beschreiben.
9. Externe Endpunkte, die niemand gescannt hat. Ruft Ihr Package einen Dienst auf, den Sie selbst betreiben, gehört dieser Dienst zum Prüfumfang und braucht einen eigenen dynamischen Scan-Report.
10. Eine Testumgebung, die der Reviewer nicht nutzen kann. Eine abgelaufene Org, eine Identity Challenge, die ihn aussperrt, oder Objekte ohne Daten. Das Team bedient Ihre Lösung end to end wie ein Kunde und kann nicht prüfen, was nicht läuft.

Welche Scanner-Findings sind False Positives, und wie dokumentiert man sie?

Die Messlatte liegt nicht bei null Findings, und sie liegt je Scanner anders. Die Vorbereitungshinweise von Salesforce legen es fest:

• Salesforce Code Analyzer: Beheben Sie jeden sicherheitsrelevanten Fehler und ignorieren Sie Findings ohne Sicherheitsbezug.
• Source Scan im Partner Security Portal: Beheben Sie Low, Medium und High und lassen Sie rein informative Warnungen stehen.
• Dynamische Scanner wie ZAP, Burp Suite, Veracode, Intruder, Acunetix und JiT DAST: Beheben Sie alles außer informativen Punkten und Warnungen, und legen Sie einen Screenshot bei, der belegt, dass der richtige Endpunkt gescannt wurde.

Erzeugen Sie den Code-Analyzer-Bericht mit dem AppExchange-Regelsatz, damit er dem entspricht, was der Reviewer erwartet:

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

Welche Scans Pflicht sind, hat sich zuletzt geändert, prüfen Sie also die aktuellen Scanner-Anforderungen, bevor Sie etwas erzeugen.

Seit Salesforce den gehosteten Chimera-Scanner am 2025-06-16 abgeschaltet hat, führen Sie diesen dynamischen Scan selbst aus. Siehe Eigene dynamische Scans nach Chimera für die akzeptierten Tools und den einzureichenden Report.

In unseren Einreichungen kommen vier Kategorien oft genug als echte False Positives zurück, dass man sie einplanen sollte: Zugriffskontroll-Findings gegen Code, der User Mode bereits durchsetzt, Sharing-Findings an Klassen, die nur über einen Kontext betreten werden, in dem Sharing schon greift, Findings zu veralteten Bibliotheken, die auf eine Versionsnummer in einer mitgelieferten Static Resource anspringen, und Reflected Cross-Site-Scripting an Parametern, die das DOM nie erreichen.

Recht zu haben reicht allerdings nicht. Durch die Prüfung bringt Sie das Dokument. Salesforce verlangt ein Dokument, das erklärt, warum jeder markierte Punkt kein Sicherheitsrisiko darstellt, und fordert dabei konkret zu beschreiben, wie Sie sich gegen die angezeigte Schwachstelle schützen. Geben Sie jedem Finding einen eigenen Eintrag: Scanner und Regel-ID, Datei und Zeile, ein Satz zum Datenpfad, die genaue Schutzmaßnahme und die Stelle im Package, an der sie sitzt. Einzeilige Abweisungen kommen als Rückfrage zurück, und Rückfragen kosten Wochen. Für eine ausführliche Anleitung zum Begründungsformat und den Fehlern, die es ablehnen lassen, siehe False Positives für die Salesforce Security Review dokumentieren.

Was gehört neben dem Package in die Einreichung?

• Nutzungsdokumentation, geschrieben so, dass jemand ohne Vorkenntnis der App einen vollständigen Workflow durchlaufen kann.
• Dokumentation der Datenflüsse zwischen der Salesforce-Org und jeder Composite Site, mobilen App oder Browser-Erweiterung.
• Sämtliche Scan-Reports plus das False-Positive-Dokument.
• Eine Developer-Edition-Org mit installiertem Package und realistischen Testdaten.
• Zugangsdaten für jedes externe System, das die App berührt, inklusive API-, OAuth- und SAML-Zugriff.
• Installationslinks und Zugangsdaten für mobile oder Desktop-Clients.

Wie lange dauert die Security Review, und was kostet sie?

Salesforce gibt an, dass eine Lösung typischerweise 4 bis 5 Wochen durch die Prüfung braucht, und dass für jede kostenpflichtige Lösung auf dem Marktplatz eine Gebühr von $999 für die Ersteinreichung und für jeden weiteren Versuch anfällt. Beides spricht für dasselbe Vorgehen: Ziehen Sie die Arbeit an der Zugriffskontrolle nach vorn, denn die günstigste Einreichung ist die, die man nur einmal macht.

Wenn Sie ein Produkt paketieren und die Prüfung lieber Leuten überlassen, die sie schon bestanden haben: Tekunda baut und paketiert AppExchange-Produkte als Salesforce PDO.

FAQ

Müssen auch kostenlose Apps durch die Security Review?

Ja. Jede Lösung, die über den Marktplatz verteilt wird, muss die Prüfung bestehen, bevor sie gelistet wird. Die von Salesforce dokumentierte Gebühr betrifft kostenpflichtige Lösungen.

Reicht der Salesforce Code Analyzer allein?

Nein. Code Analyzer v5 deckt Apex, Visualforce, JavaScript und TypeScript in Ihrem Package ab. Jeder externe Endpunkt, den Ihre App aufruft, braucht zusätzlich einen eigenen dynamischen Scan-Report.

Was ist der häufigste Ablehnungsgrund?

Die Zugriffskontrolle. Queries und DML im System Mode sowie Klassen, die Sharing erben statt es zu deklarieren, erzeugen mehr Findings als alles andere.

Ändert eine Agentforce- oder Agenten-App die Checkliste?

Für agentische Lösungen gilt dieselbe Security Review. Der Unterschied zeigt sich in der Dokumentation der Datenflüsse, denn jeder externe Dienst, den Ihr Agent aufrufen kann, muss beschrieben und gescannt sein.

Ist die Security Review ein einmaliges Ereignis?

Nein. Salesforce prüft gelistete Lösungen periodisch erneut, und jedes Feature, das Sie danach ausliefern, wird an denselben Maßstab gehalten. Die Checkliste ist damit ein dauerhaftes Release-Gate und keine Aufgabe zum Launch.