Last week, it was brought to my attention that security reviews and audits are now asking ISVs to check for Field Level Security (FLS) and Object CRUD permissions prior to any DML outside of standard controllers.  

This is a fairly radical change that impacts a lot of managed package applications across the board. I and others have several concerns about this change in the security review process:

1. Why the sudden change in security review policy?  
   • None of the ISVs I have talked to were informed of the change prior to being either audited or submitting any apps for security review.  The only official documentation I can find on the change is a blurb in the Security Scanner help page here: http://security.force.com/security/tools/forcecom/scannerhelp.  
   • As ISVs, it would be greatly appreciated to have an official Security Review Guide, that is updated well in advance to when policy changes like this take place.  Some ISVs have several packages, others lots of customizations, and we all need time to prepare for the security review.
2. Has the security scanner been updated to enforce this rule yet?
   1. I have not run an app through the Security Review process recently, so I am curious if this rule has been implemented already in the security scanner. (http://security.force.com/security/tools/forcecom/scanner)
3. Why force FLS and CRUD checks on every DML transaction?
   • I am a fan of using standard controllers when necessary, but several apps, including one my company develops rely heavily on Custom Controllers.  In most cases where FLS comes into play, typically it's a simple fix of a profile permission or permission set that resolves the issue.  Instead, now, we have to implement FLS and CRUD checking prior to each DML transaction.  This adds complexity on top of existing DML calls.  
   • If need be, can the FLS and CRUD checking be done on a one-time run in an install script?
   • Does Salesforce have any plans of either adding FLS checking for custom controllers or adding methods to Apex for checking credentials similar to the Force.com EASPI library? (https://code.google.com/p/force-dot-com-esapi/)

Thanks, I look forward to hearing any feedback on this issue.

Last week, it was brought to my attention that security reviews and audits are now asking ISVs to check for Field Level Security (FLS) and Object CRUD permissions prior to any DML outside of standard controllers.  

This is a fairly radical change that impacts a lot of managed package applications across the board. I and others have several concerns about this change in the security review process:

1. Why the sudden change in security review policy?  
   • None of the ISVs I have talked to were informed of the change prior to being either audited or submitting any apps for security review.  The only official documentation I can find on the change is a blurb in the Security Scanner help page here: http://security.force.com/security/tools/forcecom/scannerhelp.  
   • As ISVs, it would be greatly appreciated to have an official Security Review Guide, that is updated well in advance to when policy changes like this take place.  Some ISVs have several packages, others lots of customizations, and we all need time to prepare for the security review.
2. Has the security scanner been updated to enforce this rule yet?
   1. I have not run an app through the Security Review process recently, so I am curious if this rule has been implemented already in the security scanner. (http://security.force.com/security/tools/forcecom/scanner)
3. Why force FLS and CRUD checks on every DML transaction?
   • I am a fan of using standard controllers when necessary, but several apps, including one my company develops rely heavily on Custom Controllers.  In most cases where FLS comes into play, typically it's a simple fix of a profile permission or permission set that resolves the issue.  Instead, now, we have to implement FLS and CRUD checking prior to each DML transaction.  This adds complexity on top of existing DML calls.  
   • If need be, can the FLS and CRUD checking be done on a one-time run in an install script?
   • Does Salesforce have any plans of either adding FLS checking for custom controllers or adding methods to Apex for checking credentials similar to the Force.com EASPI library? (https://code.google.com/p/force-dot-com-esapi/)

Thanks, I look forward to hearing any feedback on this issue.

This is an extension of the below thread...

 

Security Review - Am I Ready?  which has this text...

"We understand that our partners are of varying sizes and may not necessarily have all the organizational security processes and policies in place. As long as your application and network security is solid and you've address issues flagged by Checkmarx and Burp, you should be in good shape."

 

The Requirements Checklist provides a number of security points including specific application password handling (enforcing password expiration, etc). 

 

For a hosted application, I am curious how much these policies are enforced, or if they are largely recommendations.  We are a small team and have not yet implemented all of these points, but have locked down our application with other standard means.

 

If we focus on Burb and Checkmark security scans will we be pretty much ok? (I have another post about FLS being a concern since we are integrating only per the API).

 

I'd hate to spend the time and money waiting for the review only to be rejected for one of these points. Anyone have any insight?

 

Thanks!

 

Reilly