Review is a gate, not a formality
AppExchange security review is a hard gate, and a failed submission can cost weeks. Teams treat it as paperwork at the end and then discover their architecture has issues that cannot be patched over the weekend. The way to pass first time is to build for the review from the first line, not to prepare for it at the end.
We built and published iSyncSF through this process and passed on the first submission, which shapes how we advise ISV clients.
What reviewers actually check
The recurring themes are enforced sharing and CRUD/FLS checks, no SOQL or SOAP injection paths, secure handling of secrets, sensible use of the platform's security features, and no data leaving the platform where it should not. Most first-submission failures are not exotic; they are a missed FLS check or an object accessed without respecting the user's permissions.
Reviewers are checking that your package respects the org's security model rather than working around it. Build that in and the review is confirmation, not discovery.
Engineer it in from the start
We enforce sharing, check field and object permissions, and keep data on-platform as design constraints, not late fixes. Static analysis catches the obvious classes of issue before submission, and a human review catches the rest.
Passing security review first time is not luck; it is the natural result of building the package the way the review expects from day one.
Key takeaways
- Build for security review from the first line, not as end-of-project paperwork.
- Most failures are missed FLS/CRUD checks, injection paths, or off-platform data.
- Enforce sharing and permissions as design constraints; iSyncSF passed on first submission.