AppExchange Security Review
The AppExchange Security Review is the mandatory Salesforce review process that every app, component, or solution must pass before it can be listed on the AppExchange.
Definition
The AppExchange Security Review is the mandatory Salesforce review process that every app, component, or solution must pass before it can be listed on the AppExchange. A partner submits the package and supporting documentation through the Partner Portal; Salesforce's product security team runs automated and manual checks for OWASP-top-ten vulnerabilities, insecure coding patterns, improper sharing usage, exposed credentials, and policy compliance. Apps that pass are listed; apps that fail get a detailed remediation report and can re-submit after fixing.
The review exists because installed AppExchange packages run inside customer orgs with the permissions of whoever installs them, often with broad data access. A vulnerable package becomes a vulnerable customer org. The review is one of the longest single processes in the Salesforce partner journey, commonly taking 8 to 16 weeks from first submission to listing approval depending on package complexity and how clean the first submission is. Re-reviews on package updates are faster but still required for any change that affects security surface.
Why the Security Review is the gating event of the AppExchange partner journey
What gets reviewed
The review covers the entire package: Apex classes and triggers, Lightning components (Aura and LWC), Visualforce pages, custom objects and fields, profiles and permission sets the package adds, connected app configurations, named credentials, external services. Beyond the code, Salesforce reviews the partner business listing, support model, data processing addendum (if the package touches customer data), and the supporting documentation. The review surface is broad because customer trust is the asset being protected; any weak link in the package becomes a customer-org liability.
The submission packet and what to include
The submission requires the package itself (uploaded through the Partner Portal), the test org credentials so the reviewer can install and exercise the package, the public documentation, the listing copy, and the data processing addendum where applicable. The single largest cause of re-review delays is incomplete documentation; reviewers need to understand what every external callout does, why every permission set grants what it grants, and how every storage write is justified. Spending an extra week on documentation before submission usually saves four weeks of back-and-forth during review.
Automated scans: Checkmarx and CheckProduct
Salesforce runs automated security scans on every submission. Checkmarx scans the Apex and Lightning code for common vulnerability patterns (SOQL injection, cross-site scripting, hardcoded secrets, insecure deserialization). CheckProduct (Salesforce's internal tool) checks for Salesforce-specific anti-patterns (WITHOUT SHARING used inappropriately, sharing rule bypasses, governor limit risks at scale). Partners can run the same scans before submission through the Partner Security Portal. Pre-scanning catches the easy issues before the formal review and meaningfully shortens the review cycle.
Manual review and the security architect
After automated scans, a Salesforce security architect manually reviews the package. They install it in a test org, exercise the functionality, read the code for issues the scanners miss, and verify the documentation matches the actual behavior. The manual review is where most edge-case issues surface: a sharing model that looks fine in code but produces over-permissioning at scale, an external service that handles personal data without a documented retention policy, a UI component that exposes a callable Apex method without authentication. Manual review takes the largest single slice of total review time.
Common failure patterns
Five patterns cause the majority of first-submission failures. Apex classes marked WITHOUT SHARING for the wrong reason (typically to bypass a permission check rather than for an architectural reason). Lightning components that fetch sensitive data through unsecured Apex calls. Hardcoded API keys or test data in the package. Permission sets that grant Modify All Data or Modify Metadata without justification. External service callouts without a named credential. Each is fixable but each requires code or configuration changes plus re-submission. Knowing the patterns before first submission cuts the failure rate dramatically.
Re-review for updates and version management
Once a package is approved, every subsequent version requires re-review. Re-reviews are faster (often 2 to 6 weeks) because the security baseline is established and reviewers focus on diffs. Partners must submit any update that changes security surface: new Apex classes, new external callouts, new permission sets, new connected app scopes. Cosmetic changes (UI label edits, documentation tweaks) do not require re-review. Maintaining a private test org with the approved baseline plus the proposed changes is the standard partner practice for assessing whether a given change triggers re-review.
The Partner Security Portal and ongoing obligations
The Partner Security Portal is the central submission, scan, and tracking surface. Partners file submissions, run pre-scans, track review status, and receive remediation reports through the portal. Beyond initial review, listed partners have ongoing obligations: incident response procedures, vulnerability disclosure handling, periodic security questionnaires from enterprise customers. The Security Review is the entry gate; running an AppExchange app responsibly is an ongoing program. Salesforce can pull a listing for serious security incidents even years after the initial approval.
How to prepare for and pass the AppExchange Security Review on the first submission
The partners who pass on the first submission are the ones who treat the review as a quality gate, not a paperwork step. Run the pre-scans, document everything, fix the known anti-patterns, then submit. The partners who fail are the ones who submit and hope.
- Read the AppExchange Security Review requirements end to end
The Partner Security Portal hosts the current requirements document. Read it before writing any code. The requirements update per Salesforce release; old reviews of the requirements miss new policy.
- Run Checkmarx and CheckProduct pre-scans
Pre-scans are available through the Partner Security Portal. Run them on the package, fix every High and Medium finding, document any False Positive with reasoning. Pre-scan clean is the bar for first submission.
- Audit Apex sharing model class by class
Default WITH SHARING. Only use WITHOUT SHARING when the architecture requires it (system-level callbacks, integration users) and document the reason in the class header.
- Audit Lightning components for unsecured data access
Every @AuraEnabled method should have explicit access checks. Components that fetch sensitive data must verify the calling user has appropriate permissions, not rely on the UI to gate access.
- Remove hardcoded credentials and test data
Hardcoded API keys in Apex, test users in custom settings, sample data in static resources. All of these fail review. Use Custom Metadata Types and Named Credentials for configuration; ship sample data through post-install scripts.
- Document every permission set, named credential, and external callout
Documentation is what saves the manual review. For each permission set: what it grants and why. For each named credential: what external system, what authentication, what data flows. For each callout: what payload, what response handling.
- Submit through the Partner Security Portal with all artifacts
Package upload, test org credentials, documentation, listing copy, data processing addendum if applicable. Missing artifacts add weeks to review time.
- Respond to remediation feedback quickly and completely
The remediation report is the roadmap to approval. Address every item; do not pick and choose. Resubmit with a documented response per item. Partial responses extend the cycle.
First submission vs re-submission vs update review. Each has different artifact requirements and timelines.
Checkmarx and CheckProduct findings. Address before submitting to shorten the formal review.
Org credentials the reviewer uses to install and exercise the package. Stage with realistic test data.
Per-permission-set, per-callout, per-named-credential documentation. The largest single factor in first-submission outcome.
Required when the package processes customer data outside Salesforce. Pre-prepare if applicable.
- WITHOUT SHARING used to bypass permission checks (rather than for legitimate system-level reasons) is the single most common cause of failure. Document the reason in every WITHOUT SHARING class header.
- Hardcoded credentials and test data in the package fail review every time. Use Custom Metadata Types and Named Credentials; ship sample data through post-install.
- Incomplete documentation extends review by weeks. Reviewers need to understand every callout, permission, and configuration choice before they can clear it.
- Pre-scans are available and underused. Partners who skip pre-scans fail first submission on issues that the scanners would have caught in an afternoon.
- Every package version after the first requires re-review for security-affecting changes. UI label edits are exempt; new Apex, new callouts, new permissions are not.
Trust & references
Straight from the source - Salesforce's reference material on AppExchange Security Review.
- ISVforce GuideSalesforce Developers
Hands-on resources to go deeper on AppExchange Security Review.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. What does the AppExchange Security Review evaluate?
Q2. Which packages must pass security review?
Q3. What should an ISV do to reduce the number of review cycles?
Discussion
Loading discussion…