IMO, the question is perhaps too broad to be answered as asked. Are you looking for the published results of third party security audits? Do the other candidate applications have published 3rd party audits?
As far as Moodle's security, you can enforce password complexity and expiration if you use
LDAP for authentication, for instance, and you can deliver Moodle via SSL.
Those two features make Moodle much more secure then any system that lacks them (any system that contains user information and does not support SSL is not even close to secure).
A third thing Moodle has over most proprietary systems is that the code can be reviewed for security issues.
If you can't review the full source code of a system, then any security review you do is going to be based on what the vendor tells you, not on the actual source code. Depending on the vendor, these promises may not be made by the developers, but by other departments who may not even know what language the system is written in.
Since even the best developers are prone to missing problems in their own work, I'm not trying to imply that the security of a closed source app. may be inflated for marketing purposes, rather that 3rd party code review is a basic principle of security*. Of course Moodle has this to a great extent, as it is open source, anyone can look over the code, and many have. This may be even better than a single sourced 3rd party audit, as many expert eyes from various places have looked at the code.
Of course a very large part of security is based on local conditions: how your
server is setup, managed, and monitored. One could load a very secure application on a insecurely setup server, for instance. I would say the standard Moodle installation with default settings, set up to use SSL for all pages, no shell,
ftp or sftp access, and using LDAP authentication with enforced password complexity (at least 8 chars with a number, special character, and no dictionary words allowed), and expiration of passwords monthly, is a very secure application. More security could be found by expiring passwords weekly or daily, enforcing complex passwords, locking down PHP using open_basedir, using an enterprise server OS such as RHEL or SuseEnterprise with all the patches applied, using server monitoring software to actively report suspicious activity**, etc.
And if the stakes are high, then contracting with a 3rd party (such as Spikesource) for a full code level security audit for all the candidate applications you are considering (and dropping any applications that don't allow this) would (IMO, though I am not a lawyer, and this is not a SLA
) be reasonable.
It may also be reasonable to contract with a partner to ensure the server is set up to match the client's desired level of security.
*3rd party review is also a basic principle in other fields, for instance it is similar to peer review in the sciences.
** Looking for repeated failed calls to the same file, for instance, a hallmark of script kiddies looking for unpatched systems.
