Comment les ISV réussissent la Security Review AppExchange

La plupart des rejets de la Security Review AppExchange ne viennent pas de bugs exotiques. Ils se ramènent à une liste courte et prévisible : CRUD/FLS non appliqués, violations de sharing, paramètres de session faibles et secrets dans les métadonnées. Les ISV qui traitent la review comme un audit de code deux semaines avant la soumission y perdent généralement un cycle complet.

Pourquoi les applications échouent-elles à la Security Review de Salesforce ?

L'équipe de review de Salesforce exécute une analyse statique (Checkmarx, PMD via Salesforce Code Analyzer). Depuis le retrait du scanner hébergé Chimera le 2025-06-16, le scan dynamique des endpoints tiers appelés par votre package vous revient, à vous de l'exécuter et de le soumettre, comme l'explique Exécuter vos propres scans dynamiques après Chimera. Les échecs que nous voyons le plus souvent sur les missions ISV se répartissent en quatre catégories :

• Lacunes CRUD/FLS. Du code Apex qui lit ou écrit des objets sans vérifier les accès de l'utilisateur courant aux objets et aux champs, notamment dans les contrôleurs Visualforce et les endpoints REST.
• Déclarations de sharing manquantes. Des classes sans with sharing qui exécutent du DML, ou une classe "with sharing" qui appelle un helper "without sharing" et hérite de son contexte plus permissif.
• Mauvaise configuration des sessions et de l'identité. Des orgs de test où l'identity challenge ou la MFA bloque les outils du reviewer, au lieu de l'approche recommandée par liste d'adresses IP autorisées.
• Secrets au mauvais endroit. Des clés API stockées dans des custom metadata types que tout admin abonné peut interroger, et des données personnelles journalisées via System.debug.

Comment préparer une application pour la Security Review AppExchange ?

La préparation relève surtout de la discipline, pas de nouveaux outils. Avant de demander une review :

• Exécutez Salesforce Code Analyzer sur l'ensemble du package, pas seulement sur les classes récemment modifiées, et triez chaque résultat.
• Vérifiez que chaque instruction DML se trouve dans une classe déclarée with sharing, ou documentez le cas précis de contournement de CRUD/FLS (les agrégats roll-up et les objets de journalisation internes sont les deux cas que Salesforce accepte généralement).
• Analysez chaque domaine non Salesforce appelé par votre package avec un scanner d'applications web approuvé et corrigez les résultats de gravité élevée avant la soumission.
• Sortez les secrets des métadonnées et placez-les dans des Named Credentials ou un coffre externe référencé à l'exécution.

Que signifie réellement un faux positif de Checkmarx ou PMD ?

Les scanners signalent des motifs, pas des intentions, donc une partie de chaque rapport n'est que du bruit : une requête SOQL qui ressemble seulement à une concaténation de chaînes, ou une ligne de debug qui ne touche jamais de données utilisateur. Traiter chaque ligne signalée comme un changement de code obligatoire gaspille un cycle. Le chemin le plus rapide consiste à évaluer chaque résultat selon le risque réel, à corriger ce qui est réellement exploitable et à rédiger une courte justification pour le reste. Les reviewers lisent les justifications, ils ne récompensent pas les affirmations générales de type "corrigé" qui ne tiennent pas à un nouveau scan.

Comment un partenaire d'implémentation réduit-il le risque de la Security Review ?

Un partenaire qui a déjà fait passer des packages en review sait quels résultats méritent d'être discutés et lesquels il vaut mieux simplement corriger, et c'est ce jugement qui fait gagner du temps. Tekunda a piloté de bout en bout des Security Reviews AppExchange pour des clients ISV, de l'audit initial de l'Apex et des intégrations jusqu'à la nouvelle soumission après les retours des reviewers. Les deux ou trois allers-retours qui surprennent les primo-déposants arrivent donc rarement sur nos missions.

La surface d'intégration élargit vite le périmètre de la review : chaque callout, chaque paramètre remote site et chaque domaine qui stocke des données Salesforce entre dans le scan d'application web du reviewer. Réussir cela du premier coup, grâce à notre travail d'ingénierie d'intégration, fait généralement la différence entre une soumission propre et une deuxième série de résultats.

Que se passe-t-il si la review revient avec des résultats ?

Un rejet n'est pas un retour à zéro. Si les résultats ne concernent que du code exécuté sur la plateforme Salesforce, téléversez une nouvelle version du managed package et relancez la review depuis l'onglet Packages. Si le correctif se trouvait entièrement dans votre application externe, vous pouvez généralement modifier la soumission existante. Dans les deux cas, ouvrez un case auprès de "Partner Community & AppExchange" avec le nom, l'ID et la version de votre package, afin que l'équipe de review rattache votre nouvelle soumission à la bonne file.

FAQ

Combien de temps dure la Security Review de Salesforce ?

Les délais varient selon la complexité de la soumission et le volume actuel de reviews, et Salesforce ne publie pas de SLA fixe. Prévoyez donc une marge dans vos calendriers de release.

Un ISV peut-il éviter la review pour un package à public restreint ?

Non. Tout managed package, solution Platform API ou solution Marketing Cloud API distribué sur AppExchange doit réussir la review avant son listing, quelle que soit la taille du public visé.

La review s'applique-t-elle aux packages unmanaged ?

Le processus formel de Security Review s'applique spécifiquement aux managed packages 2GP et 1GP et aux solutions basées sur API soumis pour un listing AppExchange.

Quelle est l'erreur CRUD/FLS la plus courante ?

Construire un contrôleur ou un endpoint REST qui lit ou écrit directement un objet via SOQL/DML sans vérifier d'abord les permissions de l'utilisateur courant, ce qui contourne en silence les restrictions des profils et des permission sets.

Faire passer proprement un package en review n'est qu'une partie de la livraison sur AppExchange ; bien construire le produit et les intégrations du premier coup est la partie la plus difficile. Si vous préparez une soumission ou planifiez votre prochaine release, parlez à notre équipe d'ingénierie produit ou contactez-nous pour cadrer le travail.