Skip to content
Tekunda Team

Tekunda Team

Wie ISVs die Salesforce AppExchange Security Review bestehen

Wie ISVs die Salesforce AppExchange Security Review bestehen

Die meisten Ablehnungen in der AppExchange Security Review haben nichts mit exotischen Bugs zu tun. Sie lassen sich auf eine kurze, vorhersehbare Liste zurückführen: nicht durchgesetztes CRUD/FLS, Sharing-Verstöße, schwache Sitzungseinstellungen und Secrets in Metadaten. ISVs, die die Review als Code-Audit zwei Wochen vor der Einreichung behandeln, verlieren dadurch meist einen ganzen Zyklus.

Warum fallen Apps durch die Salesforce Security Review?

Das Review-Team von Salesforce führt eine statische Analyse durch (Checkmarx, PMD über Salesforce Code Analyzer). Seit der gehostete Chimera-Scanner am 2025-06-16 eingestellt wurde, müssen Sie den dynamischen Scan aller Drittanbieter-Endpoints, die Ihr Package aufruft, selbst durchführen und einreichen, wie in Eigene dynamische Scans nach Chimera beschrieben. Die Fehler, die wir in ISV-Projekten am häufigsten sehen, fallen in vier Kategorien:

  • CRUD/FLS-Lücken. Apex, das Objekte liest oder schreibt, ohne die Objekt- und Feldberechtigungen des aktuellen Benutzers zu prüfen, vor allem in Visualforce-Controllern und REST-Endpoints.
  • Fehlende Sharing-Deklarationen. Klassen ohne with sharing, die DML ausführen, oder eine "with sharing"-Klasse, die einen "without sharing"-Helper aufruft und dessen lockereren Kontext erbt.
  • Falsch konfigurierte Sitzungen und Identitäten. Test-Orgs, in denen Identity Challenge oder MFA die Tools des Reviewers blockieren, statt des empfohlenen Ansatzes mit einer IP-Allowlist.
  • Secrets am falschen Ort. API-Schlüssel in Custom Metadata Types, die jeder Abonnenten-Admin abfragen kann, und personenbezogene Daten, die über System.debug protokolliert werden.

Wie bereiten Sie eine App auf die AppExchange Security Review vor?

Vorbereitung ist vor allem Disziplin, kein neues Tooling. Bevor Sie eine Review beantragen:

  • Führen Sie den Salesforce Code Analyzer für das gesamte Package aus, nicht nur für kürzlich geänderte Klassen, und bewerten Sie jedes Ergebnis.
  • Stellen Sie sicher, dass jede DML-Anweisung in einer mit with sharing deklarierten Klasse steht, oder dokumentieren Sie den konkreten Grund für das Umgehen von CRUD/FLS (Roll-up-Aggregate und interne Logging-Objekte sind die beiden Fälle, die Salesforce in der Regel akzeptiert).
  • Scannen Sie jede Nicht-Salesforce-Domain, die Ihr Package aufruft, mit einem zugelassenen Webanwendungs-Scanner, und beheben Sie Ergebnisse mit hohem Schweregrad vor der Einreichung.
  • Verlagern Sie Secrets aus den Metadaten in Named Credentials oder einen externen Secret Store, der zur Laufzeit referenziert wird.

Was bedeutet ein False Positive von Checkmarx oder PMD wirklich?

Scanner markieren Muster, keine Absichten, deshalb ist ein Teil jedes Berichts Rauschen: eine SOQL-Abfrage, die nur wie eine String-Verkettung aussieht, oder eine Debug-Zeile, die nie Benutzerdaten berührt. Jede markierte Zeile als zwingende Codeänderung zu behandeln, kostet einen Zyklus. Schneller ist es, jedes Ergebnis am tatsächlichen Risiko zu messen, das wirklich Ausnutzbare zu beheben und für den Rest eine kurze Begründung zu schreiben. Reviewer lesen Begründungen, sie belohnen aber keine pauschalen "behoben"-Aussagen, die einem erneuten Scan nicht standhalten.

Wie senkt ein Implementierungspartner das Risiko der Security Review?

Ein Partner, der schon Packages durch die Review gebracht hat, weiß, welche Ergebnisse die Diskussion wert sind und welche man besser einfach behebt, und genau aus diesem Urteil entsteht die Zeitersparnis. Tekunda hat AppExchange Security Reviews für ISV-Kunden von Anfang bis Ende geleitet, vom ersten Audit von Apex und Integrationen bis zur erneuten Einreichung nach dem Feedback der Reviewer. Die zwei oder drei Zusatzrunden, die Erstanmelder überraschen, kommen in unseren Projekten deshalb selten vor.

Die Integrationsfläche vergrößert den Review-Umfang schnell: Jeder Callout, jede Remote-Site-Einstellung und jede Domain, die Salesforce-Daten speichert, fällt unter den Webanwendungs-Scan des Reviewers. Das beim ersten Mal richtig zu machen, durch unsere Integrationsentwicklung, ist meist der Unterschied zwischen einer sauberen Einreichung und einer zweiten Runde von Ergebnissen.

Was passiert, wenn die Review mit Ergebnissen zurückkommt?

Eine Ablehnung ist kein Neustart. Betreffen die Ergebnisse nur Code, der auf der Salesforce-Plattform läuft, laden Sie eine neue Version des Managed Package hoch und starten die Review über den Tab Packages erneut. Lag die Korrektur vollständig in Ihrer externen Anwendung, können Sie in der Regel die bestehende Einreichung bearbeiten. In beiden Fällen eröffnen Sie einen Case unter "Partner Community & AppExchange" mit Package-Name, ID und Version, damit das Review-Team Ihre erneute Einreichung der richtigen Warteschlange zuordnet.

FAQ

Wie lange dauert die Salesforce Security Review?

Die Dauer hängt von der Komplexität der Einreichung und dem aktuellen Review-Aufkommen ab, und Salesforce veröffentlicht keine feste SLA. Planen Sie Ihre Release-Kalender also mit Puffer.

Kann ein ISV die Review bei einem Package für eine kleine Zielgruppe überspringen?

Nein. Jedes Managed Package, jede Platform-API-Lösung und jede Marketing-Cloud-API-Lösung, die über AppExchange vertrieben wird, muss die Review vor dem Listing bestehen, unabhängig von der Größe der Zielgruppe.

Gilt die Review auch für Unmanaged Packages?

Das formelle Security-Review-Verfahren gilt speziell für Managed 2GP- und 1GP-Packages sowie API-basierte Lösungen, die für ein AppExchange-Listing eingereicht werden.

Was ist der häufigste CRUD/FLS-Fehler?

Ein Controller oder REST-Endpoint, der ein Objekt direkt per SOQL/DML liest oder schreibt, ohne zuerst die Berechtigungen des aktuellen Benutzers zu prüfen, und damit Einschränkungen aus Profilen und Permission Sets stillschweigend umgeht.

Ein Package sauber durch die Review zu bringen ist nur ein Teil der Auslieferung auf AppExchange. Produkt und Integrationen gleich richtig zu bauen, ist der schwierigere Teil. Wenn Sie eine Einreichung vorbereiten oder Ihr nächstes Release planen, sprechen Sie mit unserem Product-Engineering-Team oder nehmen Sie Kontakt auf, um den Umfang zu klären.

Ähnliche Artikel