Wie die Einreichungsschleife der AppExchange Security Review Funktioniert

Die AppExchange Security Review ist eine Schleife, kein Tor. Du bewertest selbst, reichst ein, bekommst einen Befundbericht zurück, behebst und reichst erneut ein, bis Salesforce freigibt. Zu wissen, was jede Runde kostet und welche Befunde eine erzwingen, entscheidet zwischen mehreren Zyklen und einem einzigen Durchlauf.

Tekunda bringt Managed Packages als Salesforce PDO durch die AppExchange Security Review. Das Folgende ist die Schleife, so wie wir sie fahren.

Was passiert nach dem Einreichen?

Deine Einreichung landet in einer Warteschlange, dann laufen drei Perspektiven dagegen: statische Codeanalyse mit dem Salesforce Code Analyzer, dynamische Tests gegen eine laufende Org und eine manuelle Prüfung durch das Product-Security-Team von Salesforce. Zurück kommt ein Befundbericht, kein Urteil, und jede Zeile darin wird entweder behoben oder schriftlich erklärt. Salesforce gibt an, dass eine Lösung typischerweise 4 bis 5 Wochen durch die Review braucht, und dass für jede kostenpflichtige Lösung auf dem Marketplace eine Gebühr von 999 $ anfällt, für die erste Einreichung wie für jeden weiteren Versuch. Genau das macht eine zusätzliche Runde teuer: eine weitere Rechnung und ein weiterer Durchlauf derselben Warteschlange.

Was behebst du vor der ersten Runde?

Alles, was ein Scanner allein findet. Zugriffskontrolle im User Mode durchgesetzt, Sharing auf jeder Apex-Klasse deklariert, Bind-Variablen statt zusammengesetzter SOQL, maskierte Ausgaben und Geheimnisse in Named Credentials oder Protected Custom Metadata statt im Code. Die vollständige Liste, in der Reihenfolge mit dem geringsten Aufwand, steht in Salesforce Security Review Checklist: What to Fix, In Order. Ein Befund, den du selbst hättest finden können, ist der teuerste, denn er kauft eine ganze zusätzliche Runde.

Wie fährst du die Schleife Schritt für Schritt?

1. Selbst bewerten. Führe den Code Analyzer und deinen eigenen dynamischen Scan aus, triagiere jeden Befund und behebe die echten. Salesforce hat den gehosteten Chimera-Scanner am 2025-06-16 abgeschaltet, den dynamischen Scan fährst du also selbst. Siehe Running Your Own Dynamic Scans After Chimera für die akzeptierten Tools und den beizulegenden Bericht.
2. Dokumentiere, was übrig bleibt. Jeder Befund, den du nicht behebst, braucht eine eigene schriftliche Begründung: Scanner und Regel, Datei und Zeile, der Datenpfad und die schützende Kontrolle. How to Document False Positives for the Salesforce Security Review beschreibt das Format, das Prüfer akzeptieren.
3. Stelle die Einreichung zusammen. Arbeite die Security Review Requirements Checklist in der Partner Community durch: Scan-Berichte, das False-Positive-Dokument, Nutzungs- und Datenflussdokumentation, Zugangsdaten für jedes externe System und eine Developer Edition Org mit realistischen Daten, die ein Prüfer wirklich bedienen kann.
4. Einreichen und die Version in Ruhe lassen. Die Warteschlange ist kein Ort zum Weiteriterieren. Friere die eingereichte Package-Version ein und entwickle auf einem Branch weiter, damit Prüfer und Team nie unterschiedlichen Code lesen.
5. Anhand des Berichts beheben. Behandle ihn als Aufgabenliste und behebe jeden Punkt an der Wurzel statt am gemeldeten Symptom, denn der nächste Scan läuft wieder über das ganze Package.
6. Mit Belegen erneut einreichen. Beantworte jeden Befund ausdrücklich, auch die, denen du widersprochen hast, und sag, wo die Korrektur liegt. Unbeantwortete Punkte machen aus einer zweiten Runde eine dritte.

Was schickt ein Package ein zweites Mal in die Schleife?

Jedes Mal dieselbe kurze Liste: fehlende CRUD/FLS-Prüfungen, dynamische SOQL aus Eingaben, nicht maskierte Ausgaben, Cross-Site-Request-Forgery, unsichere direkte Objektreferenzen und Apex-Klassen, die nie Sharing deklariert haben. Fast alle sind in der Selbstbewertung zu fangen. Der andere Wiederholungstäter ist prozessual statt technisch, ein veralteter oder unerklärter Scan-Bericht oder eine Test-Org, in die der Prüfer sich nicht einloggen kann, was die Runde stoppt, bevor der Code überhaupt gelesen wird.

Wo Tekunda passt

Gelistete Packages werden periodisch erneut geprüft, die Schleife schließt sich also nie ganz. Ein lebendiges Remediation-Log zu führen und die Scans bei jedem Release statt bei jeder Einreichung zu fahren, macht die nächste Runde zur Formsache. Wenn du die Review lieber von Leuten machen lässt, die sie schon bestanden haben: Tekunda baut und packaged AppExchange-Produkte als Salesforce PDO.

FAQ

Wie lange dauert die AppExchange Security Review?

Salesforce gibt an, dass eine Lösung typischerweise 4 bis 5 Wochen durch die Review braucht. Eine Wiedereinreichung geht wieder in dieselbe Warteschlange, plane also eine zweite Runde in den Release-Kalender ein, statt auf eine Überholspur zu setzen.

Wie viel kostet die Security Review?

Salesforce dokumentiert eine Gebühr von 999 $ für jede kostenpflichtige Lösung auf dem Marketplace, für die erste Einreichung wie für jeden weiteren Versuch. Ein sauberer erster Durchlauf ist der einzige Weg, sie nur einmal zu zahlen.

Ist der Salesforce-Code-Analyzer-Scan verpflichtend?

Ja, für Managed Packages, die auf AppExchange gelistet werden. Lade die Code-Analyzer-Ergebnisse mit deiner Einreichung hoch, zusammen mit einem dynamischen Scan-Bericht für jeden externen Endpunkt, den dein Package aufruft.

Was hat Chimera für dynamisches Scannen ersetzt?

Nichts Gehostetes. Seit Chimera am 2025-06-16 abgeschaltet wurde, führen Partner ihre eigenen dynamischen Sicherheitstests mit Werkzeugen wie OWASP ZAP, Burp Suite oder Qualys durch und reichen den Bericht ein.

Muss ich die Review wiederholen?

Ja. Gelistete Packages unterliegen einer periodischen erneuten Prüfung, also baue Remediation und Dokumentation in deinen Release-Prozess ein, statt Sicherheit als einmaliges Ereignis zu behandeln.