Slaag in één keer voor de AppExchange security review

TL;DR: De Salesforce security review-checklist is de set controles die het Product Security-team van Salesforce verifieert voordat een managed package live gaat op AppExchange: afgedwongen CRUD/FLS en sharing, geen injectiefouten, versleutelde data, gedocumenteerde dataflows en schone scannerrapporten. Slaag in één keer door de vereiste scans te draaien, elke oplosbare overtreding te herstellen en de rest te documenteren. Hieronder staat de werkende checklist en de fouten die een herindiening veroorzaken.

Wat is de Salesforce security review?

De security review is een verplichte audit die Salesforce uitvoert op elke managed package voordat deze op AppExchange mag worden vermeld. Het combineert statische code-analyse, dynamische applicatietests en een handmatige controle door het Product Security-team van Salesforce. De indieningskosten bedragen $999 voor betaalde oplossingen (gratis listings betalen niets) en een oplossing doet er doorgaans 4-5 weken over om het proces te doorlopen. Scans hoeven niet 100% schoon te zijn; je draait ze, herstelt wat je kunt en licht de rest toe.

Wat staat er op de Salesforce security review-checklist?

Elk item hieronder komt overeen met iets dat een reviewer actief zal proberen te breken. Behandel het als een poort vóór indiening, niet als een verlanglijst.

1. Dwing CRUD en FLS af. Elke query en DML-actie moet de object- en veldrechten van de uitvoerende gebruiker respecteren. Gebruik WITH USER_MODE op SOQL en AccessLevel.USER_MODE op Database-aanroepen, plus Security.stripInaccessible() voor payloads die je zelf filtert. Handgeschreven isAccessible()/isUpdateable()-ketens laat je makkelijk incompleet.
2. Respecteer sharing. Declareer with sharing op Apex-klassen die records raken en verruim nooit de toegang om een sharing-regel te omzeilen.
3. Elimineer injectie. Gebruik bind-variabelen, geen string-concatenatie, in SOQL en SOSL. Escape alles wat dynamisch is.
4. Versleutel data. AES-256 voor data in rust, TLS 1.2 of hoger tijdens transport.
5. Bescherm secrets. Bewaar inloggegevens in Named Credentials of beschermde custom metadata, nooit hardcoded in Apex of een component.
6. Gebruik OAuth voor elke verbinding met een extern systeem in plaats van ruwe gebruikersnamen en wachtwoorden op te slaan.
7. Verhard de front-end. Stel security headers in en markeer cookies als Secure en HttpOnly.
8. Draai de scanners en documenteer false positives. Een false positive zonder uitleg leest als een onopgeloste kwetsbaarheid.
9. Documenteer alles. Architectuur, dataflow-diagrammen tussen je org en elke externe site, API-callouts en werkende testgegevens.

Welke scanners vereist Salesforce dat je draait?

Voor een managed package moet je rapporten van Salesforce Code Analyzer uploaden. Genereer ze met de AppExchange-ruleset:

sf code-analyzer run --rule-selector AppExchange --rule-selector Recommended:Security --output-file CodeAnalyzerReport.html

Salesforce voert daarnaast statische analyse uit met Checkmarx en dynamische tests met tools zoals OWASP ZAP of Burp Suite. (De oudere Chimera-scanner is uitgefaseerd.) Onthoud: de eis is dat je de scans hebt gedraaid en verholpen wat je kon, niet dat elke regel slaagt.

Waarom zakken apps voor de security review?

De meeste mislukkingen bij de eerste poging draaien om een korte lijst problemen:

• Ontbrekende CRUD- of FLS-controles op één object of veld.
• Apex die without sharing draait waar dat niet zou moeten.
• SOQL-injectie via dynamische queries.
• Gevoelige data die onversleuteld wordt opgeslagen of gelogd.
• Ongedocumenteerde false positives in de scannerrapporten.

Niets hiervan is exotisch. Ze glippen erdoor omdat ze laat werden opgemerkt, nadat de code was geschreven, in plaats van afgedwongen terwijl de package evolueerde.

Hoe versnelt de kwaliteit van je indiening de review?

Een mens beoordeelt je indiening en de kwaliteit van wat je aanlevert bepaalt hoe snel het slaagt. Alles vooraf aanleveren - volledige dataflow-diagrammen, een helder false-positive-logboek, responsieve contactpersonen en testgegevens die echt werken - haalt het heen-en-weer weg dat een review met extra weken verlengt. Hetzelfde instinct dat goede klantenservice maakt, anticiperen op de volgende vraag van de ander, is precies wat een security review verkort.

De teams die vlekkeloos slagen, behandelen de review als een doorlopende discipline: ze verankeren CRUD/FLS-handhaving en scannerruns in hun release-pijplijn, zodat de package elke sprint review-klaar is en niet in de week vóór indiening in elkaar wordt gezet. Dat is de DevOps-houding die we bij Tekunda met klanten opbouwen.

FAQ

Hoeveel kost de Salesforce security review?

De indieningskosten bedragen $999 per poging voor betaalde oplossingen, inclusief elke herindiening na een afwijzing. Gratis listings betalen de kosten niet.

Hoe lang duurt de security review?

Een oplossing doet er doorgaans 4-5 weken over, langer als deze terugkomt voor herstel.

Moeten mijn scannerrapporten 100% slagen?

Nee. Je moet de scans draaien, elke oplosbare overtreding herstellen, ze opnieuw draaien en resterende false positives documenteren.

Is de security review een eenmalige gebeurtenis?

Nee. Salesforce vereist periodiek een herbeoordeling en elke nieuwe functie die je uitbrengt moet aan dezelfde lat voldoen, dus de checklist is een doorlopende norm.