Insight

How to get Drupal.org Security Advisory Coverage for your module in 3 easy steps

Female with long brown hair is standing smiling in front of a metal wall with a hand on one hip
Rosemary Reilman Technology Lead

Overview

So you’ve finally submitted your module to Drupal.org but now you’re seeing that warning on your module page that it isn’t covered under the security advisory policy. How do you go about getting this pesky warning removed?

Warning message reads: This project is not covered by Drupal's security advisory policy

First thing: what is Drupal’s security advisory? This is a method where Drupal’s security team will be able to help advise you as a maintainer when there is a vulnerability in your code and steps to help mitigate this. Then, they will issue an announcement after a fix is in place to the Drupal community.

What also is important to know is that the security advisory coverage is on a per-user basis. This is something that our team sorta goofed on. We have multiple people working on projects together and realized halfway through our application that one person needed to be the one committing and fixing found issues. The people reviewing your application will be looking at your coding style and practices. After your module is covered, feel free to invite other maintainers, but during this process you will want to have only the applicant committing code.

 

Step 1: Create a Drupal.org module and get it release ready

You can create sandbox projects all day long (here’s a step by step on how) to test out your code and ideas but when you’re ready for an officially contributed project you’ll need to convert your sandbox projects into a full project. Before you do that, you’ll want to get your code into a release-ready state.

Make sure your module doesn’t already exist elsewhere. The Drupal community promotes collaboration over competition. This means if the functionality of your new module already exists, it’s preferred you submit a patch, take over an abandoned project and/or work with existing project maintainers to improve rather than having 12 different modules that do the exact same thing.

 

Step 2: Prepare for the application process.

Go through the security application checklist. There’s a lot outlined there. Some things to note:

  • Double check that you’ve written secure code. There are a slew of suggestions and best practices that are outlined here. 
  • Follow Drupal’s coding standards and best practices. These documents can be quite lengthy and tough to read through but it’s important to take a look to make sure your module is ready for release and it will speed up your submission process later. There are some additional tools that can help speed this process up. You can do this by submitting your project for a pareview and/or downloading and using the Coder module. This will outline warnings and some best practices that perhaps were missed. 
  • Review your code for common issues.

 

Step 3: Submit the application

One thing that I didn’t realize is that the application process is based on the user NOT necessarily the module. When submitting your application, you want to make sure that you are the one creating fixes and patching. First, create a new issue in the Drupal.org security advisory coverage applications queue. Follow the instructions for your application:

Screenshot reads: When submitting your project application, please remember to include the following with 5 bullet points listing those items
Include: name of your module or theme, a detailed description of what it does, a link to its project page, the Git instructions to clone and the intended Drupal core version in the title.

Other maintainers will look at your module and suggest fixes for them. Each time you apply a new patch or fix, you’ll want to update your project application issue to “Needs Review” status. This will signal to the different folks reviewing applications that this one is ready to review again. Remember, the same individual who submitted the application must make the fixes/patches.

In the meantime, you can review other applications to speed up your own. This is what the Drupal community calls “Review bonus”. Here’s some detailed instructions on how to complete this.

The whole process took me about a month to complete. Between our regular client work and waiting on enough individuals to review my application. After the application is approved, an individual from Drupal.org adds a tag to your Drupal.org profile. Then when you edit your module page, you’ll have the option to opt into security advisory coverage.

Security advisory coverage with the opt into security advisory radio button selected

Now any of our modules can be covered under Drupal.org Security Coverage and the big orange warning is no longer visible.

 

Interactive Knowledge has a few Drupal.org modules our team maintains for you to check out for your Drupal project: