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

Eine Checkliste für die Salesforce Security Review ist nur nützlich, wenn sie eine Reihenfolge hat. Die meisten Einreichungen scheitern an einer kurzen, vorhersehbaren Liste, und die Zugriffskontrolle steht ganz oben. Arbeiten Sie in dieser Reihenfolge: Zugriff im User Mode im Code erzwingen, die drei Scanner-Berichte triagieren, dann die Einreichungsunterlagen und eine Testumgebung zusammenstellen, die der Reviewer wirklich nutzen kann. Salesforce rechnet mit 4 bis 5 Wochen pro Review, eine Ablehnung kostet Sie also einen Release-Zyklus und keinen Nachmittag.

Tekunda hat Managed Packages in Gesundheitswesen, Logistik und Fertigung durch die Review gebracht. Was folgt, ist die Reihenfolge, in der wir arbeiten, keine Prozessbeschreibung. Den gesamten Einreichungsweg beschreibt How ISVs Pass the Salesforce AppExchange Security Review.

Die Checkliste auf einen Blick

1. Klären Sie, was Sie einreichen: ein Managed Package plus jeden externen Dienst, den es berührt.
2. Beheben Sie die Zugriffskontrolle: User Mode, explizites Sharing, kein injizierbares SOQL.
3. Beheben Sie Ausgabebehandlung, Secrets, Transportsicherheit und Authentifizierung.
4. Führen Sie Code Analyzer, den Source Scan des Partner Security Portal und einen DAST-Scan aus.
5. Beheben Sie, was die Messlatte jedes Scanners verlangt, und dokumentieren Sie jeden False Positive.
6. Bündeln Sie Dokumentation, Zugangsdaten und eine funktionierende Test-Org.
7. Reichen Sie über die Partner Console ein und planen Sie die jährliche erneute Prüfung ein.

Was sich 2026 geändert hat

Drei Dinge haben sich dieses Jahr verschoben, und ältere Checklisten kennen keines davon.

• Der Marktplatz heißt jetzt AgentExchange. Salesforce hat AppExchange in AgentExchange umbenannt und auf der TrailblazerDX 2026 den Slack Marketplace darin aufgehen lassen. Das Trailhead-Material von Salesforce nutzt inzwischen den neuen Namen, die Security Review bleibt aber die Hürde zu einem Listing.
• Apex API-Version 67.0 ändert die Sicherheits-Defaults. Laut den Summer '26 Architect Highlights von Salesforce laufen Datenbankoperationen jetzt standardmäßig im User Mode, Klassen ohne Sharing-Deklaration erhalten standardmäßig with sharing, und WITH SECURITY_ENFORCED ist entfernt, sodass eine Klasse, die es auf v67.0 noch nutzt, nicht kompiliert. Ausnahme sind Trigger: Sie laufen immer im System Mode.
• Den dynamischen Scan führen Sie selbst aus. Die Vorbereitungshinweise von Salesforce empfehlen jetzt OWASP ZAP oder Burp Suite Enterprise Edition für externe Endpunkte und akzeptieren Ihren bevorzugten DAST-Scanner. Siehe Eigene dynamische Scans nach Chimera für die Tools und den einzureichenden Bericht.

Schritt 1: Den Umfang klären

Salesforce stellt klar, dass alle Komponenten und Dienste Ihrer Lösung geprüft werden können, egal wo sie laufen. Das umfasst das Package, jeden aufgerufenen Webservice, jede Site, die Salesforce-Daten speichert, und jeden mobilen oder Desktop-Client. Legen Sie den Package-Typ fest, bevor Sie Code reparieren, denn er bestimmt, was Sie hochladen; der Artikel Salesforce Packaging Models for ISVs: 1GP vs 2GP vs Unmanaged behandelt diese Wahl.

Schritt 2: Die Befunde beheben, die Einreichungen scheitern lassen, in dieser Reihenfolge

Arbeiten Sie von oben nach unten. Die oberen Punkte sind zugleich die häufigsten Befunde und die teuersten beim nachträglichen Einbau, und deshalb verschiebt sich eine Einreichung um einen Zyklus, wenn man sie bis zuletzt liegen lässt.

1. Zugriffskontrolle, die nicht im User Mode erzwungen wird. Jede Abfrage und jede DML-Operation muss Objektrechte, Field-Level Security und Sharing des ausführenden Benutzers beachten. Verlassen Sie sich nicht allein auf den v67.0-Default: Ein Package enthält meist Klassen auf älteren API-Versionen, und Trigger-Handler können aus einem Trigger im System Mode aufgerufen werden. Setzen Sie den Zugriffsmodus explizit mit WITH USER_MODE bei SOQL und AccessLevel.USER_MODE bei Database-Aufrufen, und ersetzen Sie verbliebenes WITH SECURITY_ENFORCED, bevor Sie die API-Version anheben.
2. Sharing auf den falschen Klassen deklariert. Unterhalb von v67.0 erbt eine Klasse ohne Sharing-Schlüsselwort das Sharing des Aufrufers, sodass ein Helper, der aus einer @AuraEnabled-Methode aufgerufen wird, unbemerkt ohne Sharing laufen kann. Deklarieren Sie with sharing, without sharing oder inherited sharing explizit auf jeder Klasse, auch auf inneren und Utility-Klassen, damit der Reviewer nie klären muss, welcher Default gilt.
3. Dynamisches SOQL, das aus Eingaben zusammengesetzt wird. Nutzen Sie Bind-Variablen. Muss eine Abfrage wirklich als String gebaut werden, escapen Sie jeden eingesetzten Wert und halten Sie dieses Escaping in derselben Methode sichtbar, denn dort liest der Reviewer es.
4. Nicht escapte Ausgabe. Alles, was über escape="false", lwc:dom="manual" oder innerHTML auf die Seite gelangt, muss vorher bereinigt werden, nicht nachher.
5. Secrets und Kundendaten am falschen Ort. Hartkodierte Schlüssel in Apex, Tokens in ungeschützten Custom Settings, ein Datensatz mit personenbezogenen Daten in System.debug. Reviewer erwarten stattdessen Named Credentials und geschützte Custom Metadata.
6. Schwache Transport- oder Speicherverschlüsselung. Die Liste der häufigsten Review-Befunde von Salesforce verlangt TLS 1.2 für Verbindungen mit Ihren Sites und Portalen, und das Team scannt jeden externen Endpunkt darauf. Verschlüsseln Sie auch alles, was Sie außerhalb der Plattform speichern.
7. Externe Systeme mit gespeichertem Benutzernamen und Passwort. Nutzen Sie OAuth für jede Verbindung, die Ihr Package zu einem Dienst aufbaut, den Sie oder der Kunde betreiben. Gespeicherte Zugangsdaten sind für sich schon ein Befund, und sie machen das Datenflussdokument schwerer zu verteidigen.
8. Eine Composite Site ohne die Grundlagen. Enthält Ihre Lösung eine Weboberfläche außerhalb der Org, braucht sie Security Header, und ihre Cookies brauchen Secure und HttpOnly. Reviewer prüfen die Site, die Sie ihnen geben, nicht die, die Sie beschreiben.
9. Externe Endpunkte, die niemand gescannt hat. Ruft Ihr Package einen Dienst auf, den Sie betreiben, liegt dieser im Umfang und braucht einen eigenen Bericht eines dynamischen Scans.
10. Eine Testumgebung, die der Reviewer nicht nutzen kann. Eine abgelaufene Org, eine Identitätsabfrage, die ihn aussperrt, oder Objekte ohne Daten. Salesforce rät Partnern, das Review-Team wie einen potenziellen Kunden zu behandeln, der die gesamte Lösung von Anfang bis Ende ausprobiert, und was nicht läuft, lässt sich nicht prüfen.

Schritt 3: Scanner ausführen und die Messlatte jedes Scanners erfüllen

Sie müssen einen Salesforce-Code-Analyzer-Bericht, einen Bericht des Source Scanners im Partner Security Portal und einen DAST-Bericht beilegen. Die Messlatte ist nicht null Befunde, und sie unterscheidet sich je Scanner:

• Salesforce Code Analyzer: Beheben Sie alle sicherheitsrelevanten Befunde und Fehler außer False Positives und ignorieren Sie Befunde ohne Sicherheitsbezug. Externe Endpunkte scannt er nicht.
• Source Scanner des Partner Security Portal (Checkmarx): Beheben Sie Low-, Medium- und High-Befunde und lassen Sie informative Warnungen stehen.
• DAST-Scanner wie ZAP, Burp Suite, Veracode Dynamic Analysis, Intruder und Acunetix: Beheben Sie alles außer informativen Einträgen und Warnungen und fügen Sie einen Screenshot bei, der belegt, dass der richtige externe Endpunkt gescannt wurde.

Erzeugen Sie den Code-Analyzer-v5-Bericht mit dem AppExchange-Regelselektor, damit er dem entspricht, was der Reviewer erwartet. Bei einer komplexen Codebasis kann der Lauf Stunden dauern:

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

Welche Scans verpflichtend sind, hat sich mehrfach geändert. Prüfen Sie daher die aktuellen Scanner-Anforderungen, bevor Sie etwas erzeugen.

Schritt 4: Jeden False Positive dokumentieren

In unseren Einreichungen tauchen vier Kategorien oft genug als echte False Positives auf, dass man sie einplanen sollte: Zugriffskontroll-Befunde zu Code, der den User Mode bereits erzwingt, Sharing-Befunde zu Klassen, die nur aus einem Kontext mit bereits angewendetem Sharing betreten werden, Befunde zu veralteten Bibliotheken, die auf eine Versionszeichenfolge in einer mitgelieferten Static Resource anschlagen, und Reflected Cross-Site-Scripting-Befunde zu Parametern, die nie das DOM erreichen.

Recht zu haben reicht allerdings nicht. Das Dokument entscheidet. Salesforce verlangt ein Dokument, das erklärt, warum jeder markierte Punkt kein Sicherheitsrisiko darstellt und sagt, Sie sollen konkret beschreiben, wie Sie sich gegen die angezeigte Schwachstelle schützen. Geben Sie jedem Befund einen eigenen Eintrag: Scanner und Regel-ID, Datei und Zeile, ein Satz zum Datenpfad, die genaue schützende Kontrolle und wo diese im Package liegt. Einzeilige Abweisungen kommen als Rückfragen zurück, und Rückfragen kosten Wochen. Zum Begründungsformat und zu den Fehlern, die es scheitern lassen, siehe False Positives für die Salesforce Security Review dokumentieren.

Schritt 5: Die Einreichungsunterlagen zusammenstellen

• Eine Nutzungsdokumentation, die so geschrieben ist, dass jemand, der die App nie gesehen hat, einen vollständigen Workflow durchlaufen kann.
• Eine Datenflussdokumentation zwischen der Salesforce-Org und jeder Composite Site, mobilen App oder Browser-Erweiterung.
• Jeden Scan-Bericht, den DAST-Endpunkt-Screenshot und 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, oder eine gehostete Testinstanz davon.
• Installationslinks und Zugangsdaten für mobile oder Desktop-Clients.

Die Review starten Sie dann in der Publishing Partner Console: Öffnen Sie den Tab Technologies, wählen Sie bei Ihrer Lösung Start Review und füllen Sie vor der Zahlung die Abschnitte Kontakte, technische Details, Dokumentation und Testumgebung aus.

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

Salesforce gibt an, dass eine Lösung typischerweise 4 bis 5 Wochen für die Review braucht und dass für jede kostenpflichtige Lösung eine Gebühr von 999 $ anfällt für die erste Einreichung und jeden weiteren Versuch. Findet das Team Schwachstellen, beheben Sie sie und reichen erneut ein, was als weiterer Versuch zählt. Salesforce vermerkt außerdem, dass die meisten Einreichungen im zweiten Versuch bestehen. Beides spricht für dasselbe: Erledigen Sie die Arbeit an der Zugriffskontrolle zuerst, denn die günstigste Einreichung ist die, die Sie nur einmal machen müssen.

Möchten Sie die Review lieber Leuten überlassen, die sie schon bestanden haben? Tekunda bietet als Salesforce-Partner Vorbereitung auf die AppExchange Security Review an. Wenn Sie noch abwägen, ob Sie externe Hilfe holen, lesen Sie Was ein Salesforce PDO macht, und wann Sie einen beauftragen.

FAQ

Müssen kostenlose Apps durch die Security Review?

Ja. Eine Lösung muss die Review bestehen, bevor sie auf dem Marktplatz gelistet wird. Die von Salesforce dokumentierte Gebühr von 999 $ gilt für kostenpflichtige Lösungen.

Heißt API-Version 67.0, dass ich CRUD-, FLS- und Sharing-Arbeit überspringen kann?

Nein. Die neuen Defaults gelten nur für Klassen, die mit v67.0 oder höher kompiliert sind, und Trigger laufen weiterhin im System Mode. Deklarieren Sie Zugriffsmodi und Sharing explizit, damit der Reviewer sie Zeile für Zeile prüfen kann.

Reicht Salesforce Code Analyzer allein?

Nein. Sie brauchen außerdem den Bericht des Source Scanners im Partner Security Portal, und jeder externe Endpunkt, den Ihre App aufruft, braucht einen eigenen DAST-Bericht.

Ändert eine Agentforce- oder agentenbasierte App die Checkliste?

Es gilt dieselbe Review, aber jeder externe Dienst, den Ihr Agent aufrufen kann, muss beschrieben und gescannt werden. Siehe AppExchange Security Review für agentische Apps: was anders ist.

Ist die Security Review ein einmaliges Ereignis?

Nein. Gelistete Lösungen werden typischerweise einmal im Jahr erneut geprüft, und Salesforce kann jederzeit eine Review verlangen. Neue Package-Versionen nutzen eine Bestätigung in der Partner Console statt einer neuen Review, also behalten Sie die Checkliste als festes Release-Gate.