Salesforce Code Analyzer v5: je pipeline van sfdx-scanner af halen

Kort: Salesforce Code Analyzer v5 vervangt de sfdx-scanner-plugin. Installeer hem met sf plugins install code-analyzer, ruil sf scanner run in voor sf code-analyzer run, en vervang de oude --engine- en --category-vlaggen door een enkele --rule-selector. De Graph Engine valt onder hetzelfde commando, en het afstellen van engines verhuist van CLI-vlaggen naar een code-analyzer.yml.

Draait je CI nog sf scanner run, dan is dit de migratie die je inplant voor je volgende AppExchange-inzending, niet erna. De rest van de security review verandert niet, dus deze gids blijft bij de toolwissel. Voor wat reviewers echt afkeuren en in welke volgorde je het oplost, zie Salesforce Security Review Checklist: What to Fix, In Order.

Wat is er veranderd tussen sfdx-scanner en Code Analyzer v5?

Zelfde werk, nieuwe voordeur. Code Analyzer v5 is een sf-plugin die de engines voor statische analyse achter een commando en een resultaatformaat bundelt, in plaats van de engine-per-engine vlaggen van v4. Drie verschillen tellen bij de migratie:

• Een commando-oppervlak. sf code-analyzer run dekt de engines die eerder over sf scanner run en sf scanner run dfa verdeeld waren, dus de Graph Engine is geen aparte aanroep met eigen vlaggen meer.
• Selectors in plaats van engine- en categorievlaggen. Je vraagt regels op naam, tag, engine of severity op via --rule-selector, in plaats van --engine met --category te combineren.
• Configuratie in een bestand. Het afstellen van engines dat in CLI-vlaggen en per-engine configpaden zat, hoort nu in een code-analyzer.yml, die je commit naast de code die hij bewaakt.

Hoe installeer en draai je hem?

Installeer de plugin en draai hem tegen je workspace:

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

Genereer eenmalig een startconfiguratie en commit die, zodat elke ontwikkelaar en elke CI-job met dezelfde regels analyseert:

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

Vertrouw geen selector voordat je hebt opgesomd waar hij op uitkomt. Dit is de snelste manier om een migratie te betrappen die je dekking stilletjes versmalde:

sf code-analyzer rules --rule-selector Security

Hoe vertaal je je bestaande commando's?

Loop je pipelinedefinities en lokale scripts in een keer door:

• sf scanner run --target force-app wordt sf code-analyzer run --workspace force-app.
• --engine pmd --category Security wordt --rule-selector pmd:Security, of gewoon --rule-selector Security als je die tag over alle engines wilt.
• sf scanner run dfa wordt een selector op de Graph Engine binnen de normale run, in plaats van een eigen subcommando.
• --format plus --outfile worden --output-file, waarbij de extensie het formaat kiest. Gebruik --output-file results.sarif als je bevindingen naar de code-scanningweergave van je host uploadt.
• Configvlaggen per engine worden regels in code-analyzer.yml. Verhuis ze in plaats van ze als vlaggen na te bouwen.

Kopieer je onderdrukkingslijst niet met de hand over op regelnaam. Regel-identifiers zijn met de engines meeverhuisd, dus leid je uitzonderingen opnieuw af uit een verse sf code-analyzer rules-lijst en gooi weg wat niet meer oplost.

Hoe maak je er een CI-gate van?

Gebruik --severity-threshold. Het commando eindigt niet-nul zodra het een overtreding vindt op of boven het niveau dat je meegeeft, en dat maakt van de scan een gate in plaats van een rapport:

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

Zet de drempel waar je codebase vandaag staat, niet waar je hem wilt hebben, en trek hem aan zodra de achterstand weg is. Een gate die vanaf dag een elke pull request laat falen, staat binnen een week uit, en een uitgeschakelde gate vangt niets.

Wat verandert deze migratie niet?

Code Analyzer dekt de code in je package. De rest van het inzendingsbewijs blijft door de versiewissel onaangeroerd:

• De broncodescan via het Partner-portaal draai je nog steeds apart.
• Elk extern endpoint dat je package aanroept heeft nog steeds een eigen dynamisch scanrapport nodig. Zie Running Your Own Dynamic Scans After Chimera.
• Bevindingen die je als false positive beschouwt, hebben nog steeds per stuk een geschreven onderbouwing nodig. How to Document False Positives for the Salesforce Security Review behandelt het formaat.

Een pipeline migreren die je niet zelf hebt gebouwd, met een deadline? Tekunda bouwt en verpakt AppExchange-producten als Salesforce PDO, security review inbegrepen.

FAQ

Wordt sfdx-scanner nog ondersteund?

Beschouw hem als de vorige generatie. Code Analyzer v5 is de opvolger, en nieuwe regels en engine-updates landen daar, dus een pipeline op de oude plugin raakt stilletjes achterop qua dekking.

Veranderen mijn resultaten na de migratie?

Reken erop. Selectors komen uit op een andere regelset dan je oude engine- en categoriecombinatie, en severities zijn genormaliseerd over de engines heen. Draai beide versies een keer naast elkaar en vergelijk de bevindingen voordat je de oude job weggooit.

Waar zet ik engine-instellingen nu neer?

In code-analyzer.yml, gecommit in de repo. Genereer een startbestand met sf code-analyzer config en bewerk vanaf daar, in plaats van er zelf een te schrijven.

Kan ik hem draaien zonder de hele Salesforce CLI?

Het is een sf-plugin, dus de CLI is een vereiste. Installeer CLI en plugin in je build image en niet bij elke run, anders domineert de installatie de jobtijd.