For most ISVs, AppExchange security review is where the launch date slips. A failed submission means fixing the findings, re-running the scans, and joining the queue again — often weeks of delay, and for a paid app another review fee. The teams that pass on the first attempt don’t have a secret. They build for the review from the first line of code instead of preparing for it at the end. We built and published our own product, iSyncSF, and passed AppExchange security review on the first submission. Here’s what that taught us.
Review is a gate, not a formality
Security review is Salesforce verifying that your package respects every customer org’s security model instead of working around it. Reviewers combine automated scanning with hands-on testing of the installed package and any external services it talks to. That means architecture problems can’t be papered over with a cover letter. If your design depends on running in system mode everywhere or shipping data to an endpoint you haven’t secured, the fix is a redesign, and redesigns are what turn a two-week delay into a two-month one.
The cost is real too. Paid apps pay a fee for each review attempt — widely reported as $999 — while free apps don’t. Check the current figure in the Partner Community before you budget, but either way a second attempt costs time you’d rather spend selling.
What reviewers actually check
The findings that fail submissions are rarely exotic. The recurring themes:
- Sharing and permissions. Apex that ignores the running user’s object and field access, or classes declared without sharing for no documented reason. A single missed field-level security check is one of the most common first-submission failures.
- Injection paths. Dynamic SOQL built from user input without binding or escaping, and unescaped output that opens the door to cross-site scripting.
- Secrets and credentials. API keys hard-coded in Apex or stored where admins can read them, instead of protected settings or named credentials.
- Data leaving the platform. Calls to external services that aren’t secured, documented, and justified.
- Outdated components. Old JavaScript libraries with known vulnerabilities bundled into static resources.
Scan early, scan often, document the rest
Salesforce requires Code Analyzer reports with a security review submission, and the expectation is clear: run the scans, fix every violation you can, re-run, and submit the clean reports. Some findings will be false positives — a flagged pattern that isn’t exploitable in context. Those are acceptable, but each one needs a written explanation of why it’s safe. A pile of unexplained warnings reads as a team that didn’t look.
We don’t wait for submission week. The scanner runs in our CI pipeline on every change, so violations are fixed when they’re introduced and cheap to fix — the same principle behind governance-first CI across multiple orgs. By the time we submit, the report is a formality.
Engineer it in from the start
We treat security as a design constraint, not a late fix. Every data-access path enforces the user’s permissions. Sharing is declared explicitly on every class, and any exception is documented. Data stays on-platform wherever possible — iSyncSF is 100% Salesforce-native, which removed a whole category of review questions. Code is written to handle large data volumes safely, as we described in bulkifying Apex for large-record jobs, because performance and security reviewers both notice code that only works on ten records.
Static analysis catches the obvious classes of issue. A human review catches the rest: logic flaws, a permission check in the wrong place, an endpoint that trusts its input. That’s why every change we ship — including code our AI agents draft — is reviewed by a certified engineer before it merges.
Prepare the submission like a product
Reviewers need to test what you built, so make it easy. Provide a clean test org with the package installed and configured, working credentials for any external service, clear usage instructions for every feature, and your scan reports with false-positive notes. A reviewer who can’t reach a feature can’t pass it. We also include a one-page architecture overview showing where data is stored, which external endpoints are called and why, and how permissions are enforced — it answers the reviewer’s first questions before they ask them.
How we help
We help ISVs in two ways: a pre-submission security assessment of an existing package, with every finding fixed or documented, or full AppExchange development built for review from day one. Either way you get engineers who have taken their own product through security review and passed first time.
Key takeaways
- Build for AppExchange security review from the first line — architecture issues can’t be fixed in submission week.
- Most failures are missed sharing or field-level checks, injection paths, exposed secrets, or unsecured external calls.
- Run Code Analyzer in CI, document every false positive, and hand reviewers a test org that makes every feature reachable.