The Security Review process is the final step every ISV must complete before they can bring their app to market on the AppExchange. Yet it’s not uncommon for ISVs to fail on their first attempt. For many, it can take 2 to 3 more tries to pass, delaying your time to market.
But Security Review doesn’t have to be a mystery! In this webinar, Salesforce Security Review Operation Analyst, Lubdha Dahale, joins CodeScience ISV Specialist, Jeremy Engler, and CodeScience Global Alliances Manager, Erin Murray, to de-mystify the Sec Rev process and provide actionable advice to help you succeed.
4. Who is CodeScience?
● Founding partner of the Salesforce Product
Development Organization (PDO) Program
● We partner with clients to build solutions
on the Salesforce AppExchange
● Named first Master PDO in 2017
● From design to build to implementation,
we support through the full lifecycle
7. How to Prep like a Pro
Security Review doesn’t happen in a day
8. Planning
1. Reframe how you approach it
a. Think of it as a security hardening sprint
2. ISV Partner Agreement
a. Get your ISV Agreement fully executed ASAP
3. Concurrent work
a. Start prepping your deliverables early
b. Don’t wait for the day you want to submit
c. Listing content
4. Organize your resources
a. Security Review folder
9. Prep
5. Code Scans & Code Review
a. If you need to scan an off-platform system, do it early
b. Search for every instance of issues that the code
scanners find
6. Compliance & Questionnaire
a. Prep this information beforehand
7. Documentation
a. Solution Architecture
b. Use Cases
8. Demo org
a. Use the trialforce template ID from Salesforce
b. The review team uses the Admin credentials
10. Submittal
9. Contact Info
a. Always use a distribution list
10. Credit Card (Only)
a. Must be able to charge $2700 now and $150/year
ongoing
11. Pre-Book Security Review Office Hours
a. Security review can take between 4-6 weeks
b. Ideally schedule a session 10 weeks after your app is
placed in queue
11. The SF Security Review Team
Meet the team who reviews your apps
15. Operations Check
● The Security Review Operations team reviews
each submission for completeness before
placing the SR queue
● Checks for things like:
○ Unrelated packages in the demo org
○ Incorrect version in the demo org
○ Not marked as “Lightning Ready”
○ Missing Use Case doc
○ Problem with scans or false positive docs
● Log a case after resolving any issues
● Should receive an email once in the SR queue
16. ● Always provide the Listing ID, Package ID and Version ID related to your case
● Correct credentials to Web environments, Native environment
(https://login.salesforce.com/)
● Clean scan reports (ZAP, Burp, Chimera or Checkmarx) or attach supporting
False-Positive document
● Hit “Start Review” button beside version ID on Publishing Console
Tips to avoid delays in Security Review
17. Why apps fail Security Review
● Issues with the package:
○ CRUD/FLS Enforcement
■ Not checking user’s perms to do what the
code does
■ #1 failure reason
○ Insecure Storage of Sensitive Data
○ Sensitive Information in Debug
● Issues with the client API/web UI:
○ Password enumeration: shows if username is correct
○ TLS/SSL Configuration
○ XSS Vulnerabilities
● Office Hours
○ Book early
○ Link
19. Example Security Findings Report
Note the bolded point at
the top of the report:
The report starts with a
table of contents
summarizing the types
of vulnerabilities found.
21. Have a Plan
● Triage
○ Track each issue like you do bugs
○ Is the issue a False Positive?
○ Identify where the issue/fix resides
○ Assign an Owner and LOE
● Up to your project and deadlines as to
whether “hero effort” is required
● Agree on communication cadence to
management
22. Address the Issues
● Legitimate issues need to be fixed, either in the
package or off-platform
● Not a comprehensive list
○ Need to check for other instances of issues in
the code
● Off-platform fixes are the biggest risk/effort
○ Must schedule that work alongside your
existing product roadmap
● Issues in the package will require a new upload
○ Post-SR development in the master branch
can hamper SR fixes
○ Keep new dev in a new, non-master branch
until SR is passed
●
23. Resubmit
● Update
○ Code Scans
○ False positive documentation
○ Demo org
● In the Partner Community:
○ Link the new package version to
the listing
○ Submit the new package version
with all required docs &
information
○ Log a case under “Security
Review” with the Package ID
● Alert your PAM
25. For More Information
● OWASP Top 10 Security Issues list
● Build Secure Apps Trailhead
● Partner Security Portal
● Prevent Common Violations of Secure Coding Guidelines
● Security Review Office Hours
27. CodeScience Pre-Security Review Service
● ISVs who approach Security Review with a solid plan and partner with some expert
assistance typically pass Sec Rev sooner and get to market faster
● Salesforce recently asked CodeScience to help ISVs plan for Security Review and the
CodeScience Pre-Security Review Service is the result!
● Reach out to us at info@codescience.com to start your Pre-Security Review, or visit
https://learn.codescience.com/pre-security-review.html for more information
28. Please Submit Your Questions via Q&A
What would you like to see more of in our
next Security Review webinar?
Let us know in the chat!
Open Q&A