• David Esposito
  • NEWBIE
  • 30 Points
  • Member since 2011

  • Chatter
    Feed
  • 0
    Best Answers
  • 0
    Likes Received
  • 2
    Likes Given
  • 0
    Questions
  • 5
    Replies
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.
I sm trying to setup a continuous integration process for our org and I am running into an issue that I can find no solution for.  We have re-created all of our sandboxes and they now contain managed packages with Apex test failures (due to custom field validations, etc.).  I have found no way to run an Ant deployment to a sandbox and run only the tests that are NOT included in the managed packages (like you would get if you set runalltests=false, but deploy to a production org).  Every build we run to our integration sandbox fails because we get Apex failures from the managed packages, even though all of our tests pass.

Below is the path we are using to promote code (this process is not unique within our company or continuous integration lifecycle in general):
  1. Develop code in developer's sandbox.
  2. Check-in code to source control (for us it is Git/GitHub)
  3. Jenkins build job monitors commits to GitHub master branch and runs a deploy to Integration sandbox when changes are found.  All tests are run during build <deploy runalltests=true> (FAIL)
  4. The QA runs a manual Jenkins job to deploy master branch to QA sandbox.  All tests are run during build <deploy runalltests=true> (FAIL)
  5. After QA, the master branch is pushed to the Staging sandbox via Jenkins for user acceptance testing.  No tests are run <deploy runalltests=false> (PASS)
  6. Code is deployed to Production org using Jenkins build.  During this deployment process, runAllTests= false, so only the non-managed Apex test code gets executed <deploy runalltests=false> (PASS)
I'm sure other people have run into this, but is there any solution?
Hi,

Because of SSLv3 Poodle vulnerability, we have turned off SSLv3 support on our web server. This in term is causing Salesforce outbound messaging to fail.

Is there a work around with this from Salesforce end?

The outbound messaging processing issue was resolved once we turn SSLv3 back on our web server.

Ted Tsung
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.