As most ISVs are aware, all partners who wish to list their apps publicly on the AppExchange are required to pass a rigorous Security Review process to provide trust to the community of users who may end up using their solution. Salesforce recently added a new requirement to the Security Review process: ISVs must now include a Solution Architecture document as part of their submission.
This blog post will provide an overview of this new requirement, along with a useful Solution Architecture template to help you provide the right information about your solution architecture when you submit your app for review.
Evolution of Security Review requirements
The addition of new requirements to the Security Review process is nothing new; the process has evolved over the years. Originally, ISVs had to submit code scans and false positive documents, then were asked to provide a Use Case document (which was based on a CodeScience best practice of always doing so), and now we have a new required document which was added with the update of the Security Review Wizard, the Solution Architecture document.
This document takes the place of the Technical Review call which ISVs used to hold with their Partner Account Manager (PAM) and their Technical Evangelist (TE). The purpose of the call was to give the TE an opportunity to learn about the partner’s proposed solution and architecture while allowing them to ask questions about the solution, look for red flags in the design, and suggest alternatives where appropriate. It was a great opportunity to validate the proposed solution before committing to it and we would usually get some good feedback from these calls, if not at least validation of our approach.
In an effort to streamline the process, the Salesforce ISV team has removed the Technical Review call and replaced it with the Solution Architecture document requirement. With that said, this new requirement doesn’t come with a lot of guidance, so let’s take a look at what they’re asking of you.
A closer look at the Solution Architecture requirement
The tooltip in the submission wizard states:
Share documents that display detailed information flow, authentication, encryption on data transfer, and data touchpoints. Also provide basic solution usage instructions to help orient the security review team.
That’s really all the instructions ISVs are given, so you’re given a lot of leeway in how you respond. Because of our nature as a PDO, we submit multiple packages over time and so it was worth it to create a template for our build teams to use so that they’re not all solving the same problem ten different ways.
The CodeScience Solution Architecture template
Our approach was to ask ourselves what we thought an ISV TE would want to know about the packaged solution. How does it authenticate? Does it store SF credentials off-site? How does it handle data at volumes? Does it have a retry mechanism for critical data operations? What are the expected data volumes and how will you address the upper end of that range?
We then put together a thorough template that would help answer these questions in an organized way, with examples from various projects we’ve worked on, and we’d like to share this resource with you! So far it’s been working well on our projects, as each Product Owner can use the parts that are relevant and edit out the rest.
While our friends on the AppExchange Security Review Operations team have given this template the thumbs up, it’s up to you to make sure that your Solution Architecture document tells the full technical story of your end-to-end solution.
Hopefully this template can help lend some clarity to an otherwise ambiguous requirement for Security Review. So go get those Checkmarx scans fired up and get ready to submit!