Réussir la security review AppExchange du premier coup

TL;DR : La checklist de la security review Salesforce est l'ensemble des contrôles que l'équipe Product Security de Salesforce vérifie avant qu'un managed package ne soit publié sur AppExchange : CRUD/FLS et partage appliqués, aucune faille d'injection, données chiffrées, flux de données documentés et rapports de scan propres. Réussissez du premier coup en lançant les scans requis, en corrigeant chaque violation possible et en documentant le reste. Voici la checklist opérationnelle et les erreurs qui déclenchent une nouvelle soumission.

Qu'est-ce que la security review Salesforce ?

La security review est un audit obligatoire que Salesforce effectue sur chaque managed package avant sa publication sur AppExchange. Elle combine l'analyse statique du code, des tests d'application dynamiques et une revue manuelle par l'équipe Product Security de Salesforce. Les frais de soumission s'élèvent à 999 $ pour les solutions payantes (les listings gratuits ne paient rien), et une solution met généralement 4 à 5 semaines pour franchir le processus. Les scans n'ont pas besoin d'être parfaitement propres : vous les lancez, corrigez ce que vous pouvez et expliquez le reste.

Que contient la checklist de la security review Salesforce ?

Chaque élément ci-dessous correspond à quelque chose qu'un examinateur tentera activement de casser. Traitez-le comme un point de contrôle avant soumission, pas comme une liste de souhaits.

1. Appliquez CRUD et FLS. Chaque requête et chaque opération DML doit respecter les permissions d'objet et de champ de l'utilisateur courant. Utilisez WITH USER_MODE sur SOQL et AccessLevel.USER_MODE sur les appels Database, ainsi que Security.stripInaccessible() pour les payloads que vous filtrez vous-même. Les chaînes isAccessible()/isUpdateable() écrites à la main sont faciles à laisser incomplètes.
2. Respectez le partage. Déclarez with sharing sur les classes Apex qui touchent aux enregistrements et n'élargissez jamais l'accès pour contourner une règle de partage.
3. Éliminez l'injection. Utilisez des variables de liaison, pas la concaténation de chaînes, dans SOQL et SOSL. Échappez tout ce qui est dynamique.
4. Chiffrez les données. AES-256 pour les données au repos, TLS 1.2 ou supérieur en transit.
5. Protégez les secrets. Stockez les identifiants dans des Named Credentials ou des custom metadata protégées, jamais en dur dans l'Apex ou un composant.
6. Utilisez OAuth pour chaque connexion à un système externe au lieu de stocker des noms d'utilisateur et mots de passe bruts.
7. Renforcez le front-end. Définissez des en-têtes de sécurité et marquez les cookies Secure et HttpOnly.
8. Lancez les scanners et documentez les faux positifs. Un faux positif sans explication se lit comme une vulnérabilité non traitée.
9. Documentez tout. Architecture, diagrammes de flux de données entre votre org et tout site externe, appels d'API et identifiants de test fonctionnels.

Quels scanners Salesforce exige-t-il que vous lanciez ?

Pour un managed package, vous devez téléverser les rapports de Salesforce Code Analyzer. Générez-les avec le jeu de règles AppExchange :

sf code-analyzer run --rule-selector AppExchange --rule-selector Recommended:Security --output-file CodeAnalyzerReport.html

Salesforce effectue également une analyse statique avec Checkmarx et des tests dynamiques avec des outils comme OWASP ZAP ou Burp Suite. (L'ancien scanner Chimera a été retiré.) Rappelez-vous : l'exigence est que vous ayez lancé les scans et corrigé ce que vous pouviez, pas que chaque règle passe.

Pourquoi les applications échouent-elles à la security review ?

La plupart des échecs au premier essai tournent autour d'une courte liste de problèmes :

• Contrôles CRUD ou FLS manquants sur un seul objet ou champ.
• De l'Apex qui s'exécute without sharing là où il ne le devrait pas.
• Injection SOQL via des requêtes dynamiques.
• Données sensibles stockées ou journalisées en clair.
• Faux positifs non documentés dans les rapports de scan.

Rien de tout cela n'est exotique. Ces failles passent parce qu'elles ont été détectées tard, après l'écriture du code, plutôt qu'appliquées au fur et à mesure de l'évolution du package.

Comment la qualité de votre soumission accélère-t-elle la revue ?

Un humain examine votre soumission, et la qualité de ce que vous lui remettez détermine la rapidité de la validation. Tout fournir d'avance - diagrammes de flux de données complets, journal clair des faux positifs, contacts réactifs et identifiants de test qui fonctionnent vraiment - supprime les allers-retours qui rallongent une revue de plusieurs semaines. Le même instinct qui fait un bon service client, anticiper la prochaine question de l'autre, est exactement ce qui raccourcit une security review.

Les équipes qui réussissent sans accroc traitent la revue comme une discipline continue : elles intègrent l'application de CRUD/FLS et les scans dans leur pipeline de livraison, afin que le package soit prêt pour la revue à chaque sprint, et non bricolé la semaine précédant la soumission. C'est la posture DevOps que nous construisons avec nos clients chez Tekunda.

FAQ

Combien coûte la security review Salesforce ?

Les frais de soumission sont de 999 $ par tentative pour les solutions payantes, y compris chaque nouvelle soumission après un échec. Les listings gratuits ne sont pas facturés.

Combien de temps dure la security review ?

Une solution met généralement 4 à 5 semaines à franchir la revue, davantage si elle revient pour correction.

Mes rapports de scan doivent-ils passer à 100 % ?

Non. Vous devez lancer les scans, corriger chaque violation possible, les relancer et documenter les faux positifs restants.

La security review est-elle un événement unique ?

Non. Salesforce exige périodiquement une nouvelle revue, et chaque nouvelle fonctionnalité que vous livrez doit respecter le même niveau, donc la checklist est une norme permanente.