Comment fonctionne la boucle de soumission de la revue de sécurité AppExchange

La revue de sécurité AppExchange est une boucle, pas un portail. Vous vous auto-évaluez, vous soumettez, vous recevez un rapport de constats, vous corrigez et vous resoumettez jusqu'à la validation de Salesforce. Savoir ce que coûte chaque tour, et quels constats en imposent un, fait la différence entre plusieurs cycles et une réussite du premier coup.

Tekunda fait passer des packages managés par la revue de sécurité AppExchange en tant que PDO Salesforce. Voici la boucle telle que nous la menons.

Que se passe-t-il après la soumission ?

Votre soumission entre dans une file d'attente, puis trois angles s'appliquent : l'analyse statique du code avec le Salesforce Code Analyzer, les tests dynamiques sur une org en fonctionnement, et une revue manuelle par l'équipe sécurité produit de Salesforce. Ce qui revient est un rapport de constats, pas un verdict, et chaque ligne est soit corrigée, soit expliquée par écrit. Salesforce indique qu'une solution met généralement 4 à 5 semaines à traverser la revue, et que pour chaque solution payante vendue sur la marketplace il y a des frais de 999 $, pour la première soumission comme pour chaque tentative suivante. C'est ce qui rend un tour supplémentaire coûteux : une facture de plus, et un passage de plus dans la même file.

Que corriger avant le premier tour ?

Tout ce qu'un scanner trouve sans aide. Contrôle d'accès appliqué en user mode, partage déclaré sur chaque classe Apex, variables liées plutôt que SOQL concaténée, sorties échappées, et secrets dans des Named Credentials ou des Protected Custom Metadata plutôt que dans le code. La liste complète, dans l'ordre le moins coûteux, est dans Salesforce Security Review Checklist: What to Fix, In Order. Un constat que vous auriez pu détecter vous-même est le plus cher de tous, parce qu'il achète un tour entier.

Comment mener la boucle, étape par étape ?

1. Auto-évaluez. Lancez le Code Analyzer et votre propre scan dynamique, triez chaque constat et corrigez les vrais. Salesforce a retiré le scanner hébergé Chimera le 2025-06-16, le scan dynamique vous revient donc. Voir Running Your Own Dynamic Scans After Chimera pour les outils acceptés et le rapport à joindre.
2. Documentez ce qui reste. Chaque constat que vous ne corrigez pas exige sa propre justification écrite : scanner et règle, fichier et ligne, le chemin de la donnée, et le contrôle qui la protège. How to Document False Positives for the Salesforce Security Review décrit le format que les relecteurs acceptent.
3. Constituez la soumission. Parcourez la Security Review Requirements Checklist de la Partner Community : rapports de scan, document de faux positifs, documentation d'usage et de flux de données, identifiants pour chaque système externe, et une org Developer Edition avec des données réalistes qu'un relecteur peut vraiment manipuler.
4. Soumettez, puis laissez la version tranquille. La file d'attente n'est pas un endroit où continuer à itérer. Gelez la version du package soumise et continuez à développer sur une branche, pour que le relecteur et votre équipe ne lisent jamais un code différent.
5. Corrigez à partir du rapport. Traitez-le comme une liste de tâches et corrigez chaque point à la racine plutôt qu'au symptôme signalé, car le scan suivant repasse sur tout le package.
6. Resoumettez avec des preuves. Répondez explicitement à chaque constat, y compris ceux que vous contestiez, et dites où se trouve la correction. Les points laissés sans réponse transforment un deuxième tour en troisième.

Qu'est-ce qui renvoie un package pour un deuxième tour ?

La même courte liste à chaque fois : absence de contrôles CRUD/FLS, SOQL dynamique bâtie sur des entrées, sorties non échappées, CSRF, références directes non sûres à des objets, et classes Apex qui n'ont jamais déclaré de partage. Presque tous sont détectables en auto-évaluation. L'autre récidiviste est procédural plutôt que technique, un rapport de scan obsolète ou non expliqué, ou une org de test où le relecteur ne peut pas se connecter, ce qui bloque le tour avant même la lecture du code.

Où Tekunda intervient

Les packages listés sont revus périodiquement, la boucle ne se referme donc jamais tout à fait. Tenir un journal de remédiation vivant, et relancer les scans à chaque release plutôt qu'à chaque soumission, rend le tour suivant formel. Si vous préférez confier la revue à des gens qui l'ont déjà passée, Tekunda construit et package des produits AppExchange en tant que PDO Salesforce.

FAQ

Combien de temps prend la revue de sécurité AppExchange ?

Salesforce indique qu'une solution met généralement 4 à 5 semaines à traverser la revue. Une resoumission repasse par la même file, prévoyez donc un deuxième tour dans le calendrier de release plutôt que de compter sur une voie rapide.

Combien coûte la revue de sécurité ?

Salesforce documente des frais de 999 $ pour chaque solution payante vendue sur la marketplace, pour la première soumission comme pour chaque tentative suivante. Une réussite nette du premier coup est le seul moyen de ne les payer qu'une fois.

Le scan Salesforce Code Analyzer est-il obligatoire ?

Oui, pour les packages managés listés sur AppExchange. Téléversez les résultats du Code Analyzer avec votre soumission, accompagnés d'un rapport de scan dynamique pour chaque endpoint externe appelé par votre package.

Qu'est-ce qui a remplacé Chimera pour le scan dynamique ?

Rien d'hébergé. Depuis le retrait de Chimera le 2025-06-16, les partenaires lancent leurs propres tests de sécurité dynamiques avec des outils comme OWASP ZAP, Burp Suite ou Qualys et soumettent le rapport.

Dois-je repasser la revue ?

Oui. Les packages listés font l'objet d'une nouvelle revue périodique, alors intégrez la remédiation et la documentation à votre processus de release plutôt que de traiter la sécurité comme un événement unique.