Not a problem. Regarding your follow up questions:
There are several stages within both our general development cycle and release process which aim to proactively identify any implementation problems or bugs. These aren't specifically security threat based (such as an automated threat analysis tool), but checking for security risks does form part of their scope, so where possible we can identify and rectify any issues prior to them being released. Detailed information about the development process is covered in the process documentation
, but here's an outline of the relevant stages where security issues will ideally be proactively identified:
- During development of all issues, the assignee will write manual testing instructions, automated testing, and where applicable, both.
- Automated and manual testing is run at various stages in the process, which confirms any new automated testing is successful, any additions do not break existing functionality, and changes are working as intended. Major releases also go through a manual QA testing cycle to ensure features are still working as expected in the latest version. (The testing documentation has more details on each of those if you'd like to learn more).
- A peer reviewer (another developer) will then check the code and testing for errors. In addition to things like code syntax and structure, they are also looking for logic issues, missing test cases and so on, including anything they identify as a security risk (such as missing permissions checks, missing test cases etc). They will usually also perform some testing of the changes.
- The next stage is integration review, which is performed by a senior development team. This also includes reviewing (by a highly experienced Moodle developer), with the addition of looking at its impact on Moodle as a whole, and confirming no conflicts with other code also being integrated.
- Finally, the changes are passed to a testing team (or further developer), who perform any manual testing included on the issue, checking everything is working as expected in all affected versions.
Issues won't progress to the next phase of the above until the current one has been signed off by the relevant reviewer/tester.
In terms of testing security fixes themselves, these are performed twice; once when the patch is first completed, and again in the week prior to release when being integrated into the final build, to ensure the fix still works as intended, and no side effects are identified.
You are correct, the HQ MoodleCloud team take care of patching and upgrades within MoodleCloud. They don't specifically publish a list of the patches that have been applied, so you won't be able to confirm which issues have been manually patched prior to an upgrade, but as a site admin you would have access to view the current Moodle version, so looking at the previously mentioned publication of security fixes, you can see which fixes were applied in the current version.
Since MoodleCloud is a production environment, I wouldn't recommend running a vulnerability assessment there, since it may inadvertently impact other users of the service. In the first instance, if you would like to perform a VA on the Moodle LMS itself, I'd suggest downloading
a copy (or cloning with git
), and installing it on your own test servers (or local machine) and assessing there. However, if there is anything you have in mind that would specifically require testing on MoodleCloud, before you do so, please send those details to the security inbox (firstname.lastname@example.org), and I will forward them to the relevant manager to review and get in touch with you directly.
Also keep in mind if you do run a VA on your own instance of Moodle, that generally automated testing has produced a lot of false positive results in Moodle, so the results will need some manual analysis (I've posted some information about this and some common false positives you may find helpful in another forum post
). If you do have any specific concerns within the results, please also don't hesitate to send me the examples to email@example.com, and we can review and discuss them further.