Salesforce Code Analyzer v5 : migrer votre pipeline depuis sfdx-scanner

En bref : Salesforce Code Analyzer v5 remplace le plugin sfdx-scanner. Installez-le avec sf plugins install code-analyzer, échangez sf scanner run contre sf code-analyzer run, et remplacez les anciens indicateurs --engine et --category par un unique --rule-selector. Le Graph Engine passe sous la même commande, et le réglage des moteurs quitte les options CLI pour un code-analyzer.yml.

Si votre CI appelle encore sf scanner run, planifiez cette migration avant votre prochaine soumission AppExchange, pas après. Le reste de la security review ne change pas, ce guide s'en tient donc au changement d'outil. Pour ce que les reviewers rejettent vraiment et dans quel ordre le corriger, voyez Salesforce Security Review Checklist: What to Fix, In Order.

Qu'est-ce qui change entre sfdx-scanner et Code Analyzer v5 ?

Même travail, nouvelle porte d'entrée. Code Analyzer v5 est un plugin sf qui réunit les moteurs d'analyse statique derrière une commande et un format de résultat, au lieu des options moteur par moteur exposées par la v4. Trois différences comptent au moment de migrer :

• Une seule surface de commande. sf code-analyzer run couvre les moteurs auparavant répartis entre sf scanner run et sf scanner run dfa : le Graph Engine n'est plus une invocation séparée avec ses propres options.
• Des sélecteurs plutôt que des options moteur et catégorie. Vous demandez les règles par nom, tag, moteur ou sévérité via --rule-selector au lieu de combiner --engine et --category.
• La configuration dans un fichier. Le réglage des moteurs, jusque-là dans des options CLI et des chemins de config par moteur, appartient désormais à un code-analyzer.yml que vous commitez à côté du code qu'il gouverne.

Comment l'installer et l'exécuter ?

Installez le plugin, puis lancez-le sur votre workspace :

sf plugins install code-analyzer
sf code-analyzer run --workspace . --view detail

Générez une configuration de départ une fois et commitez-la, pour que chaque développeur et chaque job CI analysent avec les mêmes règles :

sf code-analyzer config --output-file code-analyzer.yml

Avant de faire confiance à un sélecteur, listez ce qu'il résout. C'est le moyen le plus rapide d'attraper une migration qui a discrètement réduit votre couverture :

sf code-analyzer rules --rule-selector Security

Comment traduire vos commandes existantes ?

Passez vos définitions de pipeline et vos scripts locaux en une seule fois :

• sf scanner run --target force-app devient sf code-analyzer run --workspace force-app.
• --engine pmd --category Security devient --rule-selector pmd:Security, ou simplement --rule-selector Security si vous voulez ce tag sur tous les moteurs.
• sf scanner run dfa devient un sélecteur sur le Graph Engine à l'intérieur du run normal, au lieu d'une sous-commande à part.
• --format et --outfile deviennent --output-file, où l'extension choisit le format. Utilisez --output-file results.sarif si vous remontez les résultats dans la vue de code scanning de votre hébergeur.
• Les options de config par moteur deviennent des entrées de code-analyzer.yml. Déplacez-les au lieu de les reproduire en options.

Ne migrez pas une liste de suppressions en recopiant les noms de règles à la main. Les identifiants de règles ont suivi les moteurs : redérivez vos exclusions depuis un listing sf code-analyzer rules frais et supprimez celles qui ne résolvent plus.

Comment en faire une barrière en CI ?

Utilisez --severity-threshold. La commande sort en erreur dès qu'elle trouve une violation au niveau que vous passez ou au-dessus, et c'est ce qui transforme le scan en barrière plutôt qu'en rapport :

sf code-analyzer run --workspace . \
  --rule-selector Security \
  --severity-threshold 3 \
  --output-file results.sarif

Placez le seuil là où se trouve votre base de code aujourd'hui, pas là où vous la voulez, puis resserrez une fois l'arriéré résorbé. Une barrière qui fait échouer chaque pull request dès le premier jour est désactivée en une semaine, et une barrière désactivée n'attrape rien.

Ce que cette migration ne change pas

Code Analyzer couvre le code contenu dans votre package. Le reste des preuves de soumission n'est pas touché par le changement de version :

• Le scan de code source via le portail Partner reste une étape distincte.
• Tout endpoint externe appelé par votre package a toujours besoin de son propre rapport de scan dynamique. Voyez Running Your Own Dynamic Scans After Chimera.
• Les résultats que vous considérez comme des faux positifs demandent toujours une justification écrite, un par un. How to Document False Positives for the Salesforce Security Review en détaille le format.

Vous migrez, sous contrainte de délai, un pipeline que vous n'avez pas construit ? Tekunda construit et package des produits AppExchange en tant que PDO Salesforce, security review comprise.

FAQ

sfdx-scanner est-il encore supporté ?

Traitez-le comme la génération précédente. Code Analyzer v5 est le successeur, et c'est là qu'arrivent les nouvelles règles et les mises à jour des moteurs : un pipeline resté sur l'ancien plugin perd discrètement en couverture.

Mes résultats vont-ils changer après la migration ?

Attendez-vous à ce que oui. Les sélecteurs résolvent un jeu de règles différent de votre ancienne combinaison moteur plus catégorie, et les sévérités sont normalisées entre moteurs. Lancez les deux versions une fois, côte à côte, et comparez les résultats avant de supprimer l'ancien job.

Où mettre les réglages des moteurs maintenant ?

Dans code-analyzer.yml, commité dans le dépôt. Générez un fichier de départ avec sf code-analyzer config et éditez à partir de là plutôt que d'en écrire un de zéro.

Puis-je l'exécuter sans toute la CLI Salesforce ?

C'est un plugin sf, la CLI est donc un prérequis. Installez la CLI et le plugin dans votre image de build plutôt qu'à chaque exécution, sinon l'installation domine le temps du job.