You developed your application and ‌passed the AppExchange Security review, and now your app is on the market. As you create great new features for your customers and make your solution more robust and complex, have the security concerns stopped? Definitely not! But there’s nothing to worry about. Salesforce is here to help you with the rest of your journey into making great software by providing tools, tips, and tricks for your ongoing development.

Tools for checking for vulnerabilities in your code

The tools you used during your security review must continue to be used throughout the development lifecycle of your application. These include:

  • The Checklist Builder will give you aspects of your solution that should be tested with each new release. 
  • You’ll gain much time and expertise by using the CLI scanner tool, Salesforce Code Analyzer, to find and mitigate vulnerabilities as they show up. (Note: bugs in the tool should be reported to the GitHub email.) There’s also a VS Code Beta version of the tool. And it can be used in conjunction with the retire.js engine for third-party code.
  • After you complete your package and determine that it’s ready to release, you must then run it against Checkmarx, which is provided to Partners in the Partner Security Portal. There you can schedule office hours with the Product Security team to get security best practices and ask implementation questions.
  • Don’t forget to check your endpoints with web app scans. Those could be ZAP, Burp (the most advanced on the market at the moment), or if you own the server you are scanning, Chimera (also located in the Partner Security Portal).

    Remember, tools do a good job of checking for standard programmatic vulnerabilities, so it’s of utmost importance that you run manual testing and keep a running list of false positives from those tools. These can be very valuable later on in your development.

    Best practices for continuous development

    Salesforce recommends that you think about security early during your software development lifecycle and engage the security team early in the process. Running your scans is a great starting point for maintaining a secure application, but it’s not all that you can do. Scanners give you a general idea of possible vulnerabilities, but they are limited, and some issues can only be spotted by manual testing of an application. That’s why your security team should be engaged from the design phase through the release of a new feature.

    We advise you to elect a security champion on your development team that could spearhead the initial conversation about security with developers. This champion can be any developer interested in security and familiar with the code base, and in this role, they would prepare the ground for a smooth collaboration with the security teams inside your organization.

    Establish repositories for the consistency of your code

    The consistency of your code plays a key role in the success of your development efforts. To maintain a secure code development lifecycle, you must think about security together with the design and implementation of code. Creating and maintaining secure code development practices involves creating a repository of code that has secure patterns. This is useful for maintaining the enforcement of sharing and CRUD/FLS, and to avoid things like injection attacks. Maintaining a code base of security best practices with reusable pieces of code saves developers time and ensures that vulnerabilities are not introduced by new patterns for solving known configuration issues. You should also check our developer documentation for updates to AppExchange policies and best practices.

    Threat modeling

    Threat modeling needs to be included in your development lifecycle design phase by your security team expert. This will help you gauge what are your most concerning pieces that could be entry points for vulnerabilities and attacks. Threat modeling is when you look at the architecture diagram and put on the attacker’s hat; you look at the flow of the application and identify what are the weak links and how they could be exploited. This is not a deep exercise — you should only map the concerning areas, so developers can think of solutions to prevent possible attacks.

    Check your code with scans

    Before releasing your code to your customers, it’s important to check that the code is secure and threat modeling was used to mitigate any possible vulnerabilities. This step is crucial if you want to protect your customers and maintain the security of your application. This is the time when you should engage the security team again to run a pen test of the feature.

    Don’t forget to check that your libraries are up to date. You can use a scanner to list your libraries in use throughout the application and check against a CVE database. You can use tools like the ones cited on the OWASP website, as well as retire.js, snyk.io. You can also refer to the Gartner guide for app security tools. The best practice at this point is to use SFCA with the retire.js engine for this. That’s a good start to identifying vulnerabilities in third-party JavaScript.

    Perform manual reviews

    In a pen test, the security team will review the code and test the front end of the application to try to exploit it by creating unforeseen actions and gaining unauthorized access to protected data based on the user type used during testing.

    Be sure to review the most common vulnerabilities that cause AppExchange security review failures. You can also refer to OWASP’s top 10 vulnerabilities for the part of your application that is external to Salesforce.

    Conclusion

    To uphold the value of trust, developers need to always take security measures and principles into consideration. This short guide provides a starting point for keeping security top of mind. Don’t forget to check the links provided and think about security at every step of your development process. We’ll provide more information on each of the points raised here in future posts.

    Resources

    About the author

    Richard Redditt is a Lead Security Review Operations Analyst on the AppExchange Ecosystem team. Over the past eight years, he’s helped many companies go through the security review process. He has spoken at Dreamforce and provided guidance and best practices to partners building for the AppExchange.

    Get the latest Salesforce Developer blog posts and podcast episodes via Slack or RSS.

    Add to Slack Subscribe to RSS