AgentExchange Security Review checklist: what to check before you submit

Most teams that fail the AgentExchange (formerly AppExchange) Security Review do not fail on a clever exploit. They fail on something they could have checked in an afternoon: a missing scan report, a test org the reviewer cannot log in to, an API key in a custom setting, an external endpoint nobody scanned. A failed submission costs weeks of calendar time, so the cheapest work you will do is the work before you press submit.

This is a practical, tick-box checklist for the week before submission. It is deliberately different from our post on what fails the review, which goes deep on CRUD, FLS, sharing and XSS in code. Here the focus is everything around the code: the package, the reports, the reviewer's access and the paperwork.

#1. Know what is in scope

The reviewers assess your whole solution, not only the Salesforce package. Write the list down before anything else.

• Every Salesforce component: Apex, LWC, Aura, Visualforce, Flows, permission sets, connected apps or External Client Apps, Named Credentials.
• Every external web application, API or service the package calls or that calls into Salesforce.
• Mobile apps, browser extensions or desktop clients that are part of the offering.
• Third-party libraries bundled in static resources, with their versions.

Anything missing from this list is something you will not have scanned or documented, and it is usually where reviewers look.

#2. Package and org hygiene

• If you ship a package, it is a managed package, built and installed the way a customer would install it.
• Permission sets grant only what the app needs. No Modify All Data, View All Data or Author Apex unless you can justify it in writing.
• No profile changes that a customer would inherit without asking.
• Guest and Experience Cloud access is off unless the product needs it, and where it is on, the guest profile is minimal.
• Debug code, test-only endpoints and verbose logging of record data are removed.

#3. Code checks you should already pass

Run your own checks before the reviewers do. The common failure classes are well known:

• Object and field permissions enforced on every query and DML path (WITH USER_MODE, user-mode DML or Security.stripInaccessible).
• Every class declares its sharing keyword, and every without sharing has a written reason.
• No SOQL or SOSL built by concatenating user input.
• No unescaped output in Visualforce, Aura or LWC (lwc:dom="manual" and innerHTML reviewed).
• No outbound HTTP to plain http:// endpoints.

The readiness checklist breaks these down by category.

#4. Secrets and credentials

This category fails more submissions than it should, because the fix is simple.

• No API keys, passwords or tokens in Apex, JavaScript, static resources or metadata.
• Secrets stored in protected custom settings, protected custom metadata, or Named Credentials with External Credentials.
• No secrets in the git history of the code you are submitting, if the reviewers might see it.
• OAuth callback URLs use HTTPS, and scopes are the minimum the integration needs.

#5. Scan reports to attach

The review asks for evidence that you scanned. Prepare each report as a file you can upload.

• A Salesforce Code Analyzer report for the package source. This is required: no other scanner replaces it.
• A dynamic scan report for every external web application or API in scope, run against the environment the reviewers will test.
• A false-positive document for every finding you believe is not exploitable, with a specific reason per row ("FLS checked on line 42 via stripInaccessible" rather than "not applicable").
• All reports dated close to submission and matching the version you are submitting.

#6. Reviewer access

The reviewers will test your solution like an attacker would. If they cannot get in, they cannot pass you.

• A test org with the current package version installed and configured, sample data loaded.
• Working credentials for each user type the product supports (admin, standard user, community or guest where relevant).
• Credentials and test accounts for every external system in scope.
• Credentials checked the day you submit: not expired, not locked, MFA set up in a way the reviewer can complete.

#7. Documentation

• An architecture diagram showing data flows between Salesforce and any external service.
• Usage instructions: how to install, configure and exercise the main features.
• A list of the data your solution stores outside Salesforce, where, and how it is protected.
• Answers ready for the submission questionnaire, consistent with the diagram.

#8. Budget and timing

• Check the current Security Review fee and who pays it on Salesforce's partner documentation. Salesforce publishes it and it can change, so do not rely on a number from an old blog post.
• Plan for the review queue and for at least one round of fixes before you announce a listing date.

#Automating the checklist

Vulkro for Salesforce maps a scan of your project onto the review categories, the pre-submit checklist and the published checklist sections, and builds the submission packet as one self-contained HTML file:

vulkro-sf appexchange-report . -o readiness.html

If you already run Salesforce Code Analyzer, import its output. Vulkro drafts a false-positive justification for each row it has evidence for and writes the False Positives Whitelist:

sf code-analyzer run --output-file ca.json
vulkro-sf appexchange-report . --import-code-analyzer ca.json --fpw-out FPW.json -o readiness.html

Drafted justifications are never marked accepted: read each one before you upload it. The packet supports the Code Analyzer report the review requires; it does not replace it. To keep the verdict current on every pull request, add the gate to CI:

vulkro-sf appexchange-report . --format json --gate

The gate exits 1 when a pre-submit item fails. Our post on the readiness report walks through the verdict per section.

#FAQ

#What do I need to submit for the AgentExchange Security Review?

Your package (managed, if you ship one), a Salesforce Code Analyzer report, scan reports for any external endpoints, false-positive documentation, a configured test environment with credentials for each user type, and architecture and usage documentation. Check Salesforce's current submission guide for the exact list.

#How much is the AgentExchange Security Review fee?

Salesforce publishes the fee, and who pays it, in its partner documentation. It has changed over time, so check the current figure there before you plan a budget.

#Is there an antivirus check in the Security Review?

The review assesses your solution's security: code, configuration, integrations and how data is handled. It is not the same thing as the antivirus listings you may find on AgentExchange, which are products that scan files uploaded to Salesforce. If your app handles file uploads, document how it treats untrusted files.

Ready to check your package? Start a 14-day trial of Vulkro for Salesforce.