Salesforce Security Review Checklist: What to Fix, In Order

A Salesforce security review checklist is only useful if it is ordered. Most submissions fail on a short, predictable list, and access control sits at the top of it. Work in this order: enforce user-mode access in code, triage the three scanner reports, then assemble the submission materials and a test environment the reviewer can actually use. Salesforce puts a typical review at 4 to 5 weeks, so a rejection costs you a release cycle, not an afternoon.

Tekunda has taken managed packages through the review in healthcare, logistics and manufacturing. What follows is the order we work in, not a description of the process. For the end-to-end submission journey, see How ISVs Pass the Salesforce AppExchange Security Review.

The checklist at a glance

1. Confirm what you are submitting: a managed package, plus every external service it touches.
2. Fix access control: user mode, explicit sharing, no injectable SOQL.
3. Fix output handling, secrets, transport security and authentication.
4. Run Code Analyzer, the Partner Security Portal source scan and a DAST scan.
5. Fix what each scanner's bar requires, and document every false positive.
6. Package the documentation, credentials and a working test org.
7. Submit from the Partner Console and plan for the annual re-review.

What changed in 2026

Three things moved this year, and older checklists predate all of them.

• The marketplace is now AgentExchange. Salesforce renamed AppExchange to AgentExchange at TrailblazerDX 2026 and folded the Slack Marketplace into it. Salesforce's own Trailhead material now uses the new name, but the security review itself is still the gate to a listing.
• Apex API version 67.0 changes the security defaults. Per Salesforce's Summer '26 architect highlights, database operations now run in user mode by default, classes without a sharing declaration default to with sharing, and WITH SECURITY_ENFORCED is removed, so a class still using it on v67.0 will not compile. Triggers are the exception: they always run in system mode.
• You run the dynamic scan yourself. Salesforce's preparation guidance now recommends OWASP ZAP or Burp Suite Enterprise Edition for external endpoints and accepts your preferred DAST scanner. See Running Your Own Dynamic Scans After Chimera for the tools and the report to submit.

Step 1: Confirm what is in scope

Salesforce's guidance is blunt that all of your solution's components and services, no matter where they live, are fair game. That means the package, any web service it calls, any site that stores Salesforce data, and any mobile or desktop client. Settle your package type before you start fixing code, because it decides what you upload; Salesforce Packaging Models for ISVs: 1GP vs 2GP vs Unmanaged covers that choice.

Step 2: Fix the findings that get submissions rejected, in order

Fix these top to bottom. The items near the top are both the most common findings and the most expensive to retrofit, which is why leaving them until last is how a submission slips a cycle.

1. Access control that is not enforced in user mode. Every query and DML operation has to respect the running user's object permissions, field-level security and sharing. Do not rely on the v67.0 default alone: a package usually carries classes on older API versions, and trigger handlers can be entered from a trigger running in system mode. Set the access mode explicitly with WITH USER_MODE on SOQL and AccessLevel.USER_MODE on Database calls, and replace any remaining WITH SECURITY_ENFORCED before you bump the API version.
2. Sharing declared on the wrong classes. Below v67.0, a class with no sharing keyword inherits sharing from its caller, so a helper invoked from an @AuraEnabled method can quietly run without it. Declare with sharing, without sharing or inherited sharing explicitly on every class, including inner and utility classes, so the reviewer never has to work out which default applies.
3. Dynamic SOQL assembled from input. Use bind variables. If a query genuinely has to be built as a string, escape every interpolated value and keep that escaping visible in the same method, because that is where a reviewer reads it.
4. Unescaped output. Anything reaching the page through escape="false", lwc:dom="manual" or innerHTML has to be sanitised before it gets there, not after.
5. Secrets and customer data in the wrong place. Hardcoded keys in Apex, tokens in unprotected custom settings, a record with personal data passed to System.debug. Named Credentials and protected custom metadata are what reviewers expect instead.
6. Weak transport or storage encryption. Salesforce's list of the most common review findings requires TLS 1.2 on connections involving your sites and portals, and the team scans every external endpoint for it. Encrypt anything you store off-platform as well.
7. External systems authenticated with a stored username and password. Use OAuth for every connection your package opens to a service you or the customer runs. Stored credentials are a finding on their own, and they make the data flow document harder to defend.
8. A composite site shipped without the basics. If your solution includes a web surface outside the org, it needs security headers, and its cookies need Secure and HttpOnly. Reviewers check the site you hand them, not the one you describe.
9. External endpoints nobody scanned. If your package calls a service you operate, that service is in scope and needs its own dynamic scan report.
10. A test environment the reviewer cannot use. An expired org, an identity challenge that locks them out, or objects with no data in them. Salesforce tells partners to treat the review team as a potential customer test-driving the whole solution end to end, and it cannot review what will not run.

Step 3: Run the scanners and meet each one's bar

You must include a Salesforce Code Analyzer report, a Partner Security Portal source scanner report and a DAST report. The bar is not zero findings, and it is different for each scanner:

• Salesforce Code Analyzer: fix all security-related findings and errors except false positives, and ignore findings that are not security related. It does not scan external endpoints.
• Partner Security Portal source scanner (Checkmarx): fix Low, Medium and High findings, and leave informational warnings alone.
• DAST scanners such as ZAP, Burp Suite, Veracode Dynamic Analysis, Intruder and Acunetix: fix everything except informational items and warnings, then attach a screenshot proving the right external endpoint was scanned.

Generate the Code Analyzer v5 report with the AppExchange rule selector, so it matches what the reviewer expects. On a complex codebase the run can take hours:

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

Which scans are mandatory has shifted more than once, so confirm the current scanner requirements before you generate anything.

Step 4: Document every false positive

Across our submissions, four categories come back as genuine false positives often enough to plan for: access-control findings raised against code that already enforces user mode, sharing findings on classes only ever entered through a context that has applied sharing, retired-library findings matched on a version string inside a bundled static resource, and reflected cross-site scripting findings on parameters that never reach the DOM.

Being right is not enough, though. The document is what passes. Salesforce asks for a document explaining why each flagged item does not pose a security risk, and tells you to be specific about how you protect against the vulnerability indicated. Give every finding its own entry: scanner and rule identifier, file and line, one sentence describing the data path, the exact control that protects it, and where that control lives in the package. One-line dismissals come back as questions, and questions cost weeks. For the justification format and the mistakes that get it rejected, see How to Document False Positives for the Salesforce Security Review.

Step 5: Assemble the submission materials

• Usage documentation written so that someone who has never seen the app can complete a full workflow.
• Data flow documentation between the Salesforce org and any composite site, mobile app or browser extension.
• Every scan report, the DAST endpoint screenshot and the false positive document.
• A Developer Edition org with the package installed and realistic seeded data.
• Credentials for each external system the app touches, or a hosted test instance of it.
• Install links and credentials for any mobile or desktop client.

You then start the review from the Publishing Partner Console: open the Technologies tab, choose Start Review on your solution, and complete the contacts, technical details, documentation and test environment sections before payment.

How long does the security review take, and what does it cost?

Salesforce states that a solution typically takes 4 to 5 weeks to get through the review, and that for every paid solution there is a $999 fee for the initial submission and for any subsequent attempts. If the team finds vulnerabilities, you fix and resubmit, and that counts as another attempt. Salesforce also notes that most submissions pass on the second attempt. Both facts argue for the same thing: front-load the access control work, because the cheapest submission is the one you only have to make once.

If you would rather the review was handled by people who have cleared it before, Tekunda runs AppExchange security review preparation as a Salesforce partner. If you are still weighing whether to bring in outside help, What a Salesforce PDO Does, and When to Hire One sets out where a PDO earns its fee.

FAQ

Do free apps need a security review?

Yes. A solution has to pass the review before it is listed on the marketplace. The $999 submission fee that Salesforce documents applies to paid solutions.

Does API version 67.0 mean I can skip CRUD, FLS and sharing work?

No. The new defaults only apply to classes compiled at v67.0 or later, and triggers still run in system mode. Declare access modes and sharing explicitly so the reviewer can verify them line by line.

Is Salesforce Code Analyzer enough on its own?

No. You also need the Partner Security Portal source scanner report, and any external endpoint your app calls needs a DAST report of its own.

Does an Agentforce or agent-based app change the checklist?

The same review applies, but every external service your agent can call has to be described and scanned. See AppExchange Security Review for Agentic Apps: What Is Different.

Is the security review a one time event?

No. Listed solutions are typically re-reviewed once a year, and Salesforce can request a review at any time. New package versions use an attestation in the Partner Console instead of a fresh review, so keep the checklist as a standing release gate.