Revue de sécurité Salesforce : lancer vos propres scans dynamiques après Chimera

En bref : Salesforce a retiré son scanner dynamique hébergé Chimera le 2025-06-16, donc les partenaires lancent désormais leur propre scan dynamique (DAST) et soumettent les résultats avec leur revue de sécurité AppExchange. Pointez un outil accepté comme OWASP ZAP, Burp Suite ou Qualys vers une installation complète, gardez la preuve que vous avez scanné le bon endpoint, et documentez chaque constat trié. Ce guide couvre ce qui a changé, quels outils sont admis, comment produire un rapport prêt à soumettre, et les erreurs qui le renvoient.

Pendant des années, Salesforce a lancé le scan dynamique à votre place via Chimera. Ce service a disparu. L'analyse statique et la revue manuelle sont inchangées, mais le scan dynamique vous revient désormais, à lancer et à prouver. Ce guide porte sur ce seul changement. Pour les modes d'échec qui renvoient les soumissions et l'ordre pour les corriger, voir Checklist de la security review Salesforce : quoi corriger, et dans quel ordre.

Qu'est-ce qui a changé au retrait de Chimera ?

Chimera était le service hébergé de Salesforce qui testait dynamiquement les endpoints externes d'un partenaire pendant la revue. Depuis son retrait le 2025-06-16, les partenaires qui soumettent un managed package lancent eux-mêmes leur scan dynamique contre chaque service que le package appelle, et joignent le rapport à la soumission. Salesforce continue l'analyse statique et la revue manuelle ; seul le test dynamique est passé de votre côté.

Si votre package n'appelle que des API Salesforce et n'héberge rien d'externe, il y a peut-être peu à scanner. Dès que votre app dialogue avec un service que vous exploitez, ce service entre dans le périmètre et exige son propre rapport.

Quels outils de scan dynamique Salesforce accepte-t-il ?

Vous choisissez l'outil, tant qu'il produit un rapport DAST crédible. Ceux vers lesquels les partenaires se tournent le plus souvent sont :

• OWASP ZAP. Gratuit et open source, le point de départ habituel pour une première soumission.
• Burp Suite. L'édition professionnelle couvre la plupart des besoins des partenaires, avec un scanner actif plus solide que la version gratuite.
• Qualys WAS. Une option hébergée pour les équipes qui l'utilisent déjà ailleurs dans leur stack.
• D'autres outils DAST comme Veracode, Acunetix, Intruder ou JiT DAST sont tout aussi acceptables si votre équipe en possède déjà un.

Salesforce s'intéresse au rapport, pas à la marque dessus. Quoi que vous lanciez, il doit montrer qu'il a atteint et sollicité l'endpoint en production.

Comment lancer un scan et documenter les résultats ?

1. Déployez une installation complète du package dans une org de test avec des données réalistes, pour que le scanner sollicite de vrais workflows plutôt que des pages vides.
2. Authentifiez le scanner comme un vrai utilisateur, puis laissez-le crawler et scanner activement chaque endpoint externe que l'app appelle. Un scan non authentifié manque l'essentiel de la surface.
3. Capturez une capture d'écran ou un log prouvant que le scan a touché le bon endpoint. Salesforce demande la preuve que la bonne cible a été testée, pas seulement un résumé propre.
4. Triez chaque constat. Corrigez les vrais problèmes, et pour chaque faux positif écrivez une entrée : outil et identifiant de règle, l'endpoint, le chemin de la donnée, et le contrôle qui la protège.
5. Exportez le rapport complet plus votre document de faux positifs, et joignez les deux à la soumission avec vos rapports de scan statique.

Quels sont les pièges courants ?

• Scanner la mauvaise cible. Pointer l'outil vers une URL de staging que le package n'appelle jamais produit un rapport que Salesforce ne peut pas rattacher à votre app.
• Sauter l'authentification. Un scan non authentifié n'atteint jamais la surface connectée, donc le rapport paraît propre parce qu'il n'a presque rien testé.
• Soumettre la sortie brute. Une liste de constats sans tri se lit comme non revue. Chaque élément exige une correction ou une justification écrite.
• Le remettre à la semaine d'avant. Lancez le scan pendant le développement, pour que les constats apparaissent quand ils sont peu coûteux à corriger.

Où Tekunda intervient

Lancer et prouver un scan dynamique est exactement l'étape qui bloque un lancement quand une équipe la rencontre pour la première fois. Tekunda construit et package des produits AppExchange en tant que PDO Salesforce, scan dynamique et soumission compris.

FAQ

Ai-je encore besoin d'un scan dynamique après le retrait de Chimera ?

Oui, plus qu'avant. Chimera le lançait pour vous ; maintenant vous le lancez vous-même et soumettez le rapport avec votre package.

Quel outil utiliser ?

N'importe quel outil DAST crédible. OWASP ZAP est l'option gratuite par défaut ; Burp Suite, Qualys et Veracode sont des options payantes courantes. Salesforce juge le rapport, pas la marque.

Et si mon package n'a pas d'endpoints externes ?

Alors il n'y a peut-être rien à scanner dynamiquement. Dès que l'app appelle un service que vous exploitez, ce service entre dans le périmètre et exige son propre rapport.

Quand lancer le scan ?

Pendant le développement, pas la semaine avant de soumettre, pour que les constats apparaissent quand ils sont encore peu coûteux à corriger.