Hoe ISV's slagen voor de Salesforce AppExchange Security Review

De meeste afwijzingen bij de AppExchange Security Review gaan niet over exotische bugs. Ze komen neer op een korte, voorspelbare lijst: niet-afgedwongen CRUD/FLS, sharing-overtredingen, zwakke sessie-instellingen en secrets in metadata. ISV's die de review zien als een code-audit twee weken voor indiening, verliezen er meestal een volledige cyclus aan.

Waarom zakken apps voor de Salesforce Security Review?

Het reviewteam van Salesforce voert statische analyse uit (Checkmarx, PMD via Salesforce Code Analyzer). Sinds de gehoste Chimera-scanner op 2025-06-16 is gestopt, is de dynamische scan van externe endpoints die je package aanroept jouw taak om uit te voeren en in te dienen, zoals beschreven in Zelf dynamische scans uitvoeren na Chimera. De fouten die we het vaakst zien bij ISV-trajecten vallen in vier categorieën:

• Gaten in CRUD/FLS. Apex die objecten leest of schrijft zonder de object- en veldtoegang van de huidige gebruiker te controleren, vooral in Visualforce-controllers en REST-endpoints.
• Ontbrekende sharing-declaraties. Klassen zonder with sharing die DML uitvoeren, of een "with sharing"-klasse die een "without sharing"-helper aanroept en diens lossere context overneemt.
• Verkeerde sessie- en identiteitsinstellingen. Testorgs waarin identity challenge of MFA de tooling van de reviewer blokkeert, in plaats van de aanbevolen aanpak met een IP-allowlist.
• Secrets op de verkeerde plek. API-sleutels in custom metadata types die elke subscriber-admin kan opvragen, en PII die wordt gelogd via System.debug.

Hoe bereid je een app voor op de AppExchange Security Review?

Voorbereiding is vooral discipline, geen nieuwe tooling. Voordat je een review aanvraagt:

• Draai Salesforce Code Analyzer op het volledige package, niet alleen op recent gewijzigde klassen, en beoordeel elke bevinding.
• Controleer of elke DML-opdracht in een klasse met with sharing staat, of documenteer de specifieke reden om CRUD/FLS te omzeilen (roll-up-aggregaties en interne logobjecten zijn de twee gevallen die Salesforce doorgaans accepteert).
• Scan elk niet-Salesforce-domein dat je package aanroept met een goedgekeurde webapplicatiescanner en los bevindingen met hoge ernst op vóór indiening.
• Haal secrets uit metadata en zet ze in Named Credentials of een externe secret store die tijdens runtime wordt aangesproken.

Wat betekent een false positive van Checkmarx of PMD echt?

Scanners markeren patronen, geen intentie, dus een deel van elk rapport is ruis: een SOQL-query die alleen maar op stringconcatenatie lijkt, of een debugregel die nooit gebruikersdata raakt. Elke gemarkeerde regel als verplichte codewijziging behandelen kost een cyclus. Sneller is elke bevinding afzetten tegen het echte risico, oplossen wat echt misbruikt kan worden en een korte onderbouwing schrijven voor wat je laat staan. Reviewers lezen onderbouwingen, maar belonen geen algemene "opgelost"-claims die bij een nieuwe scan niet standhouden.

Hoe verkleint een implementatiepartner het risico bij de Security Review?

Een partner die al eerder packages door de review heeft geloodst, weet welke bevindingen de discussie waard zijn en welke je beter gewoon oplost, en juist dat oordeel levert de tijdwinst op. Tekunda heeft AppExchange Security Reviews van begin tot eind geleid voor ISV-klanten, van de eerste Apex- en integratie-audit tot de herindiening na feedback van reviewers. Daardoor komen de twee of drie extra rondes die nieuwe indieners verrassen in onze trajecten zelden voor.

Het integratieoppervlak vergroot de scope van de review snel: elke callout, remote site-instelling en elk domein dat Salesforce-data opslaat, valt onder de webapplicatiescan van de reviewer. Dat in één keer goed doen, via ons integratie-engineeringwerk, is meestal het verschil tussen een schone indiening en een tweede ronde bevindingen.

Wat gebeurt er als de review met bevindingen terugkomt?

Een afwijzing is geen herstart. Raken de bevindingen alleen code die op het Salesforce-platform draait, upload dan een nieuwe managed package-versie en start de review opnieuw vanaf het tabblad Packages. Zat de oplossing volledig in je externe applicatie, dan kun je meestal de bestaande indiening aanpassen. Open in beide gevallen een case bij "Partner Community & AppExchange" met je packagenaam, ID en versie, zodat het reviewteam je herindiening aan de juiste wachtrij koppelt.

FAQ

Hoe lang duurt de Salesforce Security Review?

Doorlooptijden hangen af van de complexiteit van de indiening en het huidige reviewvolume, en Salesforce publiceert geen vaste SLA. Plan je releasekalender dus met marge.

Kan een ISV de review overslaan voor een package met een klein publiek?

Nee. Elk managed package, Platform API-oplossing of Marketing Cloud API-oplossing die via AppExchange wordt gedistribueerd, moet door de review vóór de vermelding, ongeacht de omvang van het beoogde publiek.

Geldt de review ook voor unmanaged packages?

Het formele Security Review-proces geldt specifiek voor managed 2GP- en 1GP-packages en API-gebaseerde oplossingen die voor een AppExchange-vermelding worden ingediend.

Wat is de meest gemaakte CRUD/FLS-fout?

Een controller of REST-endpoint bouwen die een object rechtstreeks via SOQL/DML leest of schrijft zonder eerst de rechten van de huidige gebruiker te controleren, waardoor restricties uit profielen en permission sets ongemerkt worden omzeild.

Een package netjes door de review krijgen is één onderdeel van leveren op AppExchange. Het product en de integraties meteen goed bouwen is het moeilijkere deel. Bereid je een indiening voor of plan je je volgende release, praat dan met ons product engineering-team of neem contact op om het werk af te bakenen.