mjhjmtu

I would like to use a Drupal 7 module that is "not covered by Drupal’s security advisory policy", specifically the Conditional Fields module.

It would allow me to do exactly what I need. It looks like this module is pretty actively used and maintained but I am not sure how worried I should be about of using a module that I won't get updates about if any security issue should arise.

Any advice? Is coding something like (using hook_form_alter and states) this myself a safer approach?

According to the Security advisory process and permissions policy, modules that have an alpha, beta, or rc (relase candidate) status are not covered by this policy, and security advisories will not be reported for these projects. At the time of writing, Conditional Fields has recommended releases for Drupal 7 and 8 that are both in "alpha" stage. Even without security advisories, you can still choose to be notified when the module is updated.

Since module releases and their status are arbitrarily assigned by project maintainers, only you can judge whether you should use a module marked as not being covered by Drupal’s security advisory policy. One maintainer's "alpha" module, would be a "1.0" version to another maintainer.

You should examine the maintainer's credibility, history on Drupal.org, the project's popularity, and the speed at which issues are resolved or responded to. Many popular and public sites do make use of "beta" or other modules.

Coding your own module to duplicate the functionality of a module that already exists seems more likely to introduce security vulnerabilities that can potentially only be diagnosed or fixed by one person: you. Using an "alpha" module with a competent maintainer and an active community of users seems far more advisable.

Be careful in "only" using the security advisory. Instead you may want to consider many more criteria to help you make decissions. As I documented in (what I call) maintenance scorecards. In that case they relate to charting modules, but you can apply them for any set of modules of course.

These are IMO the criteria you should also consider:

• Nr of open bugs


• No RTBC'd items


• Last commits


• Community docu


• Support 2 core releases


• DEV release for D8


• Nr of Committers


• SimpleTests or Unit Tests


• Automated testing enabled


• Downloads / installs ratio


• Contributing users in commits