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

En bref : Salesforce a retire son scanner dynamique heberge Chimera le 2025-06-16, donc les partenaires lancent desormais leur propre scan dynamique (DAST) et soumettent les resultats avec leur revue de securite AppExchange. Pointez un outil accepte comme OWASP ZAP, Burp Suite ou Qualys vers une installation complete, gardez la preuve que vous avez scanne le bon endpoint, et documentez chaque constat trie. Ce guide couvre ce qui a change, quels outils sont admis, comment produire un rapport pret a soumettre, et les erreurs qui le renvoient.

Pendant des annees, Salesforce a lance le scan dynamique a votre place via Chimera. Ce service a disparu. L'analyse statique et la revue manuelle sont inchangees, mais le scan dynamique vous revient desormais, a lancer et a prouver. Ce guide porte sur ce seul changement. Pour les modes d'echec 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 change au retrait de Chimera ?

Chimera etait le service heberge 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-memes leur scan dynamique contre chaque service que le package appelle, et joignent le rapport a la soumission. Salesforce continue l'analyse statique et la revue manuelle ; seul le test dynamique est passe de votre cote.

Si votre package n'appelle que des API Salesforce et n'heberge rien d'externe, il y a peut-etre peu a scanner. Des que votre app dialogue avec un service que vous exploitez, ce service entre dans le perimetre 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 credible. Ceux vers lesquels les partenaires se tournent le plus souvent sont :

• OWASP ZAP. Gratuit et open source, le point de depart habituel pour une premiere soumission.
• Burp Suite. L'edition professionnelle couvre la plupart des besoins des partenaires, avec un scanner actif plus solide que la version gratuite.
• Qualys WAS. Une option hebergee pour les equipes qui l'utilisent deja ailleurs dans leur stack.
• D'autres outils DAST comme Veracode, Acunetix, Intruder ou JiT DAST sont tout aussi acceptables si votre equipe en possede deja un.

Salesforce s'interesse au rapport, pas a la marque dessus. Quoi que vous lanciez, il doit montrer qu'il a atteint et sollicite l'endpoint en production.

Comment lancer un scan et documenter les resultats ?

1. Deployez une installation complete du package dans une org de test avec des donnees realistes, pour que le scanner sollicite de vrais workflows plutot 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 authentifie manque l'essentiel de la surface.
3. Capturez une capture d'ecran ou un log prouvant que le scan a touche le bon endpoint. Salesforce demande la preuve que la bonne cible a ete testee, pas seulement un resume propre.
4. Triez chaque constat. Corrigez les vrais problemes, et pour chaque faux positif ecrivez une entree : outil et identifiant de regle, l'endpoint, le chemin de la donnee, et le controle qui la protege.
5. Exportez le rapport complet plus votre document de faux positifs, et joignez les deux a la soumission avec vos rapports de scan statique.

Quels sont les pieges 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 a votre app.
• Sauter l'authentification. Un scan non authentifie n'atteint jamais la surface connectee, donc le rapport parait propre parce qu'il n'a presque rien teste.
• Soumettre la sortie brute. Une liste de constats sans tri se lit comme non revue. Chaque element exige une correction ou une justification ecrite.
• Le remettre a la semaine d'avant. Lancez le scan pendant le developpement, pour que les constats apparaissent quand ils sont peu couteux a corriger.

Ou Tekunda intervient

Lancer et prouver un scan dynamique est exactement l'etape qui bloque un lancement quand une equipe la rencontre pour la premiere 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 apres le retrait de Chimera ?

Oui, plus qu'avant. Chimera le lancait pour vous ; maintenant vous le lancez vous-meme et soumettez le rapport avec votre package.

Quel outil utiliser ?

N'importe quel outil DAST credible. OWASP ZAP est l'option gratuite par defaut ; 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-etre rien a scanner dynamiquement. Des que l'app appelle un service que vous exploitez, ce service entre dans le perimetre et exige son propre rapport.

Quand lancer le scan ?

Pendant le developpement, pas la semaine avant de soumettre, pour que les constats apparaissent quand ils sont encore peu couteux a corriger.