How ISVs Pass the Salesforce AppExchange Security Review

Most AppExchange security review rejections are not exotic bugs. They trace back to a short, predictable list: unenforced CRUD/FLS, sharing violations, weak session settings, and secrets in metadata. ISVs that treat the review as a code audit two weeks before submission usually lose a full cycle to it.

Why do apps fail the Salesforce security review?

Salesforce's review team runs static analysis (Checkmarx, PMD via Salesforce Code Analyzer) and dynamic scans against any third-party endpoints your package calls. The failures we see most on ISV engagements fall into four buckets:

• CRUD/FLS gaps. Apex that reads or writes objects without checking the running user's object and field-level access, especially in Visualforce controllers and REST endpoints.
• Missing sharing declarations. Classes without with sharing that perform DML, or a "with sharing" class that calls a "without sharing" helper and inherits its looser context.
• Session and identity misconfiguration. Test orgs with identity challenge or MFA blocking the reviewer's tooling, instead of the recommended IP allowlist approach.
• Secrets in the wrong place. API keys stored in custom metadata types any subscriber admin can query, and PII logged through System.debug.

How do you prepare an app for the AppExchange security review?

Preparation is mostly discipline, not new tooling. Before you request a review:

• Run Salesforce Code Analyzer against the full package, not just recently touched classes, and triage every finding.
• Confirm every DML statement sits inside a class declared with sharing, or document the specific case for bypassing CRUD/FLS (roll-up aggregates and internal logging objects are the two Salesforce generally accepts).
• Scan every non-Salesforce domain your package calls with an approved web application scanner and resolve high-severity findings before submission.
• Move secrets out of metadata and into Named Credentials or an external secret store referenced at runtime.

What does a false positive from Checkmarx or PMD actually mean?

Scanners flag patterns, not intent, so a chunk of every report is noise: a SOQL query that merely looks like string concatenation, or a debug line that never touches user data. Treating every flagged line as a required code change wastes a cycle. The faster path is triaging each finding against real risk, fixing what's genuinely exploitable, and writing a short justification for anything left as-is. Reviewers read justifications; they don't reward blanket "fixed" claims that don't hold up on re-scan.

How does an implementation partner reduce security review risk?

A partner who has taken packages through the review before knows which findings are worth arguing and which are worth just fixing, and that judgment is where the time savings come from. Tekunda has led AppExchange security reviews end to end for ISV clients, from the initial Apex and integration audit through resubmission after reviewer feedback, so the two or three round trips that catch first-time submitters off guard rarely happen on our engagements.

Integration surface compounds review scope fast: every callout, remote site setting, and domain that stores Salesforce data is in scope for the reviewer's web application scan. Getting that right the first time, through our integration engineering work, is usually the difference between a clean submission and a second round of findings.

What happens if the review comes back with findings?

A rejection is not a restart. If findings only touch code running on the Salesforce platform, upload a new managed package version and start review again from the Packages tab. If the fix was entirely in your external application, you can usually edit the existing submission instead. Either way, log a case against "Partner Community & AppExchange" with your package name, ID, and version so the review team matches your resubmission to the right queue.

FAQ

How long does the Salesforce security review take?

Timelines vary by submission complexity and current review volume, and Salesforce does not publish a fixed SLA, so plan release calendars with buffer.

Can an ISV skip the review for a narrow-audience package?

No. Any managed package, Platform API solution, or Marketing Cloud API solution distributed on AppExchange must pass review before listing, regardless of intended audience size.

Does the review apply to unmanaged packages?

The formal security review process applies specifically to managed 2GP and 1GP packages and API-based solutions submitted for AppExchange listing.

What's the single most common CRUD/FLS mistake?

Building a controller or REST endpoint that reads or writes an object directly via SOQL/DML without checking the running user's permissions first, silently bypassing profile and permission set restrictions.

Getting a package through review cleanly is one part of shipping on AppExchange; building the product and integrations right the first time is the harder part. If you're preparing a submission or planning your next release, talk to our product engineering team, or get in touch to scope the work.