📢 Attention Salesforce Certified Trailblazers! Maintain your credentials and link your Trailhead and Webassessor accounts by December 6th. Learn more.
close
•
Start tracking your progress
Trailhead Home
Trailhead Home

Complete the Review Process and List Your App

Learning Objectives

After completing this unit, you’ll be able to:

  • Describe how the Product Security team reports vulnerabilities.
  • Explain how to resubmit your app for review after fixing security issues.
  • List the steps to take to launch your app after it’s approved.

Face the Facts

You just got an email from the Salesforce security team. Your product has been reviewed. You’ve been waiting for weeks for this email, so you’re excited. But in a way, you dread opening it: What if you didn’t pass?

If your product doesn’t pass its first security review, it’s in good company. Half of all submitted offerings fail their first security review. Security isn’t easy! If it were, we wouldn’t actually need the security review process.

Let’s explore both possible security review outcomes—not passing, and passing—since you’re likely to encounter both as you develop your products.

Keep Your Chin Up

Contents

Because we’ve been talking about “passing” the security review, you might think of the security review as an exam that you pass or fail. But it’s not really so black and white. Think of the review as feedback from the security team—feedback that helps you improve the quality of your product and increases your chances of a successful launch.

If your product doesn’t pass its security review, you get this feedback as a report that lists the vulnerabilities that the security team found. The email you receive also has detailed instructions on how to fix these vulnerabilities.

Your security report

The nice thing about the report is that it gives you specific descriptions of the issues it finds. It provides a hyperlinked table of contents at the top of the report that looks something like this:

  1. SOQL Injection Vulnerability...
  2. Sensitive Information in Debug Vulnerability...
  3. Information Disclosure Vulnerability...
  4. CRUD/FLS Enforcement Vulnerability...

Each entry is a type of security vulnerability. Beneath each entry is the name of the component where the vulnerability was discovered. Below the table of contents are detailed descriptions of each vulnerability. Clicking an entry takes you to the corresponding description.

We Go Wide. You Go Deep

The report lists every kind of vulnerability found in your product, but not every instance. If you see a SOQL injection vulnerability on the list, review all your code—not solely the component mentioned—for SOQL injection opportunities.

We can also alert you to the types of vulnerabilities we exploited to break into your app, but we can’t make an exhaustive list. Your team has a lot more expertise in your code base anyway. So you can find these vulnerabilities faster than we can once you know that they exist.

Testing Isn’t Perfect

We can only spend a limited amount of time finding vulnerabilities in your product. Sometimes when an app is re-reviewed, we find some new kinds of vulnerabilities we didn’t see the first time. Testing isn’t comprehensive, either in width or depth. So when you review your code base, keep your eyes peeled for all kinds of vulnerabilities, even those not in the report.

Keep calm and fix your code

As you fix the vulnerabilities, don’t forget to reuse scanners and adversarial testing on your product, just as you did before the review. They help prevent new vulnerabilities from sneaking into your code.

Review Your Practices as Well as Your Code

Sit down for a chat with your team to process the results of the security review. Here are some questions you can use to start a conversation:

  • How did these vulnerabilities slip through your own security reviews?
  • Were there things you could have done to find them sooner?
  • Would more testing help?
  • Would more staffing or more time help?
  • Would more Salesforce security training help?
  • Did you learn anything from the security review that can be applied to your development process?

There is no perfect strategy for achieving security—it takes dedication and determination. But you can always improve your overall strategy by incorporating what you learn from each security review.

And of course, your success is our success! If you need guidance in fixing vulnerabilities or examining your processes, contact your partner account manager or technical evangelist. If you need technical security advice, our Trust Team holds office hours.

Rinse, Repeat

You’ve fixed your app and revamped your development process. You can’t believe how much more secure everything is, and you can’t wait for a security review rematch. Do your worst, Salesforce Product Security team!

The security team never backs down from a challenge. You need only get their attention. How you do that depends on whether you fixed code that runs on the Salesforce platform.

If you changed code that runs on the Salesforce platform, you must upload a new version of your managed package. If you also made changes external to the package, add that information when you go through the wizard:

  1. From the Publishing Console, click the Listings tab.
  2. Click your listing.
  3. Upload your new managed package to your listing by clicking Change Packages.
  4. Click Start Review next to the Security Review field on your package.
  5. Go through the security review wizard and follow the normal submission process.

If you fixed only code that runs externally to Salesforce, edit your existing security review submission information:

  1. From the Publishing Console, click the Listings tab.
  2. Click your listing.
  3. Click Edit Review next to the Security Review field on your package.
  4. Go through the security review wizard and update any information that has changed.
  5. Log a case in the Partner Community to let the Product Security team know you are resubmitting your product for review. Include your package name, ID, and version in the comments.

Either way, you don’t have to pay another setup fee. As long as your package ID and your namespace don’t change, we consider your resubmission as the same offering as before. And as in the first round, the security review process takes 6 to 8 weeks.

Ship It

When your product passes its security review, you get a nice email saying that it is approved. You’ve done it! That wasn’t so bad, was it? Congratulate everyone on your team and enjoy the moment. Celebrate in your favorite way.

When that magic moment passes, it’s time to launch your product. The security review email gives you an idea of your next steps in this process. Finalize your listing in the Publishing Console and get your marketing team ready.

We can help with your launch. Your partner account manager can work with you, and the Trailblazer Checklist step 10 has several great resources on selling your products on AppExchange.

Then sit back and watch your numbers grow.

Resources