Mastering the AppExchange Security Review: A Step-by-Step Guide for Partners

Listing your solution on the Salesforce AppExchange is a major milestone for any partner. It opens the door to the vast Salesforce ecosystem, but there is one critical gatekeeper you must pass first: the AppExchange Security Review.

Salesforce prioritizes trust above all else. To ensure customer data remains safe, every managed package, API solution, and Marketing Cloud app must undergo a rigorous security assessment. While the process can seem daunting, proper preparation is the key to success.

Based on the official ISVforce Guide, here is your roadmap to navigating and passing the security review.

Phase 1: Preparation and Secure Development

The security review isn’t just a final exam; it starts with how you build your app. Before you proceed with any submission, ensure you have laid the groundwork by adopting secure coding standards, enforcing Field-Level Security (FLS) and CRUD permissions, and certifying your solution as Lightning Ready.

Beyond these universal requirements, the preparation steps differ significantly depending on whether you are building a First-Generation (1GP) or Second-Generation (2GP) managed package.

Common Prerequisites (Both 1GP & 2GP)

• Adopt Secure Coding Standards: Your solution must comply with strict security requirements. Common violations to avoid include SOQL injection, Cross-Site Scripting (XSS), and insecure data storage.
• Enforce Field-Level Security (FLS) and CRUD: Your Apex code must respect the organization’s Create, Read, Update, and Delete settings. Ensure your code checks permissions before accessing data.
• Certify Lightning Readiness: All new solutions submitted for review must be certified as Lightning Ready.
• Connect Your Org: Ensure your packaging org (for 1GP) or Dev Hub org (for 2GP) is connected to the AppExchange Partner Console.

Prerequisites for First-Generation Managed Packages (1GP)

For 1GP, your packaging organization is the “source of truth.”

1. Dedicated Packaging Org: You must use a dedicated Developer Edition org specifically for packaging your application. This org will contain all the metadata for your package.
2. Namespace Registration: You need to register a unique namespace for your package within your packaging org. This namespace will be prefixed to your components to prevent naming conflicts.
3. Managed - Released Version: You must create a “Managed - Released” version of your package from your packaging org. Beta versions cannot be submitted for security review.

Prerequisites for Second-Generation Managed Packages (2GP)

2GP is a modern, source-driven approach where your version control system is the “source of truth,” managed through Salesforce DX.

1. Enable Dev Hub: You must designate and enable a Dev Hub org. This org will own your packages and track their versions.
2. Salesforce CLI: Install and configure the Salesforce CLI on your development machine to create and manage your packages from the command line.
3. Namespace Registry: Register your namespace in a separate Developer Edition org and then link it to your Dev Hub. This allows you to use the same namespace across multiple 2GP packages.
4. Source-Driven Development: Your package’s metadata should be stored in a version control system (like Git). You will use the CLI to build package versions directly from your source code.
5. Managed Package Version: Similar to 1GP, you must create a managed package version using the Salesforce CLI before it can be submitted for review.

Phase 2: Mandatory Testing and Scanning

You cannot submit your app without “showing your work.” Salesforce requires you to run specific automated scanning tools and submit the reports.

1. Salesforce Code Analyzer

You are required to scan your managed package using the Salesforce Code Analyzer. This unified tool runs multiple engines (like PMD, ESLint, and RetireJS) to identify static code issues and front-end vulnerabilities.

2. Source Code Scanner (Checkmarx)

For most submissions, you must run the Source Code Scanner (powered by Checkmarx), which is accessible via the Partner Security Portal. This scanner analyzes your Apex, Visualforce, and Lightning code for vulnerabilities.

3. External Endpoint Scanning (ZAP/Burp Suite)

If your solution communicates with external web applications or services (non-Salesforce endpoints), you are required to scan them using a dynamic application security testing (DAST) tool like OWASP ZAP or Burp Suite. You must verify you have permission to scan these external endpoints before proceeding.

Phase 3: Managing False Positives

It is common for scanners to flag code that isn’t actually a vulnerability—these are known as false positives. You don’t need to rewrite secure code just to please a scanner, but you must document it.

• Analyze the Report: Review every issue flagged by the scanners.
• Fix or Document: If it’s a real issue, fix it. If it’s a false positive, create a document explaining why the code is secure and doesn’t pose a risk.
• Be Specific: Your documentation should reference the specific file, line number, and technical justification for why the vulnerability is not exploitable.

Phase 4: Gathering Submission Materials

When you are ready to submit via the AppExchange Partner Console, make sure you have the following “submission kit” ready. You won’t be able to submit without these:

1. Test Environment: A Developer Edition org with your managed package installed and configured.
2. Credentials: Valid login credentials for the test org and any external systems your app integrates with.
3. Scan Reports: The most recent reports from Checkmarx, Code Analyzer, and any external scans (ZAP/Burp).
4. Documentation: Your false positive analysis and user guides.

Phase 5: The Review Timeline

Once you submit, the process moves through several stages:

1. Submission Verification (1–2 Weeks): The operations team ensures all your materials (credentials, scans, documents) are present and valid.
2. Technical Testing (3–6 Weeks): The Product Security team performs manual and automated penetration testing on your solution. Sometimes, the wait time can be longer than 6 weeks depending on demand, especially during the lead up to Dreamforce.

Outcomes

• Approved: Congratulations! You can immediately list your solution on AppExchange.
• Not Approved: You will receive a report detailing the specific vulnerabilities found. You must fix these issues, generate new scan reports, and resubmit. All resubmissions require a new fee to be paid. If you believe the report is incorrect, raise a case or work with your ISV Technical Advisor if you have been assigned one.

---

For Free Apps: How to Get Your Security Review Fee Waiver

If you plan to distribute your solution for free, you are ‘exempt’ from the standard security review fee. However, the submission system will still prompt you for payment. You must request a fee waiver code (voucher) before you submit. The waiver code will reduce your fee to US$1.

Steps to request a voucher:

1. Log in to the Salesforce Partner Community.
2. Click the ? (Help) icon and select Log a Case for Help.
3. Select Partner Programs & Benefits as the product and ISV Technology Request as the topic.
4. In the subject and description, state that you are submitting a free app and request a Security Review Fee Waiver Code.
5. Once the support team verifies your eligibility, they will email you a code. Enter this voucher code at the payment screen of the Security Review Wizard to zero out the cost.

Pro Tips for Success

• Wait for Package Propagation: After you upload a new package version in your org, it can take some time to appear in the AppExchange submission portal. If your new version isn’t visible immediately, wait a few hours and try again before logging a support case.
• Book Office Hours Immediately: The Product Security team offers “Office Hours” for security guidance, but there can be a 4–6 week lead time for availability. I usually recommend booking a slot as soon as possible. You can simply cancel it if you don’t end up needing it.
• Test Early and Often: Don’t wait until the end of development to run security scans. Integrate tools like the Salesforce Code Analyzer into your daily workflow.
• Use AI to review your code: Salesforce Vibes, Claude, Gemini, Codex are all really good at reviewing your code for Salesforce best practices and compliance to security standards. Run your code through one or more of these LLMs to get recommendations and suggestions for improvement before you submit.

Passing the security review is a rigorous process, but it serves as a powerful badge of trust for your customers. By following these guidelines and preparing thoroughly, you can navigate the review with confidence.