Salesforce Security Review Checklist: How to Prepare and Pass

Managed 2GPs created from TRIAL Dev Hubs are not allowed

Managed 2GPs created from TRIAL Dev Hubs are not reviewable by security review team.

Ensure that your managed 2GP was created using the Dev Hub in your Partner Business Org (PBO).

Then, ensure that you have requested activation of your PBO so it can be moved from a TRIAL to an ACTIVE state.

You must log a case and select "Partner Community & AppExchange" for the Product and "Security Review" and ask for the activation.

Include web application scan results for third-party domains 

Your submission should include any web application scan results for the third-party (non-Salesforce) domains integrated with your app.

Add any non-Salesforce endpoints in your submission, included as composite environment(s), and/or in the remote site settings of your Salesforce test org. Example https://testapi.net/

Non-Salesforce domains/endpoints are considered in the scope of the security review if they are integrated with your Salesforce component in any way (e.g. if your app makes callouts to them, if they store any Salesforce data, or if they're used for other purposes such as authentication).

Provide scan results from one of approved web application scanning tools for any sites in scope of the review.

• Approved scanning tools include OWASP ZAP, Chimera, or Burp Suite.
• You must correct any high-severity issues detected for OWASP ZAP or Burp Suite.
• All issues labeled other than “Informational/Other” for Chimera must also be corrected.
• Provide clean scan results, or supplement the results with documentation that explains false positives.
• Alternatively, if no issues are detected, provide a screenshot of the endpoint scanned.

Provide any necessary authentication credentials, such as username/passwords or API keys, that the Security Review Team might need to test these external integrations.

Identity challenge is enabled workaround

Identity challenge is enabled on your org. As a workaround, you'll need to safelist Salesforce IP ranges.

You can spin up a new org with the IP addresses whitelisted and multi-factor authentication (MFA) disabled by following the steps in this link.

Alternatively, follow the steps below in your current org:

• Disable MFA with the steps below:
  1. Log into the org and go to the setup section.
  2. Search for “Session Settings” in the search bar on the top left.
  3. Go to session settings, then “Session Security Levels”
  4. Select Two-Factor Authentication from High Assurance and click remove.
  5. Press save at the bottom of the page.
• Safelist the Salesforce IP ranges and as well as the following ranges and addresses:
  • 13.108.0.0 - 13.111.255.255
  • 62.17.146.0 - 62.17.146.255
  • 85.222.134.0 - 85.222.134.255
  • 104.161.246.0 - 104.161.246.255
  • 182.71.125.154 - 182.71.125.155
  • 182.72.29.238 and 136.232.119.246

Enforce sharing rules in classes

Enforce sharing in your classes that access/modify salesforce standard/custom objects.

In order to avoid this vulnerability, you will need to declare "with sharing" these classes.

Note: Sharing is enforced or not in the class that perform the DML queries, if a class with sharing call another class "without sharing", and does the queries, the objects retrieved/modified will be without sharing enforcement.

Object (CRUD) and Field Level Security (FLS) are configured on profiles and permission sets and can be used to restrict access to standard and custom objects and individual fields. Force.com developers should design their applications to enforce the organization's CRUD and FLS settings on both standard and custom objects, and to gracefully degrade if a user's access has been restricted.

Some use cases where it might be acceptable to bypass CRUD/FLS are:

• For creating roll up summaries or aggregates that don’t directly expose the data
• Modifying custom objects or fields like logs or system metadata that shouldn’t be directly accessible to the user via CRUD/FLS
• Cases where granting direct access to the custom object creates a less secure security model.

Make sure to document these use cases as a part of your submission.

Sensitive Information in Debug

Revealing information in debug statements can help reveal potential attack vectors to an attacker. Debug statements can be invaluable for diagnosing issues in the functionality of an application, but they should not publicly disclose sensitive or overly detailed information (this includes PII, passwords, keys, and stack traces as error messages, among other things). 

No sensitive or PII data should be logged using the system.debug method.

Sharing Violation Vulnerability

The Force.com platform makes extensive use of data sharing rules. Each object can have unique permissions for which users and profiles can read, create, edit, and delete. These restrictions are enforced when using all standard controllers. When using a custom Apex class, the built-in profile permissions and field-level security restrictions are not respected during execution. The default behavior is that an apex class has the ability to read and update all data with the organization. Because these rules are not enforced, developers who use Apex must take care that they do not inadvertently expose sensitive data that would normally be hidden from users by profile-based permissions, field-level security, or organization-wide defaults. This is particularly true for Visualforce pages. Classes should explicitly declare with sharing when possible.

Conduct a Comprehensive Review

Conduct a comprehensive review of your application using the above as a guide to identify similar issues. 

Most cases when the security review starts their checks, they are unable to identify every instance of each type of vulnerability. As a result, their report will generally contain one example of each type of vulnerability found, and it will be up to you to check for other similar instances throughout your application.

Re-visit Security Resources. 

Visit the Salesforce Security Resources secure coding guidelines, tools, and training, and the ISV Security Review Resources to prepare for the AppExchange security review process.

In addition to manual testing, run automated scans with tools such as Salesforce Code Analyzer, OWASP ZAP, and Checkmarx.
Salesforce Code Analyzer - Overview & Guide
Web Application Scanner (ZAP)
Checkmarx - Security Code Scanner

Additional Resources:

More info here Security Guidelines for Apex and Visualforce Development

For more in-depth, interactive training materials, check out the new trailhead for ISV Security Review

You can keep up-to-date on alerts, participate in discussions, and post comments and questions in the Security Review Collaboration Group of the Partner Community.

Generate a submission checklist that is customized to your solution. Using the Security Review Submission Requirements Checklist Builder.

If you submitted a package version for review and failed with some feedback from the security team, make sure when you're ready to schedule follow-up Security Review consider those two important points.

1.  If you changed code that runs on the Salesforce platform, you must upload a new version of your managed package.
   • From the Publishing Console, click the 'Listings' tab.
   • Click on your listing.
   • Link your newly uploaded managed package version to your listing by clicking the green 'Select Package' button.
   • Go to the 'Packages' tab and click the 'Start Review' link next to the Security Review field on your newest version.
   • Go through the security review wizard and follow the normal submission process.
     
     
2.  If you fixed only code that runs externally to Salesforce, edit your existing security review submission information:
   • From the Publishing Console, click the 'Listings' tab if your app does not have any Salesforce package (otherwise, click on the 'Packages' tab).
   • Click on your listing in the 'Listings' tab or, if in the 'Packages' tab, scroll to your most recently submitted package version.
   • Click the "Edit Review" link (either in the 'APP' tab of the listing, or next to the package version in the 'Packages' tab). The link might also say "Submitted" instead of "Edit Review".
   • Go through the security review wizard and update any information that has changed.
   • It is required to Log a case and select "Partner Community & AppExchange" for the Product and "Security Review" for the Topic to let the Security Review Operations Team know you are re-submitting your product for review. Include your package name, ID, and version (or listing link) in the case description.

We're glad to share any helpful information and would recommend you knowing more about our impact to the release cycle in Salesforce

Schedule a demo to find out more about how Serpent can supercharge your Salesforce DevOps Strategy today! Serpent by Tekunda offers some excellent tools to help your DevOps teams, including built-in version control, continuous deployment and release systems, merge tools, and tons of different testing tools.