Clarify policy for revoking security advisory coverage

In the DrupalCode access tab present in every user profile, there is a checkmark that allows to disable the Git access, with a textarea for the message to send via email, which by default contains the following text.

@user_name,

Your access to git.drupalcode.org has been disabled because it is in violation of the Drupal Git Contributor Agreement & Repository Usage Policy at https://www.drupal.org/git-repository-usage-policy → . To seek reinstatement, post an explanation of what happened, and the steps you will take to correct the situation, to the Drupal.org site moderators issue queue ( https://www.drupal.org/docs/develop/git/setting-up-git-for-drupal/obtain... → ).

@admin_name

Drupal Git Contributor Agreement & Repository Usage Policy → is a documentation page for Drupal Git usage policies → , which is then a documentation guide listed in Setting up Git for Drupal and get GitLab access → .

Security Coverage does not have a link to Drupal Git Contributor Agreement & Repository Usage Policy because what reported in the latter page applies to everybody who can make commits on drupal.org repositories, not just people who apply to be able to opt projects into security advisory policy.
Security Coverage could have a page listing the pre-requisites for applying, which indeed includes having already set the Git access, which then includes also agreeing on the usage terms. (When people choose their Git username, they should see text which say that doing so they agree on some terms, including agreeing on committing PHP code only under GPL-v2 license.)

The most relevant part in that documentation page is probably Termination → , which says:

A user's account may be terminated without warning for reasons that include, but are not limited to:

1. violation of these TOS
2. violation of the Drupal Code of Conduct
3. violation of the DrupalCon Code of Conduct or Speaker Agreement
4. abuse of site resources or attempt to gain unauthorized entry to the site or site resources
5. use of service in a manner inconsistent with the purpose
6. a user's request for such termination
7. requirement of applicable law, regulation, court or governing agency order

if it is deemed unsupportable by the security team.

Is this related to the recent LLM discussions?

What would make a project or user unsupportable in light that the DST is primarily a clerical position? The only item I can think of is “excessive reports”?

Removing projects:
The security team is impacting site owners more than they are impacting the maintainers. The rules for this I would assume would be limited in order to protect site owners.

The Drupal CNA may still need to process a request for an advisory for unsupported projects, refuse it and process a MITRE dispute response (in other words the Drupal Security Team may create significantly more paperwork for itself rather than reducing the paperwork when they revoke a project).

Removing Vetted Users permissions:
I would assume the allowed reasons for this would be fairly limited, the only one I’ve seen published so far is when a user fails to respond to the security team leading to a module being marked unsupported the Security team may revoke the access (not sure which of the pages I saw that on).

Wouldn’t users generally be operating within the context of the permission? The Vetting permission is suppose to determine if a user is a “qualified” developer with a knowledge or secure PHP coding principals.

Any revocation of the user permission raises a question of “how did the user pass vetting originally (and how will the vetting process be updated to prevent it from reoccurring)”.

I do no longer see that part in my user profile, and I cannot see that part when editing other accounts.)

IIRC that was moved to GitLab as part of migration and GitLab now prompts on first use (or presumably whenever the policy inside GitLab is updated).

Any revocation of the user permission raises a question of “how did the user pass vetting originally (and how will the vetting process be updated to prevent it from reoccurring)”.

No, it does not.
Reviewing a single project does not give any guarantee the person understood how to write secure code which follows the Drupal coding standards and correctly uses the Drupal API. It eventually gives the guarantee the person was able to understand the given suggestions and eventually recognize when a suggested change was wrong. It does not even give the guarantee that person will not write modules using an LLM without reviewing what the LLM produces.

I'm going to use myself as an example.

I went through the Vetted Process in #3247119: [D9] S3FS SNS Metadata Update → .

Never during the process was I instructed to sign an agreement or even asked any of the following:

• Do you believe you know how to write secure Drupal PHP Code without being prompted?
• Did you personally write the code being reviewed?
• Do you agree to diligently review your commits for security concerns prior to submitting them to D.O. (
• Do you agree to work with the Security Team to resolve issues in modules you maintain? (one could argue this was implied somewhere, however it was never actually explicitly asked when applying for the role.)

During the process is D.O.'s chance to establish a 'contract' with the applicant.

Admittedly none of those questions actually stop me from doing so in the future, however the fact they were not asked I would contend is a an indicator how D.O. does not expect me to act in a special manner going forward, that D.O. failed to reaffirm its expectations of me at the time of role grant.

These are just examples based on some of the limited comments, and why I mention that each revocation should inherently trigger a process review, not every incident will identify a part of the process that can be improved, however those that do will help better define the program and (hopefully) reduce the number of incidents.

Never during the process was I instructed to sign an agreement or even asked any of the following:

It would be a moth point to ask to applicants if they believe to know how to write secure code. Everybody could say they believe they are able to write secure code; that would not mean they effectively know how to write secure code.

The purpose of those applications is reviewing a project, and that is done once. Everybody could diligently write the code for the application project, but then use an LLM to write a project, which is exactly what happened in a recent case.

The agreement was shown when a person set Git on drupal.org. People setting their Git were asked to commit only PHP code under GPLv2+ license. I cannot say what people see now that Git accounts are handled on GitLab side, but they should still see that agreement. If they do not see the agreement, something needs to be changed.

The existing policies about Git usage should make more visible, but the first step is making clear that setting up Git on drupal.org means also agreeing on the Git usage.

I created a new documentation page ( Pre-requisites for applying for the permission to opt into security advisory coverage → ), which contains the following text.

When you make commits in drupal.org repositories, you agree on the terms listed in Drupal Git Contributor Agreement & Repository Usage Policy → .

That is just a reminder for people who apply to be able to opt projects into security advisory policy. People who make commits on drupal.org repositories (which is possible without being able to opt projects into security advisory policy) are already agreeing on those terms, as that documentation page says.

This is a free service provided by the Drupal developers for the Drupal community. By using the repository you agree to the terms of services (see below).

People who set a Git account on drupal.org should see a short text saying to which terms they agree. Since Git accounts are now set from the GitLab instance, that needs to be changed on the GitLab side of drupal.org, if it is no longer happening.

(As side note, people can still change their Git username on drupal.org side, but on that form part there is no text about the repository usage policy.)

(one could argue this was implied somewhere, however it was never actually explicitly asked when applying for the role.)

When people set a project to be covered by the security advisory policy, they will see the following.

I will cooperate with the Drupal Security Team → as needed.

Read & understand the policy → ! Once you opt-in your project, you may not opt-out. Only the Security Team will be able to change this.

That is no longer visibile once the project has been covered by the security advisory policy.

The link shown there takes to Security advisory process and permissions policy → ; it is the same link given in the project page.

Back to the topic, does this issue suggest the list of cases where the permission to opt projects into security advisory coverage should be more explicit?
Should a short reminder about what agreed when using drupal.org Git repositories be shown, for example, on the DrupalCode access tab (which is probably not the tab people will visit more frequently, since it just allows them to change their Git username)?

Removing projects:
The security team is impacting site owners more than they are impacting the maintainers. The rules for this I would assume would be limited in order to protect site owners.

This depends on the usage of the project.

A newly published project which is full of security holes and has zero users will impact no site owners at all if it's withdrawn, and an increasing number of people if it's left published and starts to be used.

There's now a situation where this has happened. It was not a fast or easy decision to make. Several members of the security team expressed concern that this individual was not following the process. Ultimately Michael Hess and I made this decision as the 2 members of the Security Working Group, taking into perspective the feedback from members of the Security Team.

The modules affected do not have many users - it's possible (even likely) that all the users are development or test sites of the author.

There is a template of an email to send to the maintainer https://www.drupal.org/drupal-security-team/security-team-procedures/sec... →

Their access to opt future projects into Security Coverage was revoked.

Their projects that were opted into Security Coverage were all changed to "Not covered."

An advisory was issued for the one module where there is a reported security vulnerability https://www.drupal.org/sa-contrib-2025-057 →

The other projects did not get an advisory.

The private issues were closed as "can be public" and the reporter and maintainer have the option to copy them to the public.

A big area I'm not sure about is if we should issue a CVE for any privately reported issues while the project was covered. I think it could be appropriate to issue a CVE.

I hope we never have to do this again. If we do, this provides a starting point for what the process should look like.

Hi @greggles,

I'm the user you're referring to.

Can I copy the content of the original Security Advisory already validated by the Security Team, and also make public the details of the issues and the history of how they were reported? For example, I noticed one issue marked as an exception that wasn't even opened with clear replication steps in the summary (never confirmed by the reporter), and another one that was assigned to me more than 10 days after it was originally opened.

This entire process has left me very discouraged with the Security Team's approach. The disclosure only happened because I shared my module on Slack to gather community feedback — and instead of constructive collaboration, I was criticized for using AI. The same people then went on to report security issues.

Additionally, I've noticed some modules that have a Security Advisory in place but either don’t work at all or throw composer errors on install.

Kind regards,
Alberto

The documentation on making an issue public → includes advice to remove significant amounts of information. I do not think it would benefit you, nor the general public interest, to publish all the content in the issues.

Just to add a bit:

About: ...Their projects that were opted into Security Coverage were all changed to "Not covered."...

there is auto_translation module that has also post on drop times and is used by more than 250 sites ( agree not so much but an impact ) and now it become not covered by security from years that was without a security issue, that is not clear for site mainteners.

Best regards

Hi @greggles,

i don't want to have any benefit from what i do for the community, i just want to share for the benefit of everyone can understand how the process is or not is in some case structured.

Because if there is security team concern that was agreed to address in a way and then this was done after all the decision was changed in an unilateral way, without notice or nothing, i don't think this is healty community approach to follow, but for sure i'm wrong!

Best regards
Alberto