How to get vetted role or green shield for module

Aim

The aim of this is to obtain a new Drupal role (vetted) after verifying what the user who applies understands about writing secure code that follows the Drupal coding standards and correctly uses the Drupal APIs, following the Drupal best practices.

While the application requires users to choose a project they created and for which they committed the code, the focus of the application isn’t the project, but the users who apply, will get a new Drupal role necessary to be able to opt into security coverage for projects they are owner or maintainer in.

Preparation

Before entering the project application process, the following conditions must be met.

• There isn’t another, still open, application from the same user. This includes postponed applications.
• The user who applies cannot yet opt for projects into security advisory coverage.
• The user who applies has committed code in the project used for the application (not an issue fork created to fix an issue in an existing project). Those commits must be (preferably) the only ones done in the branch used for the application, or be most of the commits for that branch.
• The account used to create the application (and to commit code in the project) isn’t a shared account. Shared accounts aren’t allowed to commit code on Drupal.org repositories.
• There is sufficient PHP code to see what the user who created the application understands of Drupal coding standards, Drupal APIs, and Drupal best practices; a project that only implements a hook or two to, for example, add a library (CSS or JavaScript) to most or all the Drupal pages doesn’t contain sufficient PHP code for these applications.

Application process

1. Obtain basic Git access and create a project for your code.
2. Get your project into a state you feel is release-ready; ideally, you would commit the project early and have a track record of several weeks/months of commits so that application reviewers can get an idea of your development and maintenance style.
3. Have a look at the security advisory coverage applications checklist and try to resolve the common issues.
4. Once ready, create a new issue in the Drupal.org security advisory coverage applications queue. Fill out the issue form.
   
   • Title: The branch name and the project name (For example, for the 2.0.x branch of the project Email Octopus, then the title would be [2.0.x] Email Octopus.)
   • Category: Task
   • Status: Needs review or, if you want reviewers to wait before reviewing the project, Active
   • Component: Select the option that better describes the type of project used for the application
   • Description
     1. Write a detailed description of what your project does, including how it is different from other, similar, projects (if applicable)
     2. For themes, a screenshot is also helpful
     3. Add the link to the project page
     4. Add the list of links to reviews of other project applications that you did 
5. Reviewers will then examine the project files and provide feedback over the coming days/weeks (again see Review process for security advisory coverage: What to expect). You can always ask what to do, if you don’t understand it in first time.
6. As the application process is fully volunteer-driven, many of our most active reviewers may use the review bonus program to prioritize which applications they review. This program gives priority to those who are also helping to review other applications. Participation is not mandatory, but it does provide a significant fast track through the application process. Due to limited resources, it could otherwise take a number of weeks between reviews of your own application. To participate in the Review Bonus program, review three other applications and reference them in your own application.
7. Once given the sign-off, you will be able to opt all your projects into security advisory coverage. Once this comes into place, there is no need to submit another application for review, since (at this stage) you are considered a trusted contributor.
   

What next steps are?

Once the application is fixed, and you have the role that allows you to opt projects into security advisory coverage, you can edit the project to change the value assigned to the Security advisory coverage field.

You will be able to opt into security advisory coverage for every project you create, including the ones created in the past.

Keeping in mind these pointers.

1. Once the project opts for security advisory, it can’t be undone, so please be careful while doing that, but you can always mark your releases as recommended(provides green shield) or not.
2. Use correct branch naming and tags versioning.
3. Before providing any stable release, clear the project issue queue, so your release may not have already reported bugs.
4. Providing green shield stable release builds more trust for the end user in terms of security and code. So make sure you first have dev, beta, and alpha releases. Then provide the stable release.

Once you are clear with all the processes and best practices, you can also start reviewing the other project applications and suggest feedback and can get credit for that issue.

Thanks, Hope this helps.