An ISV customer of mine has a Managed Package in the AppExchange for many years now. He recently was asked to resubmit for Security Review and is now wondering what to expect and how to best plan and prepare that work.

From the official documents, this looks like a normal initial submission but I wondered if there are differences and pitfalls that others could prevent us from stumbling over.

  1. Did you successfully go through such a Resubmission of an established app?
  2. What was the biggest issue or challenge in that process?
  3. Was the amount of work bigger or smaller compared to the initial submission?
  4. Is Salesforce also expecting User Guide and Architectural documentation according to the now extended scope and functionality of the app?
  5. How detailed does Salesforce scan external Heroku / GCP components? Just Endpoint scans with Chimera?
  6. Do you recommend consulting Security Office Hours even with no specific questions?

4 Answers 4


I've gone through a resubmission last year. To be fair, the process was fairly straightforward (exactly the same as a normal submission) - but that's because I kept the resubmission in mind after my initial release.

To answer your questions:

  1. Yes

  2. Reviewing old code that hasn't been touched in years. It's easy to prepare when you remember the entire application in your head - less so when you wrote something 2 years ago and never looked at it since.

  3. Definitely less work than my initial submission. I relied primarily on the code scanner report to focus my attention. With that being said, there were some issues that I detected (that the review team did not, btw) that were not found in the code scanner.

  4. I only submitted an architectural document, without a user guide. I did provide testing instructions in the submission though, and hints and tips in the app data (click me, drag me, right-click me, etc).

  5. Their scans are detailed. If you have anything on Heroku, you MUST use a CDN to comply with all the requirements. It costs additional money per month, but that's the only way I was able to comply with all their security requirements. I failed one review because I gave a different error message when trying to log in with a wrong password as opposed to with a username that doesn't exist. This, they rightly said, can be used to farm email addresses.

Another recommendation, if you're using express on Heroku, is to use Helmet and some security-related headers. Here's what I ended up using:

res.set('Access-Control-Allow-Origin', 'https://       .isimio.com');
res.set("Content-Security-Policy", "default-src 'self'; frame-ancestors 'none'; form-action 'self';");
res.set("Cache-Control", "no-cache, no-store, must-revalidate");
res.set("Pragma", "no-cache");
res.set("X-Content-Type-Options", "nosniff");
res.set("Strict-Transport-Security", "max-age=31536000");
   crossOriginResourcePolicy: false,
  1. I haven't done this, but it probably won't hurt - especially if you haven't gone through a security review yourself before.
  1. Yes, I did. Last year.

    • Salami Tactics, Manual Security Review only points to one issue and you need the tooling to detect all of them. Especially important for JS libraries
    • Checkmarx reports were not consistent.
  2. Less effort than first submission since we could rely on some available documents

  3. In our case, we pointed them to our public documentation

  4. No experience

  5. Should you fail 3 times, Security Office hours become mandatory. We had to wait 6 weeks for a slot.

  1. yes
  2. 3rd party integrations
  3. bigger
  4. yes, it should match the current scope which you are submitting
  5. like during 1st submission
  6. no, but it sounds Heroku / GCP components you may clarify the expectations

The best thing about resubmission is that failing it does not really hurt. Your app anyway is on AppExchange so it’s not time-sensitive to pass resubmission.

Of course, better to aim for getting it done right, but if the codebase is big and ugly (e.g during past years nobody really cared about SR requirements) it may be difficult.

In other words: if a full codebase was developed by your team you should take responsibility for the output, but if the codebase has been created by another vendor you should firstly clarify expectations that this process may be painful and time-consuming (and use it as an opportunity to reduce technical debt by your team, you can request Salesforce for extra time before making the resubmission)

  • Could you please add a few more details on why and where 3rd Party integrations were an issue and why the resubmission work effort was bigger (although you had all the docs from the initial one)? Jun 14, 2022 at 8:02
  • 1
    the size of the code increased a lot compared to the 1st submission, so preparations of the documentation, cleaning the whole code base, reviewing it, etc was more complex compared to the historical MVP. The issue with integrations was the fact, that we had a few APIs added to the package which was not owned by our company: it's the same when you add some 3rd party to the first submission but in living project it will be more difficult to refactor solution if needed, as already you have customers using these (potentially insecure) APIs/features/etc Jun 14, 2022 at 10:23

Jumping in to reinforce other replies.

This is based on our core AppExchange package which I have personally resubmitted on two occasions and that was last resubmitted December 2021 IIRC.

  1. Yes, we have successfully gone through many resubmissions, with a varying number of iterations each time (never a first time pass in my experience).
  2. The reason for repeated attempts is that Salesforce evolves its security requirements over time and resubmissions are periodic.
  3. The amount of work depends entirely on how well you consider security in your SDLC and how far Salesforce has moved the goalposts since last submission. Some resubmissions have been a really big task, as we faced in 2018, but others much smaller, as we had most recently.
  4. Salesforce requires the architecture document every time, and it should be up-to-date with any major changes since last time. A user guide is not required, but they need basic info about usage so if you have a generic user guide that is appropriate for use, that will save you time writing specific instructions.
  5. No comment.
  6. No. You should ensure you read the documentation again to look out for changes in the process. Otherwise it is as per CSzK's point.

Use of Checkmarx, PMD and Zap (for mobile app REST API scanning) during standard SDLC will make resubmissions smoother. We even had to provide a copy of our mobile app source, which grated for me, but you do what you have to.

NB: you have 60 days to resubmit and ideally pass. If you have to wait for office hours you need to communicate this via the case raised for resubmission in order to avoid having your AppExchange listing set private by Salesforce. Do not delay and do not forget to request extension of the deadline, otherwise you can find your listing disappears!

  • Are you saying a resubmission never works the first time? Or any Reviews even initial ones? And why do you think that? Jun 14, 2022 at 19:38
  • I cannot say it is never, for any partner, but our experience is that we have always failed on first submission and resubmission. In 2018 it took 4 goes to get through. Basically because of two issues: 1. Taking our eye off the security ball and 2. Moved goalposts (additional rules). Most recently it was again moved goalposts.
    – Phil W
    Jun 14, 2022 at 20:53

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .