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 Gruende, aus denen ein Reviewer ein Package zurueckschickt. Salesforce nennt 4 bis 5 Wochen fuer eine typische Pruefung, 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 haeufigsten Findings und die teuersten, wenn man sie nachtraeglich 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 ausfuehrenden Benutzers respektieren. Nutzen Sie WITH USER_MODE in SOQL und AccessLevel.USER_MODE bei Database-Aufrufen statt selbst gebauter isAccessible()-Ketten, die leicht unvollstaendig 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 ausdruecklich 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 ueber 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 Schluessel 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. Externe Endpunkte, die niemand gescannt hat. Ruft Ihr Package einen Dienst auf, den Sie selbst betreiben, gehoert dieser Dienst zum Pruefumfang und braucht einen eigenen dynamischen Scan-Report.
7. 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 Loesung end to end wie ein Kunde und kann nicht pruefen, was nicht laeuft.

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 ausser informativen Punkten und Warnungen, und legen Sie einen Screenshot bei, der belegt, dass der richtige Endpunkt gescannt wurde.

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

In unseren Einreichungen kommen vier Kategorien oft genug als echte False Positives zurueck, dass man sie einplanen sollte: Zugriffskontroll-Findings gegen Code, der User Mode bereits durchsetzt, Sharing-Findings an Klassen, die nur ueber 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 Pruefung bringt Sie das Dokument. Salesforce verlangt ein Dokument, das erklaert, warum jeder markierte Punkt kein Sicherheitsrisiko darstellt, und fordert dabei konkret zu beschreiben, wie Sie sich gegen die angezeigte Schwachstelle schuetzen. Geben Sie jedem Finding einen eigenen Eintrag: Scanner und Regel-ID, Datei und Zeile, ein Satz zum Datenpfad, die genaue Schutzmassnahme und die Stelle im Package, an der sie sitzt. Einzeilige Abweisungen kommen als Rueckfrage zurueck, und Rueckfragen kosten Wochen. Fuer eine ausfuehrliche Anleitung zum Begruendungsformat und den Fehlern, die es ablehnen lassen, siehe False Positives fuer die Salesforce Security Review dokumentieren.

Was gehoert neben dem Package in die Einreichung?

• Nutzungsdokumentation, geschrieben so, dass jemand ohne Vorkenntnis der App einen vollstaendigen Workflow durchlaufen kann.
• Dokumentation der Datenfluesse zwischen der Salesforce-Org und jeder Composite Site, mobilen App oder Browser-Erweiterung.
• Saemtliche Scan-Reports plus das False-Positive-Dokument.
• Eine Developer-Edition-Org mit installiertem Package und realistischen Testdaten.
• Zugangsdaten fuer jedes externe System, das die App beruehrt, inklusive API-, OAuth- und SAML-Zugriff.
• Installationslinks und Zugangsdaten fuer mobile oder Desktop-Clients.

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

Salesforce gibt an, dass eine Loesung typischerweise 4 bis 5 Wochen durch die Pruefung braucht, und dass fuer jede kostenpflichtige Loesung auf dem Marktplatz eine Gebuehr von $999 fuer die Ersteinreichung und fuer jeden weiteren Versuch anfaellt. Beides spricht fuer dasselbe Vorgehen: Ziehen Sie die Arbeit an der Zugriffskontrolle nach vorn, denn die guenstigste Einreichung ist die, die man nur einmal macht.

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

FAQ

Muessen auch kostenlose Apps durch die Security Review?

Ja. Jede Loesung, die ueber den Marktplatz verteilt wird, muss die Pruefung bestehen, bevor sie gelistet wird. Die von Salesforce dokumentierte Gebuehr betrifft kostenpflichtige Loesungen.

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 zusaetzlich einen eigenen dynamischen Scan-Report.

Was ist der haeufigste Ablehnungsgrund?

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

Aendert eine Agentforce- oder Agenten-App die Checkliste?

Fuer agentische Loesungen gilt dieselbe Security Review. Der Unterschied zeigt sich in der Dokumentation der Datenfluesse, denn jeder externe Dienst, den Ihr Agent aufrufen kann, muss beschrieben und gescannt sein.