Salesforce Code Analyzer v5: die Pipeline von sfdx-scanner loesen

Kurz gefasst: Salesforce Code Analyzer v5 löst das sfdx-scanner-Plugin ab. Installieren Sie ihn mit sf plugins install code-analyzer, tauschen Sie sf scanner run gegen sf code-analyzer run, und ersetzen Sie die alten Schalter --engine und --category durch ein einziges --rule-selector. Die Graph Engine zieht unter dasselbe Kommando, und die Feinjustierung der Engines wandert von CLI-Schaltern in eine code-analyzer.yml.

Ruft Ihre CI noch sf scanner run auf, dann planen Sie diese Migration vor der nächsten AppExchange-Einreichung ein, nicht danach. Der Rest der Security Review ändert sich nicht, dieser Leitfaden bleibt also beim Werkzeugwechsel. Was Reviewer wirklich ablehnen und in welcher Reihenfolge Sie es beheben, steht in Salesforce Security Review Checklist: What to Fix, In Order.

Was hat sich zwischen sfdx-scanner und Code Analyzer v5 geändert?

Gleiche Aufgabe, neue Eingangstür. Code Analyzer v5 ist ein sf-Plugin, das die Engines der statischen Analyse hinter einem Kommando und einem Ergebnisformat bündelt, statt der Engine-für-Engine-Schalter aus v4. Bei der Migration zählen drei Unterschiede:

• Eine Kommandooberfläche. sf code-analyzer run deckt die Engines ab, die früher zwischen sf scanner run und sf scanner run dfa aufgeteilt waren, die Graph Engine ist also kein eigener Aufruf mit eigenen Schaltern mehr.
• Selektoren statt Engine- und Kategorieschaltern. Sie fragen Regeln nach Name, Tag, Engine oder Schweregrad über --rule-selector ab, statt --engine mit --category zu kombinieren.
• Konfiguration in einer Datei. Die Feinjustierung, die in CLI-Schaltern und Config-Pfaden je Engine lag, gehört jetzt in eine code-analyzer.yml, die Sie neben dem Code committen, den sie regelt.

Wie installiert und startet man ihn?

Plugin installieren, dann gegen Ihren Workspace laufen lassen:

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

Erzeugen Sie einmal eine Startkonfiguration und committen Sie sie, damit alle Entwicklerinnen und Entwickler und jeder CI-Job mit denselben Regeln analysieren:

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

Vertrauen Sie einem Selektor erst, wenn Sie aufgelistet haben, worauf er hinausläuft. Das ist der schnellste Weg, eine Migration zu erwischen, die Ihre Abdeckung still verengt hat:

sf code-analyzer rules --rule-selector Security

Wie übersetzen Sie Ihre bestehenden Kommandos?

Gehen Sie Pipeline-Definitionen und lokale Skripte in einem Durchgang durch:

• Aus sf scanner run --target force-app wird sf code-analyzer run --workspace force-app.
• Aus --engine pmd --category Security wird --rule-selector pmd:Security, oder schlicht --rule-selector Security, wenn Sie dieses Tag über alle Engines hinweg wollen.
• Aus sf scanner run dfa wird ein Selektor auf die Graph Engine innerhalb des normalen Laufs statt ein eigenes Unterkommando.
• Aus --format plus --outfile wird --output-file, wobei die Dateiendung das Format bestimmt. Nutzen Sie --output-file results.sarif, wenn Sie Findings in die Code-Scanning-Ansicht Ihres Hosters hochladen.
• Config-Schalter je Engine werden zu Einträgen in code-analyzer.yml. Verschieben Sie sie, statt sie als Schalter nachzubauen.

Übernehmen Sie eine Unterdrückungsliste nicht per Hand über Regelnamen. Die Regel-Identifikatoren sind mit den Engines umgezogen, leiten Sie Ihre Ausnahmen also aus einem frischen sf code-analyzer rules-Listing neu ab und löschen Sie, was nicht mehr auflöst.

Wie macht man daraus ein CI-Gate?

Über --severity-threshold. Das Kommando endet ungleich null, sobald es einen Verstoß auf oder über dem übergebenen Niveau findet, und genau das macht aus dem Scan ein Gate statt eines Berichts:

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

Setzen Sie die Schwelle dort, wo Ihre Codebasis heute steht, nicht dort, wo Sie sie haben wollen, und ziehen Sie sie an, sobald der Rückstand abgebaut ist. Ein Gate, das ab Tag eins jeden Pull Request scheitern lässt, ist binnen einer Woche abgeschaltet, und ein abgeschaltetes Gate fängt gar nichts.

Was diese Migration nicht ändert

Code Analyzer deckt den Code in Ihrem Package ab. Der Rest der Einreichungsnachweise bleibt vom Versionswechsel unberührt:

• Den Quellcode-Scan über das Partner-Portal fahren Sie weiterhin separat.
• Jeder externe Endpunkt, den Ihr Package aufruft, braucht weiterhin einen eigenen dynamischen Scanbericht. Siehe Running Your Own Dynamic Scans After Chimera.
• Findings, die Sie für False Positives halten, brauchen weiterhin je eine schriftliche Begründung. How to Document False Positives for the Salesforce Security Review beschreibt das Format.

Sie migrieren unter Termindruck eine Pipeline, die Sie nicht gebaut haben? Tekunda baut und paketiert AppExchange-Produkte als Salesforce PDO, Security Review inklusive.

FAQ

Wird sfdx-scanner noch unterstützt?

Behandeln Sie ihn als Vorgängergeneration. Code Analyzer v5 ist der Nachfolger, und dort landen neue Regeln und Engine-Updates. Eine Pipeline, die auf dem alten Plugin bleibt, fällt still bei der Abdeckung zurück.

Ändern sich meine Ergebnisse nach der Migration?

Rechnen Sie damit. Selektoren lösen ein anderes Regelset auf als Ihre alte Kombination aus Engine und Kategorie, und Schweregrade sind über die Engines hinweg normalisiert. Lassen Sie beide Versionen einmal nebeneinander laufen und vergleichen Sie die Findings, bevor Sie den alten Job löschen.

Wohin gehören Engine-Einstellungen jetzt?

In die code-analyzer.yml im Repository. Erzeugen Sie eine Startdatei mit sf code-analyzer config und bearbeiten Sie sie von dort, statt eine von Grund auf zu schreiben.

Kann ich ihn ohne die komplette Salesforce CLI betreiben?

Es ist ein sf-Plugin, die CLI ist also Voraussetzung. Installieren Sie CLI und Plugin in Ihrem Build-Image statt bei jedem Lauf, sonst dominiert die Installation die Job-Laufzeit.