If you passed the AgentExchange (formerly AppExchange) Security Review a few years ago, the process you remember is not the one you will go through next. Three things changed: who runs the dynamic scan, how often you are reviewed, and what counts as part of your solution now that agents ship inside packages.
This post covers only what changed. For the full pre-submission list, see our Security Review checklist, and for the code issues reviewers find most, see what fails, and how to pass the first time.
1. The hosted dynamic scanner is gone: you bring your own
Salesforce used to run a hosted dynamic (DAST) scanner, Chimera, against the external web applications and APIs in a submission. Salesforce stopped supporting it on 16 June 2025. Partners now run the dynamic scan themselves, with a scanner of their choice, and attach the full report together with documentation for any findings they consider false positives. For endpoints you do not own, Salesforce's guidance names an open-source web scanner and a commercial one you license yourself.
What this means in practice:
- List every endpoint in scope. Every external web app, API or service your solution calls, or that calls into Salesforce. Anything missing from the list is something nobody scanned.
- Scan the environment the reviewer will see, not a local build, and keep the raw report.
- Write the false-positive notes as you go. A short paragraph per finding that explains why it is not exploitable, with a pointer to the configuration or code. Our post on the false-positive document shows a format reviewers can check quickly.
The work did not disappear when the hosted scanner did. It moved onto your calendar.
2. Reviews are yearly, and new versions need an attestation
Salesforce now says listed solutions are typically reviewed for security about once a year, and that its Product Security team can ask for a review at any time. Between reviews, a new package version does not go through a full review: you complete an attestation in the Partner Console instead.
Two consequences:
- Passing once is not the finish line. Put the next re-review on the calendar the day you pass, and keep your scan reports and false-positive notes current so the next one starts from evidence, not from memory.
- An attestation is a statement you sign. Each release you attest to should have been scanned and fixed to the same standard as the version that passed. That is far easier as part of every build than as a scramble before a review.
The cost of getting it wrong has not changed: on a paid solution the fee applies to the initial submission and to every later attempt, and each attempt means weeks in the queue.
3. Agents are part of your solution now
In April 2026 Salesforce brought AppExchange, the Slack Marketplace and the Agentforce ecosystem together as AgentExchange, and the Security Review applies to every listing. If your package now ships Agentforce actions, prompt templates or MCP connections, those are part of what is reviewed.
An agent action is an entry point like any @AuraEnabled method, with one difference: the caller is a model acting on a user's behalf, and the input can come from a prompt or a record the user did not write. Check each action the same way you would check a controller:
- It enforces the running user's object and field permissions, so the agent can never read more than the user could directly.
- It runs in a class that declares its sharing.
- Any dynamic query built from agent input uses bind variables.
- Any callout goes through a Named Credential to an endpoint you control, and that endpoint is in your dynamic-scan scope from section 1.
We covered why tools an agent can call deserve this treatment in agent tools are entry points.
What to do this quarter
- Write down every external endpoint, and scan each one with your own scanner before your next submission or re-review.
- Run Salesforce Code Analyzer v5 with the AppExchange and Recommended:Security rule selectors, and turn every open finding into a fix or a written justification.
- Add every agent action to the list of entry points you test as a non-admin user with only your package's permission set.
- Put your re-review date on the calendar, and scan every release you attest to.
Where Vulkro for Salesforce fits
Vulkro for Salesforce scans your package on your own machine, so your code never leaves it. It traces each finding from the entry point, including @AuraEnabled methods and agent actions, to the data it reaches, and labels it Proven, Unproven or Not checked. The readiness report gives a READY or GAPS checklist you can attach next to your Code Analyzer output, and you can run it on every release you attest to. Start a 14-day trial, or talk to us about your next submission.
Sources
- Salesforce Trailhead, Guide to Submitting Your Solution for Security Review: fee per attempt, yearly review, attestations for new versions (checked 5 November 2026).
- Salesforce Partner Security Portal, Source Scanner help: hosted DAST support ended 16 June 2025; partners choose their own scanner and submit full reports with false-positive documentation (checked 5 November 2026).
- Salesforce ISVforce guide, Scan your code with Code Analyzer.