Tekunda Team

Tekunda Team

Hoe de Indieningslus van de AppExchange Security Review Werkt

Hoe de Indieningslus van de AppExchange Security Review Werkt

De AppExchange security review is een lus, geen poort. Je beoordeelt jezelf, dient in, krijgt een bevindingenrapport terug, herstelt en dient opnieuw in tot Salesforce akkoord gaat. Weten wat elke ronde kost, en welke bevindingen er een afdwingen, maakt het verschil tussen meerdere cycli en één keer goed.

Tekunda brengt managed packages als Salesforce PDO door de AppExchange security review. Dit is de lus zoals wij die draaien.

Wat gebeurt er nadat je hebt ingediend?

Je indiening komt in een wachtrij en wordt daarna vanuit drie invalshoeken bekeken: statische code-analyse met de Salesforce Code Analyzer, dynamische tests tegen een draaiende org en een handmatige beoordeling door het product security team van Salesforce. Wat terugkomt is een bevindingenrapport, geen oordeel, en elke regel wordt opgelost of schriftelijk verklaard. Salesforce geeft aan dat een oplossing doorgaans 4 tot 5 weken door de review doet, en dat er voor elke betaalde oplossing op de marketplace een tarief van $999 geldt voor de eerste indiening en voor elke volgende poging. Daardoor is een extra ronde duur: weer een factuur, en weer dezelfde wachtrij.

Wat los je op voor de eerste ronde?

Alles wat een scanner zelf kan vinden. Toegangscontrole afgedwongen in user mode, sharing gedeclareerd op elke Apex-klasse, bind-variabelen in plaats van samengestelde SOQL, ge-escapete uitvoer, en geheimen in Named Credentials of protected custom metadata in plaats van in code. De volledige lijst, in de volgorde die het minst kost, staat in Salesforce Security Review Checklist: What to Fix, In Order. Een bevinding die je zelf had kunnen vangen is de duurste soort, want die koopt een hele extra ronde.

Hoe draai je de lus, stap voor stap?

  1. Beoordeel jezelf. Draai de Code Analyzer en je eigen dynamische scan, triage elke bevinding en los de echte op. Salesforce heeft de gehoste Chimera-scanner op 2025-06-16 uitgefaseerd, dus die dynamische scan draai je nu zelf. Zie Running Your Own Dynamic Scans After Chimera voor de geaccepteerde tools en het rapport dat je meestuurt.
  2. Documenteer wat overblijft. Elke bevinding die je niet oplost heeft een eigen schriftelijke onderbouwing nodig: scanner en regel, bestand en regelnummer, het datapad en de control die het beschermt. How to Document False Positives for the Salesforce Security Review beschrijft het formaat dat reviewers accepteren.
  3. Stel je indiening samen. Werk de Security Review Requirements Checklist in de Partner Community door: scanrapporten, het false-positivedocument, gebruiks- en datastroomdocumentatie, credentials voor elk extern systeem, en een Developer Edition org met gevulde data die een reviewer echt kan gebruiken.
  4. Dien in en laat de versie met rust. De wachtrij is geen plek om door te itereren. Bevries de packageversie die je hebt ingediend en ontwikkel verder op een branch, zodat de reviewer en je team nooit naar andere code kijken.
  5. Herstel op basis van het rapport. Behandel het als een to-dolijst en los elk punt bij de wortel op in plaats van bij het symptoom dat de scanner meldde, want de volgende scan draait weer over het hele package.
  6. Dien opnieuw in met bewijs. Beantwoord elke bevinding expliciet, ook die waar je het niet mee eens was, en vermeld waar de fix zit. Onbeantwoorde punten maken van een tweede ronde een derde.

Wat stuurt een package een tweede keer de lus in?

Elke keer hetzelfde korte lijstje: ontbrekende CRUD/FLS-checks, dynamische SOQL gebouwd uit invoer, niet-ge-escapete uitvoer, cross-site request forgery, onveilige directe objectreferenties en Apex-klassen die nooit sharing declareerden. Bijna allemaal te vangen in de zelfbeoordeling. De andere terugkerende oorzaak is procesmatig in plaats van technisch, een verouderd of onverklaard scanrapport of een testorg waarop de reviewer niet kan inloggen, wat de ronde stilzet voordat de code überhaupt gelezen is.

Waar Tekunda past

Vermelde packages worden periodiek herbeoordeeld, dus de lus sluit nooit helemaal. Een levend remediatielogboek bijhouden, en de scans bij elke release draaien in plaats van bij elke indiening, maakt de volgende ronde een formaliteit. Wil je liever dat de review wordt gedaan door mensen die hem eerder hebben gehaald, dan bouwt en packaget Tekunda AppExchange-producten als Salesforce PDO.

FAQ

Hoe lang duurt de AppExchange security review?

Salesforce geeft aan dat een oplossing doorgaans 4 tot 5 weken door de review doet. Een herindiening komt opnieuw in dezelfde wachtrij, dus plan een tweede ronde in je releaseschema in plaats van op een sneller traject te rekenen.

Hoeveel kost de security review?

Salesforce documenteert een tarief van $999 voor elke betaalde oplossing op de marketplace, voor de eerste indiening en voor elke volgende poging. Een schone eerste keer is de enige manier om het één keer te betalen.

Is de Salesforce Code Analyzer-scan verplicht?

Ja, voor managed packages die op de AppExchange verschijnen. Upload de Code Analyzer-resultaten bij je indiening, samen met een dynamisch scanrapport voor elk extern endpoint dat je package aanroept.

Wat verving Chimera voor dynamisch scannen?

Niets gehosts. Sinds Chimera op 2025-06-16 is uitgefaseerd, draaien partners hun eigen dynamische beveiligingstests met tools als OWASP ZAP, Burp Suite of Qualys en dienen ze het rapport in.

Moet ik de review herhalen?

Ja. Vermelde packages zijn onderworpen aan periodieke herbeoordeling, dus bouw remediatie en documentatie in je releaseproces in in plaats van beveiliging als eenmalig te behandelen.

Gerelateerde artikelen