Salesforce security review checklist: wat je oplost, en in welke volgorde

Een Salesforce security review checklist heeft alleen waarde als hij een volgorde heeft. De meeste inzendingen sneuvelen op een korte, voorspelbare lijst, en toegangscontrole staat bovenaan. Werk in deze volgorde: dwing toegang af in user mode, triageer de drie scannerrapporten, en stel dan het inzendmateriaal en een testomgeving samen die de reviewer echt kan gebruiken. Salesforce houdt 4 tot 5 weken aan voor een review, dus een afwijzing kost je een release-cyclus en niet een middag.

Tekunda heeft managed packages door de review geloodst in de zorg, logistiek en maakindustrie. Wat hieronder staat is de volgorde waarin wij werken, geen beschrijving van het proces. Voor het volledige inzendtraject, zie How ISVs Pass the Salesforce AppExchange Security Review.

De checklist in het kort

1. Bevestig wat je inzendt: een managed package, plus elke externe dienst die het raakt.
2. Los toegangscontrole op: user mode, expliciete sharing, geen injecteerbare SOQL.
3. Los outputafhandeling, secrets, transportbeveiliging en authenticatie op.
4. Draai Code Analyzer, de source scan van het Partner Security Portal en een DAST-scan.
5. Los op wat de lat van elke scanner vereist en documenteer elke false positive.
6. Stel documentatie, inloggegevens en een werkende test-org samen.
7. Dien in via de Partner Console en plan de jaarlijkse herbeoordeling in.

Wat er in 2026 veranderde

Drie dingen zijn dit jaar verschoven, en oudere checklists kennen ze alle drie niet.

• De marketplace heet nu AgentExchange. Salesforce hernoemde AppExchange naar AgentExchange op TrailblazerDX 2026 en bracht de Slack Marketplace erin onder. Het Trailhead-materiaal van Salesforce gebruikt nu de nieuwe naam, maar de security review blijft de poort naar een listing.
• Apex API-versie 67.0 verandert de beveiligingsdefaults. Volgens de Summer '26 architect highlights van Salesforce draaien databasebewerkingen nu standaard in user mode, krijgen klassen zonder sharing-declaratie standaard with sharing, en is WITH SECURITY_ENFORCED verwijderd, dus een klasse die het op v67.0 nog gebruikt compileert niet. Triggers vormen de uitzondering: die draaien altijd in system mode.
• Je draait de dynamische scan zelf. De voorbereidingsrichtlijn van Salesforce raadt nu OWASP ZAP of Burp Suite Enterprise Edition aan voor externe endpoints en accepteert je favoriete DAST-scanner. Zie Je eigen dynamische scans draaien na Chimera voor de tools en het rapport dat je inzendt.

Stap 1: Bepaal wat binnen de scope valt

Salesforce is er duidelijk over dat alle onderdelen en diensten van je oplossing, waar ze ook draaien, meetellen. Dat zijn het package, elke webservice die het aanroept, elke site waar Salesforce-data wordt opgeslagen en elke mobiele of desktopclient. Leg je pakkettype vast voordat je code gaat repareren, want het bepaalt wat je uploadt. Het artikel Salesforce Packaging Models for ISVs: 1GP vs 2GP vs Unmanaged behandelt die keuze.

Stap 2: Los de bevindingen op die inzendingen laten afwijzen, op volgorde

Werk van boven naar beneden. De bovenste punten zijn tegelijk de meest voorkomende bevindingen en het duurst om achteraf in te bouwen, en juist daarom schuift een inzending een cyclus op als je ze tot het laatst bewaart.

1. Toegangscontrole die niet in user mode wordt afgedwongen. Elke query en elke DML-actie moet de objectrechten, veldbeveiliging en sharing van de ingelogde gebruiker respecteren. Vertrouw niet alleen op de v67.0-default: een package bevat meestal klassen op oudere API-versies, en triggerhandlers kunnen vanuit een trigger in system mode worden aangeroepen. Zet de toegangsmodus expliciet met WITH USER_MODE bij SOQL en AccessLevel.USER_MODE bij Database-aanroepen, en vervang resterende WITH SECURITY_ENFORCED voordat je de API-versie ophoogt.
2. Sharing op de verkeerde klassen gezet. Onder v67.0 erft een klasse zonder sharing-keyword de sharing van de aanroeper, dus een helper die vanuit een @AuraEnabled-methode wordt aangeroepen kan er ongemerkt zonder draaien. Zet with sharing, without sharing of inherited sharing expliciet op elke klasse, ook op inner classes en utility classes, zodat de reviewer nooit hoeft uit te zoeken welke default geldt.
3. Dynamische SOQL die uit invoer wordt opgebouwd. Gebruik bind variables. Moet een query echt als string worden gebouwd, escape dan elke ingevoegde waarde en houd dat escapen zichtbaar in dezelfde methode, want daar leest een reviewer het.
4. Output zonder escaping. Alles wat via escape="false", lwc:dom="manual" of innerHTML op de pagina komt, moet daarvoor al gesaneerd zijn, niet erna.
5. Secrets en klantdata op de verkeerde plek. Hardcoded sleutels in Apex, tokens in onbeveiligde custom settings, een record met persoonsgegevens dat via System.debug gaat. Named Credentials en protected custom metadata zijn wat reviewers in plaats daarvan verwachten.
6. Zwakke versleuteling van transport of opslag. De lijst met de meest voorkomende review-bevindingen van Salesforce eist TLS 1.2 op verbindingen met je sites en portals, en het team scant elk extern endpoint daarop. Versleutel ook alles wat je buiten het platform opslaat.
7. Externe systemen met een opgeslagen gebruikersnaam en wachtwoord. Gebruik OAuth voor elke verbinding die je package opzet met een dienst die jij of de klant draait. Opgeslagen inloggegevens zijn op zichzelf al een bevinding, en ze maken het datastroomdocument lastiger te verdedigen.
8. Een composite site zonder de basis. Levert je oplossing een webomgeving buiten de org, dan heeft die security headers nodig en moeten de cookies Secure en HttpOnly zijn. Reviewers kijken naar de site die je aanlevert, niet naar de site die je beschrijft.
9. Externe endpoints die niemand gescand heeft. Roept je package een dienst aan die jij zelf draait, dan valt die dienst binnen de scope en heeft die een eigen dynamisch scanrapport nodig.
10. Een testomgeving die de reviewer niet kan gebruiken. Een verlopen org, een identity challenge die hem buitensluit, of objecten zonder data. Salesforce zegt dat partners het reviewteam moeten behandelen als een potentiele klant die de hele oplossing end to end uitprobeert, en wat niet draait kan niet beoordeeld worden.

Stap 3: Draai de scanners en haal de lat van elke scanner

Je moet een Salesforce Code Analyzer-rapport, een rapport van de source scanner in het Partner Security Portal en een DAST-rapport meesturen. De lat ligt niet op nul bevindingen, en hij ligt per scanner anders:

• Salesforce Code Analyzer: los alle security-gerelateerde bevindingen en fouten op behalve false positives, en negeer bevindingen die niet over security gaan. Hij scant geen externe endpoints.
• Source scanner van het Partner Security Portal (Checkmarx): los Low, Medium en High op en laat informational warnings staan.
• DAST-scanners zoals ZAP, Burp Suite, Veracode Dynamic Analysis, Intruder en Acunetix: los alles op behalve informational items en warnings, en voeg een screenshot toe dat bewijst dat het juiste externe endpoint is gescand.

Genereer het Code Analyzer v5-rapport met de AppExchange-regelselectie, zodat het aansluit op wat de reviewer verwacht. Bij een complexe codebase kan de run uren duren:

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

Welke scans verplicht zijn is meer dan eens veranderd, dus controleer de huidige scannervereisten voordat je iets genereert.

Stap 4: Documenteer elke false positive

In onze inzendingen komen vier categorieen vaak genoeg terug als echte false positive om er rekening mee te houden: toegangscontrolebevindingen op code die user mode al afdwingt, sharing-bevindingen op klassen die alleen worden binnengekomen via een context waarin sharing al is toegepast, retired-library bevindingen die matchen op een versienummer in een meegeleverde static resource, en reflected cross-site scripting op parameters die de DOM nooit bereiken.

Gelijk hebben is alleen niet genoeg. Het document is wat je erdoor helpt. Salesforce vraagt om een document dat uitlegt waarom elk gemarkeerd item geen beveiligingsrisico vormt, en zegt erbij dat je specifiek moet zijn over hoe je je beschermt tegen de aangegeven kwetsbaarheid. Geef elke bevinding een eigen regel: scanner en regel-id, bestand en regelnummer, een zin over het datapad, de precieze maatregel die het afdekt, en waar die maatregel in het package staat. Afdoen in een halve zin komt terug als een vraag, en vragen kosten weken. Voor het onderbouwingsformat en de fouten die het laten afkeuren, zie False positives documenteren voor de Salesforce security review.

Stap 5: Stel het inzendmateriaal samen

• Gebruikersdocumentatie die zo geschreven is dat iemand die de app nooit heeft gezien een volledige workflow kan doorlopen.
• Documentatie van de datastromen tussen de Salesforce-org en elke composite site, mobiele app of browserextensie.
• Alle scanrapporten, de DAST-endpointscreenshot en het false-positive document.
• Een Developer Edition org met het package geinstalleerd en realistische testdata.
• Inloggegevens voor elk extern systeem dat de app raakt, of een gehoste testinstantie ervan.
• Installatielinks en inloggegevens voor eventuele mobiele of desktopclients.

Daarna start je de review vanuit de Publishing Partner Console: open het tabblad Technologies, kies Start Review bij je oplossing en vul de secties contactpersonen, technische details, documentatie en testomgeving in voordat je betaalt.

Hoe lang duurt de security review, en wat kost hij?

Salesforce geeft aan dat een oplossing doorgaans 4 tot 5 weken door de review doet, en dat voor elke betaalde oplossing een fee van $999 geldt voor de eerste inzending en voor elke volgende poging. Vindt het team kwetsbaarheden, dan los je ze op en dien je opnieuw in, wat als nieuwe poging telt. Salesforce merkt ook op dat de meeste inzendingen bij de tweede poging slagen. Beide feiten wijzen dezelfde kant op: doe het werk aan toegangscontrole vooraan, want de goedkoopste inzending is de inzending die je maar een keer hoeft te doen.

Laat je de review liever over aan mensen die er al doorheen zijn gekomen? Tekunda verzorgt als Salesforce-partner voorbereiding op de AppExchange security review. Twijfel je nog of je externe hulp inschakelt, lees dan Wat een Salesforce PDO doet, en wanneer je er een inhuurt.

FAQ

Moeten gratis apps ook door de security review?

Ja. Een oplossing moet de review doorstaan voordat hij op de marketplace wordt gepubliceerd. De fee van $999 die Salesforce documenteert geldt voor betaalde oplossingen.

Betekent API-versie 67.0 dat ik CRUD-, FLS- en sharingwerk kan overslaan?

Nee. De nieuwe defaults gelden alleen voor klassen die op v67.0 of hoger zijn gecompileerd, en triggers draaien nog steeds in system mode. Declareer toegangsmodi en sharing expliciet, zodat de reviewer ze regel voor regel kan controleren.

Is Salesforce Code Analyzer op zichzelf genoeg?

Nee. Je hebt ook het rapport van de source scanner in het Partner Security Portal nodig, en elk extern endpoint dat je app aanroept heeft een eigen DAST-rapport nodig.

Verandert een Agentforce- of agent-app de checklist?

Dezelfde review geldt, maar elke externe dienst die je agent kan aanroepen moet beschreven en gescand zijn. Zie AppExchange security review voor agentic apps: wat er anders is.

Is de security review een eenmalige gebeurtenis?

Nee. Gepubliceerde oplossingen worden doorgaans een keer per jaar opnieuw beoordeeld, en Salesforce kan op elk moment om een review vragen. Nieuwe packageversies gebruiken een attestation in de Partner Console in plaats van een nieuwe review, dus houd de checklist aan als vaste releasegate.