If you are an ISV shipping a managed package, the Salesforce security review is the gate between your app and the marketplace, and it is a real security test of your solution, not a paperwork check. This guide walks through what the review actually checks, the vulnerabilities that fail the most submissions, the scan reports you must attach, and how to prepare so you pass on the first attempt instead of paying the fee again. It is written for the package, not the customer org: if you need your own Salesforce org tested, that is Salesforce penetration testing and a different engagement.
One naming note up front. At TrailblazerDX 2026, Salesforce folded AppExchange, the Slack Marketplace, and its Agentforce ecosystem into one marketplace called AgentExchange. The security review is the same process under the new name, and Salesforce’s own documentation now titles it the AgentExchange security review. Most people still search for “AppExchange security review,” so this guide uses both.
What the Salesforce security review is, and what it costs
Every solution you list, whether a managed package, an API integration, or a web app that works with Salesforce data, has to pass the security review first. Salesforce’s reviewers test the whole solution, not just the code that runs on the platform: external web apps and services that authenticate your users or exchange Salesforce data are in scope too, which is why the submission asks for credentials to all of them.
The facts that shape your planning, from Salesforce’s own security review guidance on Trailhead:
- Fee. For every paid solution, Salesforce asks for a $999 fee for the initial submission and for any subsequent attempts. Free solutions do not pay the fee.
- An attempt. If the review finds vulnerabilities, you fix and resubmit, and that counts as another attempt at another $999. Salesforce notes that most submissions pass on the second attempt, which is exactly the pattern this guide is meant to break.
- Timeline. A solution typically takes 4 to 5 weeks to get through the review, and a follow-up review after fixes takes another 2 to 3 weeks.
- After approval. Salesforce can review a listed solution again at any time, and solutions are typically reviewed for security once a year.
A failed first attempt is not only $999. It is another few weeks in the queue while a competitor ships. Preparation is the cheapest part of the whole process.
The scans Salesforce requires
Salesforce expects specific reports with the submission. Its guidance names three scan reports: a Salesforce Code Analyzer report, a Partner Security Portal source scanner report, and a DAST report from the tool of your choice.
| Report | What it covers | Tooling |
|---|---|---|
| Salesforce Code Analyzer | Apex, Visualforce, Lightning (Aura and LWC), and JavaScript in the package | Salesforce Code Analyzer, run locally or in CI |
| Partner Security Portal source scan | A second static scan of the package source | The Checkmarx-based source code scanner in the Partner Security Portal, run from your partner account |
| DAST report | The running web endpoints of any off-platform component | A DAST tool such as OWASP ZAP or Burp Suite, both on Salesforce’s list of options |
| False-positive document | Every flagged item you believe is wrong, explained | Written by you, with the code that proves the control |
For a managed package, the Code Analyzer report is mandatory. For any part of the solution that runs on a domain you control, you attach a DAST report for those external endpoints. And for every scanner finding you plan to dispute, you write a false-positive explanation that shows, specifically, how the code protects against the vulnerability the tool flagged. A vague “not exploitable” note does not pass; a pointer to the exact with sharing declaration or the bound-variable query does. The submission also asks for usage documentation, a description of how data flows between the Salesforce org and any external component, and working test environments with credentials for every part of the solution.
The vulnerabilities that fail the most submissions
Salesforce publishes its own list of the top 20 vulnerabilities that fail partners in the review, and CRUD and FLS enforcement sits at the top by a significant margin. These are the issues to clear before you submit.
- CRUD and field-level security (FLS) enforcement. The number-one failure reason. Apex runs in system context, so it does not enforce a user’s object and field permissions unless you make it. The modern fix is to run queries and DML in user mode (
WITH USER_MODEon SOQL and SOSL, and user-mode DML). The older pattern is explicit describe checks such asisAccessible(),isCreateable(), andisUpdateable(), or stripping fields the user cannot see withSecurity.stripInaccessible(). - Insecure software versions. An outdated bundled library with a known CVE, jQuery being the classic offender. Inventory every non-Salesforce dependency and check it against published vulnerabilities, for example with the RetireJS engine that ships in Code Analyzer.
- Sharing violations. An Apex class without an explicit sharing declaration can ignore the org’s sharing rules. Declare
with sharingorinherited sharingon every class, and document the business case for any class that genuinely must runwithout sharing. - Insecure storage of secrets. No hard-coded keys, even inside a managed package. Keep secrets in protected custom metadata types or protected custom settings, and use named credentials for callout endpoints and their authentication.
- Transport security. External endpoints that carry Salesforce data are tested too. Enforce TLS 1.2 or higher, fix weak ciphers and certificate problems, and never send data or secrets over plain HTTP.
- Injection and cross-site scripting. SOQL injection from dynamic queries built with string concatenation, and stored or reflected XSS in Visualforce, Aura, and LWC. Use bound variables for queries, and avoid unsafe DOM patterns such as
innerHTMLandlwc:dom="manual"on data you have not sanitized. - CSRF, information disclosure in errors and debug logs, and loading scripts or CSS from outside static resources round out the common list.
These map cleanly onto the OWASP Top 10 (2025): the review is a platform-specific expression of broken access control, injection, misconfiguration, and vulnerable components. If your team already tests against OWASP, most of the muscle memory transfers; what changes is the Salesforce-specific enforcement model.
How Invadel prepares a package
We treat AppExchange review prep as a scoped engagement that ends with a package ready to submit, not a scan dump. It is a fixed $5,200, published on the Salesforce testing cost page.
- The scans Salesforce expects, run and triaged: a Code Analyzer scan of the package and a DAST report on any external endpoints, plus triage of the Partner Security Portal scan you run from your partner account, all in the format the review reads.
- A manual package review against the security review checklist: CRUD and FLS enforcement, sharing, SOQL injection, XSS, secrets handling, and OAuth. This is the source code review work a scanner cannot do, because it reads intent, not just patterns.
- A false-positive document that explains each flagged item the automated tools got wrong, with the code that proves the control, in the format reviewers accept.
- A recheck before you submit, so the package, its test org and credentials, and the scan reports are complete and consistent when you click submit.
We prepare the submission. Salesforce runs the official review and charges its own fee, and we do not submit on your behalf.
Where this fits your wider security
Passing the review gets you listed. It does not, by itself, answer the security questionnaire your first enterprise customer sends. Those buyers ask for evidence that maps to their frameworks, and the same testing feeds it: an ISV selling into regulated buyers usually also wants web application penetration testing of the product and a SOC 2 report. Our guide to penetration testing for SaaS companies covers how buyers read those results, and if your package uses connected apps, the risk of malicious connected OAuth apps is worth understanding before you scope OAuth into the review.
Frequently asked questions
Is it still called the AppExchange security review? Salesforce now calls it the AgentExchange security review, after merging AppExchange into AgentExchange in 2026. The process is the same, and most searches and community guides still say AppExchange. Either way, a paid solution pays $999 per attempt.
How much does the Salesforce security review cost? Salesforce charges $999 for a paid solution’s initial submission and $999 again for each subsequent attempt. Free solutions pay nothing. That fee is separate from any prep work you do beforehand. Invadel’s AppExchange review prep is a fixed $5,200, on the pricing page.
Why do so many submissions fail the first time? Salesforce says most pass on the second attempt, and its own top 20 list puts CRUD/FLS enforcement first by a significant margin, with outdated libraries and sharing violations also common. All three can be found and fixed before submission with a manual code review, which is the whole point of preparing.
What do I need to submit? The scan reports (Salesforce Code Analyzer, the Partner Security Portal source scan, and a DAST report for external endpoints), explanations for any disputed findings, usage documentation, data-flow documentation for any external component, and working test environments with credentials so reviewers can exercise the whole solution.
How long does the review take? Salesforce says a solution typically takes 4 to 5 weeks, and a follow-up review after fixes takes another 2 to 3 weeks. That is why avoiding a second attempt saves real time, not just the fee.
Is AppExchange review prep the same as testing my Salesforce org? No. Review prep readies an ISV’s managed package for Salesforce’s review. A Salesforce org penetration test checks your own org: sharing model, guest exposure, Apex, and connected apps. They are separate engagements with separate prices; the org test starts at $6,800.
Fixed price, fixed scope, and a recheck of your fixes before you submit. Scope your engagement and get a written price within one business day.
Written by
Invadel Team
Senior penetration testers writing from real engagements, the same team that scopes, tests, and reports for our clients. About Invadel →