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

Comments #11 and #12 offer good suggestions about places to make things more visible.

And yes - GitLab does present the git terms of service when they need to accept that - but it's a good point that it can be quite a long time since the last time someone looked at it.

We can probably slightly update the language on: https://www.drupal.org/drupal-security-team/security-advisory-process-an... → (or a related page) with a very simple statement about the security team's discretion to revoke based on the requirement for co-operation.

Disclosure: I was one of the reporters of the vulnerabilities, I know first hand what happened on multiple issues however I can not assert that I am aware of 100% of issues that may have been opened. I am listed on the Unsupported SA by my request (with primary intention of there being public record that yes I did indeed raise concerns through the private tracker). I understand why the DST would want to revoke the users opt-in permission, however I do not agree with how they handled it given the currently documented policies.

Do I trust any code this individual writes, no, would I recommend site owners consider uninstall any code this individual maintains, yes, Do I wonder how this user made it through the first opt-in review process, yes, do I feel this indicates flaws in the opt-in process, yes, do I believe D.O./DST should be removing users without them being given a a policy to refer to, no. This issue existing is evidence that D.O. was not ready for this. In the future I encourage D.O. to write its policies before the action is taken, not after.

In fairness to the DST this incident did reveal a set of scenarios that I had not yet encountered when dealing with maintainers, it was certainly inevitable that some day I would. When the DST did being to involve themselves in more minute details of the fixes they started wrangling the code owner back in, however by that time much of the "damage" was already done.

From the SA:

The project maintainer did not follow the terms and conditions for hosting projects on drupal.org that are opted into security coverage, so the module is losing its security coverage

I want to say this is technically valid to a single term, and that have seen other modules do similar on my own reports and other cases where the DST has admitted a module owner failed to adhere to policies. I will suggest that the DST had some involvement in some of these concerns as they did not provide corrections sooner in some cases. Factor in some communications faults and this was a recipe for disaster that has been growing for some time.

Over in 📌 Bulk LLM-generated module publishing by bigbabert Active it was described as

While @bigbabert has co-operated in the sense of replying on issues, the manner in which they're doing so constitutes malicious compliance for me.

. I suspect the latter part of that statement plays a larger role here. The saying "never attribute to malice what can be attributed to a lack of knowledge" seems relevant here.

I will agree the maintainer showed significant lack of skill, and significant lack of knowledge especially of 'their own code' which is extremely frustrating, however by all interactions I had they did respond which as far as I can tell is the rules as they exist today. I did not necessarily see the 'malicious compliance' on vulnerabilities they received, at most it was a lack of competence in the subject matter, and perhaps some language barriers.

The code owners lack of knowledge did indeed lead to sceanrios where as a reporter I would perform bare minimal support assistance (however any code owner should assume reporters will not assist them and should be happy when we do). This relates to above that as a reporter it is not my responsibility to guide a code owner on how to fix the flaws and is not to manage the DST reporting process.

Other modules, including Drupal Core, have done as bad or worse in my opinion with no punishment over the years.

As one of the individuals who received a 'reported vulnerability' after opening an issue on the maintainers modules I will agree with the DA assessment of questioning if it was malicious, however at the same time I have had a maintainer look at my code (in response to an issue I opened on their module) and find flaws that did need to be addressed so not every cross report is malicious.

I will however note that the concerns could in some cases have been out of module scope. Even in those issues I'm not sure chances to avoid the issues spiraling were well observed or communicated and that the DST could have possible reigned in the issues by being more direct. I also believe some of the DST responses lead to similar deflection in code owners issues as is shown in this thread of at least one incident without 'clear reproduction steps' that I would contend the source code itself was prima facie evidence of a fault, and that a developer should have been able to confirm on visual without full reproduction steps.

As a reporter: There is also a chilling effect if one believes their reports may also lead to being de-listed.

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,

As a code owner and issue reporter I do have similar concerns. I can not say what the DST did in the background to inform the individual, what I can say is at no point was this raised in the actual issue, I as the reporter was informed my concerns were being dismissed by seeing the public SA and only after the fact received notice in the issue.

At the very least this is questionable as it relates to coordinated disclosure by the Drupal Security Team. As a reporter I was given no time to prepare for official public release and the code owner may have been given no time to prepare either.

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.

This is one of the first thoughts that came to my mind when I saw the single SA published yesterday. From both an acknowledgment of security reporters who spent time working the issue (finding the flaws took minutes, working with the maintainer took much more time) to the DST upholding a responsibility to make possible site owners aware of how their sites may be vulnerable (yes this module has only a few reported installs, and yes its possible they are all dev sites however does the the DST has 100% conclusive proof of such).

There is still technically the 10,000 install 'procedure' however that was never adopted into the CNA SCOPE and has not been strictly adhered to since CVE publishing was revamped this year allowing reporters to request the issuance of such ID. I have not yet decided if I was going to raise these issues to a formal request (was OOO yesterday).

Given CVE ID's allow reporters a unified identification of each flaw to facilitate communication I would recommend there is reason to proactively issue a CVE-ID for each flaw that otherwise qualified as a vulnerability.

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 auto_translation module that has also post on drop times and is used by more than 250 sites

The other projects did not get an advisory.

As a site owner this one concerns me, 265 installs is indeed not a lot when compared to core, however if I were one one of those 265 installs this decision is absolutely a critical change in the module that I need to know about through an SA (or at least a PSA). That module has releases dating back to January of 2024.

As a site owner this causes me to question the very foundation of the security of any site I operate running code from the Drupal Ecosystem if security coverage will possibly be silently removed at any time how can I recommend Drupal?

I was criticized for using AI. The same people then went on to report security issues.

In my case you were criticized for your assertion about the module that could be contradicted by clearly obvious contradictions in the code, or impossibilities (testing against an unreleased D12, D9 support when using ENUM's only added as a backport to a minor release of D10, etc).

I found myself asking "does this individual understand PHP code" and even "how is this a user with the Security opt In permission, how low are the standards?".

The security vulnerabilities took longer to confirm on a test site than they did to observe in a manual code review (I do mean literal single digit minutes to see the flaws in code). The surrounding code lines I did spot read were so questionably written that I did not expect to be able to actually exploit any of my discoveries as I suspected unrelated bugs would prevent code execution to reach as far as the vulnerability. That said I do wish to temper this that when we stare at the same code over and over again it becomes much easier to become blind to flaws and that could possibly be involved here. On more than one occasions I've had a flaw against a module I maintain that in the hundreds of times I have read the code I never registered the flaw, only for when it to be pointed out it becomes blatantly obvious to the extent of thinking "how did I miss that".

In fairness to the DST this incident did reveal a set of scenarios that I had not yet encountered when dealing with maintainers

Per my comments on #3521303-20: Bulk LLM-generated module publishing by bigbabert → it is to my knowledge unprecedented, I've certainly never seen anything like it and I have seen a lot of things.

I did not necessarily see the 'malicious compliance' on vulnerabilities they received, at most it was a lack of competence in the subject matter, and perhaps some language barriers.

To be clear, 'malicious compliance' is my own personal view, not the view of the security team, however I do not know how else to describe 200kb 'vibe coded' patches with dozens of out of scope changes, which despite repeated requests to fix only the security issue in a security release, kept getting bigger every iteration.

I can think of many situations where people post patches that don't actually fix the security issue (this is part and parcel of trying to fix a security issue, there can always be additional edge cases or sometimes misunderstandings about the nature of the vulnerability etc.), the difference is between a flawed 1-20kb patch that is attempting to fix the issue within reasonable scope, and a 200kb patch that is blatantly not.

As a code owner and issue reporter I do have similar concerns. I can not say what the DST did in the background to inform the individual, what I can say is at no point was this raised in the actual issue,

📌 Bulk LLM-generated module publishing by bigbabert Active has been open in the public issue queue for three weeks.

however at the same time I have had a maintainer look at my code (in response to an issue I opened on their module) and find flaws that did need to be addressed so not every cross report is malicious.

Yes this can absolutely be the case that people find issues in each other's modules. It's not the case when copying and pasting output from an LLM prompt without reviewing it, with the only commentary being "Above an analysis done on the module using AI.".

(yes this module has only a few reported installs, and yes its possible they are all dev sites however does the the DST has 100% conclusive proof of such).

Well we can say that the module had approximately three installs in the week when the s.d.o issue was opened https://www.drupal.org/project/usage/advanced_file_destination → and now it shows six. There are two possibilities - they are either dev installs, or if they were real installs, there could have been even more of them a week or month later had this action been delayed further.

absolutely a critical change in the module that I need to know about through an SA (or at least a PSA).

I don't think a PSA has been ruled out, this feels like something that could be added to a policy suggestion in this issue.

Note: As far as I can see at least some level of fix has been committed to the repo, I'm still in a 30 day promissory lock down on specifics, however I will discuss general discussions key points that I believe lead to this scenario.

It could be argued this belongs over in 📌 Bulk LLM-generated module publishing by bigbabert Active however as the security team made its announcement post here and this is related to the fact that policy was unclear I'm going to continue with the discussion in this issue.

however I do not know how else to describe 200kb 'vibe coded' patches with dozens of out of scope changes, which despite repeated requests to fix only the security issue in a security release,

What I observed was:

1. An issue was assigned to the maintainer, they generated a patch.
2. The patch was refined a few times. (I agree the patch itself was somewhat questionable)
3. During this time the maintainer makes comments they do not believe it is actually a security fault, no direct dispute was made of this until much later.
4. Another 2 issues were assigned to the maintainer.
5. The maintainer asserted the original issue patch was related and provided it for testing. This does have security concerns in leaking issues. At no point did the Drupal security team inform the maintainer not to leak the code over. As a reporter it is not my place to tell them not to provide me this patch.
6. The maintainer was informed the patches provided no fixes to the additional reported issues
7. The maintainer provided the additional fixes ON TOP of the patch from the first issue
8. Patches were refined based on (basic) "resolved/not resolved" feedback.
9. The maintainer asked to make a single release with multiple issues.
10. A security team member marked an issue RTBC and concurred on a stacked release. RTBC also includes the automatic "release window" text as a footer in italic. At this point we now have a scenario where it is reasonable that the maintainer believed they have permission to combine the issues and that when reviewed they can be posted)
11. A second issue was reviewed by the reporter and noted that they were unable to duplicate the issue (the patch was heavily stacked at this point with 3 issues of fixes combined). It is reasonable to believe the maintainer might have taken this as 'consent' albeit they missed the DST approval stage.
12. The commits were made to the repo for issues 2 and 3 with partial of the 1st issue since it was already stacked in and a release tagged for DST release. This is the first 'major' breach in policy in that parts of two not fully approved issues were made, however from the previous steps we have reasonable consent from the Drupal Security Team. It is also important to note that these issues were constrained to the same reporter while the 3rd was a separate reporter indicating another delineation to a possible release separation
13. The concerns continue as the maintainer is informed that release is waiting on an additional issue, the maintainer appears to have not realized
14. The maintainer continued working on the 3rd issue in a stacked setup including the code from the fixes for issues 1 and 2.
15. The reporter confirmed no longer being able to duplicate the issue, however re-affirmed as they had in other issues they were providing a bare basic functional test and did not review the code.
16. The Drupal Security Team makes its first attempt to unstack the patches and remove out of scope code.
17. The maintainer removes unrelated cleanups from the patch however does not unstack them, mentioning the previous agreements for a single release. At this point we clearly have a maintainer that is of the mindset that everything needs to combine into one single patch to resolve without a firm grasp of a delineated workflow. The situation is also degraded by the commit of the previous 'release' which large size created an environment were patches are less likely to apply.
18. A reporter makes a note that normally security issues are handled in isolation, however as it is not their responsibility (and the reporter has some question on their authority as they were added after initial report to confirm/deny duplicate status) makes no clear direction to the maintainer that the security team absolutely is asking for them to be unstacked and for the maintainer to combine them just before tagging the release.
19. The Drupal Security Team announced revocation of security coverage without trying to clarify what a 'single release with multiple vulnerabilities' would look like

Given the above my personal opinion both the maintainer and the Drupal Security Team contributed to the situation of the patch files growing in size. I do not assert that the DST could have foreseen it would have taken this path until it had reached its ultimate conclusion.

I will also add their was significant tension in the issues regarding "Needs team response" which was used any time the post needed DST guidance. I personally find this fitting as the issue was in a state where neither the reporter nor the owner are really could make a ruling and asking for guidance. The issue thus contained a bit of "issue status flame warm" as we see on D.O.

that the module had approximately three installs

Unless the security team pulled the Download logs directly they used a known unreliable data set (for context, zero of my sites allow telemetry updates to be sent, its just standard operating procedure for deployments). Again I still agree this is very unlikely, however it points out to me further concerns in the teams decision making process.

- the existing policy covers it,

I disagree, as far as I can see the only real transgression I see is we have is tagging a release which as noted above there is reason to believe the DST played a significant role in this portion of the incident occurring.

has been open in the public issue queue for three weeks.

I will note I have experienced a similar issue, I followed a published procedure on D.O. and was in a release timeline for a security release, the documentation was changed in the Documentation Queue without ever informing me as the code owner. The change was made when a release and been committed and tagged in the middle of a security release window to prevent publication. T

here is a know behavioral problem from the Drupal Security Team not informing users of relevant discussions and pretending the fact they are in the public queue and could be found as sufficient. Even in this case where we are aware of the issue existing there are limitations on what could be discussed until the security issues clear.

As someone who has had my own D.O. access threatened for discussing what I perceive as mishandling of security reports by the DST I am reserved how much I was going to go to bat for someone of lower quality skill until the issues are public As such directly related comments were NOT publicly discussed in that issue which means the issues are incomplete on their feedback from relevant parties especially as being aware of the private issues I expected they were still progressing per policy.

I want to say this is technically valid to a single term, and that have seen other modules do similar on my own reports and other cases where the DST has admitted a module owner failed to adhere to policies.

I don't want to get into the specifics. I will say, it was not a single action or single violation of one term in the terms and conditions that resulted in removing this user's ability to opt projects into security coverage. Mistakes happen and we certainly wouldn't take this drastic of an action for a person who makes one mistake.

#21 is right that we can change the policy. 2 areas that seem most up for discussion in my mind:

* if folks feel a CVE should be issued for each separate issue we can do that. Submit proposed cve json to the securitydrupalorg queue and we can do that.
* I think it's reasonable to issue a PSA for modules getting opted out (the help text on the radios says it may happen). Should it happen even for modules with zero users? Or 10? 50?

Hi all,

I’ve observed a number of unstructured processes, and while that’s not ideal, I’ve decided not to ask for opt-in again. Is not something that i need for reputational or credits as looks like someone needs more on that space.

The reason is simple: I don’t feel comfortable with certain attitudes and behaviors I’ve encountered, which, from my point of view, don’t reflect a healthy, collaborative, or inclusive environment. This clashes with the way I approach digital development, customer satisfaction, and the delivery of high-quality, enterprise-level software.

I’ve also seen some comments and judgments based on just two Slack posts, which I believe is a limited and unfair way to evaluate someone's contributions. Anyone can review the current contrib space on Drupal.org and find modules with poor-quality code or serious issues, and I’m not the one who opened those reports. That is part of development activities there is no one that not make bugs this is how to evolve.

If technical knowledge and collaboration are going to be judged by a narrow view of "the only right way" to do things, then I’d rather stay out of that space.

I’ve also noticed that some of the recent comments contain personal judgments on various aspects that, in my opinion, should have no place in a security team, nor in a healthy and respectful community.

Best regards,
Alberto

I don't want to get into the specifics. I will say, it was not a single action or single violation of one term in the terms and conditions that resulted in removing this user's ability to opt projects into security coverage.

We will need that data here, the community can not participate in clarifying the policies if the alleged issues are not made clear to us.

As I noted in my above the only item I can see is the reporter tagged a release early. Everything appears to be either a dislike in communications or an annoyance at an unskilled developer who by all accounts meets the minimum defined standards as outlined in their previous approval to the Security Opt In permission.

At worst perhaps they failed to adhere to the Credit Abuse Policy in reviewing their code, however that is separate from the Security Opt In permission and contains its own punishment procedures.

Side note:
The maintainer did offer to have one of their project that had all the security concerns removed from Security Coverage, the security team did NOT appear to take this offer which would have been much less controversial, as such the Security Team needs to be held to an even tighter standard here.

@cmlara,

I also have the impression that the attention given to my comments has often been superficial. In several cases, what I wrote seems to have been ignored or not fully considered. I understand that English is not my first language and my communication may not always be perfect, but I'm used to being told when something is unclear, rather than having it dismissed altogether. A bit more dialogue or clarification would have helped avoid misunderstandings.

BR

Hi everyone,

For the benefit of who is interested, as agreed per comment #16 🐛 Clarify policy for revoking security advisory coverage Active attached screenshots of security issues and SA already agreed before the generic one without fix included was published without any triage

Best regards

@bigbabert please do not repost entire issue threads from the security issue tracker in public

@bigbabert please do not repost entire issue threads from the security issue tracker in public

Under normal industry reporting procedures the code owner generally have authority to publish reports filed to their projects, just as the reporters have rights to publish the information.

I will note per the Drupal.org Terms Of Service DST reports are CC Share Alike 2.0 licensed, as such the user appears to have the license authority to post them as all commenters in the issues accepted this license.

.

@cmlara the Drupal.org terms of service link to https://www.drupal.org/drupal-security-team/security-team-procedures/dru... → which does not say 'just post the entire content of security issues publicly without prior agreement from the security team'. This very much applies to the content of security issues that have been recently fixed or otherwise moved to the public queue since there may be additional information in discussions or specific exploits discussed, for example we delay posting test coverage for core security issues until weeks/months after the release, to allow sites a grace period to catch up - especially when exploits are very obscure.

Note: I am not a licensed attorney, if you have any questions about the below you should seek council from an individual licensed to practice law in both your jurisdiction and the jurisdiction of the Drupal Association(D.A.)

Do you think the overall Drupal.org content license should override responsible disclosure policies that are also included in the terms?

I would believe they do, the D.A. has specified a license for the content, if they wish to add additional terms it is no longer the CC Share Alike 2.0 license and they must remove the references to such, see https://wiki.creativecommons.org/wiki/Modifying_the_CC_licenses for more info.

That said the D.A. may add terms that apply to site usage allowing allowing removal of content. However that must be done in a way that the policies do not modify the license agreement for use of posted content.

Addressing that point, the linked document is to my knowledge actually the DST Charter, as such it is written to regulate Drupal Security Team members, not Code Owners or Reporters.

A key aspect is "In general, information shared within the Drupal security team" once a 3rd party that is not a security team member is added to the issue the information is no longer 'shared within the Drupal security team" unless it is discussed solely on back channels without involving non-team members.

The remaining terms are all written as applicable to Team Members and as such do not apply to the Reporter or the Code Owner.

In my opinion the reporter or code owner is theirfore likely in full compliance with their agreement "to adhere to the Drupal Security Team Responsible Disclosure Policy" as none of the policy references them nor prohibit the direct disclosure of content by non team members.

If the above is a surprise to anyone I would suggest they perform a basic audit of the legal contracts more often.

I will also caution attempting to put strict limits on Reporters may result in more public disclosure and the D.A. must tread carefully if they attempt to do so.

Addressing that point, the linked document is to my knowledge actually the DST Charter, team member disclosure contract, as such it is written to regulate Drupal Security Team members, not Code Owners or Reporters.

You clearly didn't read the Drupal.org terms of service though, because it says this:

If added to a private security issue, you agree to adhere to the Drupal Security Team Responsible Disclosure Policy

You clearly didn't read the Drupal.org terms of service though, because it says this:

I suggest you re-read my post, I detailed how I can agree to the policy yet none of the terms would actually apply as I, even after being added to an issue, am not a security member. Security team members are (currently) listed on https://www.drupal.org/drupal-security-team/security-team-members →

In other words the contract is essentially “I Conrad Lara agree when added to an issue as a reporter or code owner the current members of the security team will behave as follows with the information I provide. If I am upgraded to a security team member terms in this policy will apply to me”

The implication would be, that if someone doesn't do that repeatedly, they would not be added to private security issues any more

Perhaps that was the intent, however from my “average person” reading not what is written.

Positional titles matter, if the D.A. wants that document to apply to Reporters and Code Owners they need modify it to be (clearly) applicable.

hi @longwave,

my understanding was that permission to share the content of the security issues was given in comment 16 🐛 Clarify policy for revoking security advisory coverage Active .

BR

my understanding was that permission to share the content of the security issues was given in comment 16.

The content of those security issues is irrelevant for this issue, which is titled Clarify policy for revoking security advisory coverage. Security issues created for specific projects are irrelevant for that policy.

The content of those security issues is irrelevant for this issue

I disagree, comment #14 opened the door when calling out an incident that occurred.

The posts are an alleged breach of the policy and go directly to providing context for identifying what some team belive the current policy is.

The topic of this issue did not change, so those security issues are irrelevant for deciding what the policy for revoking the permission to opt projects into security advisory policy should say.

Also, comment #14 🐛 Clarify policy for revoking security advisory coverage Active just said it happened the permission to opt projects into security advisory policy had to be revoked and that we should provide a starting point for what the process to revoke that permission should look like.

This is not an issue to discuss each case where that permission has been revoked. It is an issue to clarify the policy to remove that permission.

I'm not discussing the specific issue but it is related and maybe someone reading here is interested in the process that come with my permission opt-out, personally i've to say again that i don't see fairness or transparency in that process neither in the SA publication, at least for my experience.

@bigbabert re #36

#16 explicitly says

I do not think it would benefit you, nor the general public interest, to publish all the content in the issues.

and the linked page also says

Much of the information in the private s.d.o issue is not appropriate to copy over to the public issue.

I do not think that gives permission to post the entire page from the private issue as a PDF.

Hi @longwave,

ok now i understand, may i kindly ask if is needed the permission of reporter or maintener before to publish the SA?

and also it is normal the attitude of certain comments in the security issues? i think sharing this will benefit to have a more transparent and fair process, that is what a n open source community should promote in my mind. I really hope that this situation can start to change some attitude and make people write inside the community not like they are talking with sub-human but pair level person.

BR

The post above reminded me of SA-CONTRIB-2025-057 →

The private issues may be made public at the discretion of the reporter and maintainer.

(emphasis mine).

Per above one could contend that the Drupal Security Team has granted permission for full disclosure to the Owners and Reporters. Note: I am not asserting that the Drupal Security Team Member Disclosure Policy applies to Code Owners or Reporters, however even if we were to accept it did we would have a public blanket waiver granted which raises questions about the claims in this thread.

Furthermore I will note for the public that the Drupal Security Team may argue they are trying to protect sites however they publicly announced a vulnerability exist in a module without informing the Code Owner or the Reporter in breach of normal Coordinated Disclosure/Responsible Disclosure ethics further weakening any arguments they may make that their reason to prohibit publication is for the safety of the community.

For issues that I am the 'sole reporter' on the sensitive information is inherently between the Code Owner and myself. If there are issues I am not the sole reporter on I can not speak for them other to say that I hold no objection to those issues either.

As I noted above my personal policy is a 30 day disclosure delay unless the site owner provides a release. The maintainer is not bound by me to withhold for any period of time and I generally encourage maintainers to release details as soon as they believe it is safe to do so.

I will note such a delay is entirely voluntary by me as a Reporter, other Reporters may not grant such a delay and neither the DST nor Code Owner have any real control of that process.

I do also feel compelled to reiterate: I understand why the Drupal Security Team does not want to deal with this code owner. I would classify this as the worst experience I have had with a maintainer since the beginning of the year however that is how the industry is at times.

I only argue the points I have made in this thread out of concern as a Code Owner, Reporter, and Site Owner that practices generally considered "standard" in most developer circles are being threatened which can impact systems I operate.

My hope is that with the incident logs available the DST will be able to point to concrete concerns as have been partly asked in previous comments and that this issue can move away from "postponed".

See my previous comment 🐛 Clarify policy for revoking security advisory coverage Active to understand why the status is Postponed (maintainer needs more info) and the Needs issue summary update tag.

Also, my first comment 🐛 Clarify policy for revoking security advisory coverage Active answered to the issue as written now.

It is not true there is no documentation about revoking the permission to opt projects into security advisory coverage; that documentation does not list all the cases for which that permission is revoked, though.

That documentation is no linked in the documentation for the process to be able to opt projects into security advisory coverage because that permission has been given also to people who did not apply with the current application to get that permission. There are people with that permission who obtained it creating an issue in the Drupal.org CVS applications → queue, which at the time did not require to even create a project and post the code in the application they created. There are people with that permission who obtained it before the Drupal.org CVS applications process was created.

Therefore, the issue summary needs to be updated to make clear what this issue is proposing.

From comment 44:

Per above one could contend that the Drupal Security Team has granted permission for full disclosure to the Owners and Reporters.

I wrote the sentence in comment #14 you're referring to while considering the process for publishing private issues. I later linked to that process from comment #16. Those comments were about half an hour apart. There was a moment of ambiguity about what kind of copying the reporter and maintainer could do, but it's no longer ambiguous.

Comments here lack work toward crafting a policy. I shared the details in comment #14 as a good faith attempt to help inform a policy. They do not name or cast judgment or expose private information.

People in the Drupal project regularly have to make decisions without policies, especially for infrequent events. We have a governance model for choosing people to make decisions. I don't know if more policies are needed to cover this scenario. Still, if someone does want more policies to cover this case, I believe that spending time writing a draft policy is a more effective way to get one.

Hi @avpaderno,

my permission at time when i asked was given by you: https://www.drupal.org/project/projectapplications/issues/3035714 →

BR

@bigbabert Yes, it was. It is not relevant for this issue, though, since for an application we just review a project, not all the project you write, including the future ones. It is not even relevant for the permission to be revoked.

to me is relevant to highlight the process and (lack of) raccomandations given, if you prefer please remove the comment. So we agree that once a mantainer individual or organization get opt-in on a project next project (if not published on slack) are not reviewed? i'm asking because i see projects with stable release eg. https://www.drupal.org/project/video_embed_jwplayer → (just fresh example but there is a lot) that not work and probably have security issues too.

Comments here lack work toward crafting a policy. I shared the details in comment

Are we crafting or clarifying? there is a big difference between the two. crafting involves creating new or modifying, clarifying involves pointing to an existing published policy decision that needs to be more clear.

#14 as a good faith attempt to help inform a policy.

I shared mine from #22 indicating that I see no reason that (under what I understand the currently policy to be) in hopes there is a policy the DST could point to for clarity or show us there is no policy for this situation and that one needs to be created.

I still maintain that since the DST tracker threads are the catalyst for this issue being opened they are directly relevant to the discussions. I presume the posts from #28 were for the same reason to shed light on the situation so that policy could be 'clarified'. Since 'fixes' for the issue are published they pose little to no risk to the community, additionally security team members used the argument that they likely only impacted development sites (which is why they acted in what appears to be a rushed mannered).

Instead of working the actual issue the D.O. representatives have instead fought the community and acted in a non collaborative manner allowing us to reach comment #50 with no sign of this issue moving forward.

My personal impression of this issue is that it was opened to allow creating a new policy that would allow banning the specific user, however the action ended up being taken before the policy as crafted. I'm still trying to assume there actually is some written policy somewhere that backs up the action, however so far there has been zero proof of such given.

People in the Drupal project regularly have to make decisions without policies, especially for infrequent events. We have a governance model for choosing people to make decisions.

This works for internal issues such as "will we add this feature to the process" however for aspects of the Security Opt In permission a role with privileges and the Security Advisory Service these are closer to contracts/terms of service and need to be explicit where ambiguity should be ruled in favor of the user (since they do not draft the contract).

The Drupal Association gets it self into trouble on these situation where it takes action without a well informed clear obviously visible to users (this means not hidden away in some sub menu somewhere, it needs to be linked from Terms of Service, or made to have a user click 'accept' on it once it becomes applicable)

As start to answer #12 I suggest https://www.drupal.org/terms → have new section added:

Role to opt projects into security advisory coverage:

The role to opt projects into security advisory coverage (known as "git vetted") may be removed by the security time without necessary cause. The user may follow the normal Project Application process to receive the role again. If the Security Team must show cause within 7 days an application being opened the user shall be eligible if they otherwise meet the current process.

Security Advisory Coverage enrollment for projects:
Maintainers with the Role to opt project into security advisory coverage may opt projects into the Security Advisory Coverage Program.

The Drupal Security Team may at anytime without required cause remove any project from Security Advisory Coverage Program.  If the Drupal Security Team does not provide cause any maintainer may opt the project back into coverage. If the Drupal Security Team provides cause any maintainer may opt the project back into coverage if they provide 7 days advance notice to the Security Team that the cause has been rectified.

Both of these could use more cleanup however I believe that gets the Gist of what the Drupal Security Team wants for this.

Both of these would likely want procedure documents associated with them that the team follows describe how they conduct their votes, how they will provide notice to impacted users (especially security advisory coverage enrollment) etc however the ToS changes would make ti clear that it can be revoked at any time even without cause (the DST will of course be kept in check by the community who will refuse to work with them if they feel doing so may threaten their accounts)

Alternatively: This could be assigned to the CWG and require formal hearings.

You can have look here 📌 [1.0.x] AI Readme Generator Active Security coverage request, reviewer sentence:

This is not an issue created in a project queue.

Comments in this queue are required to review the project files and report what needs to be changed. We do not debug projects.

Documentation for reviewers 📌 [1.0.x] AI Readme Generator Active :

Correct usage of Drupal APIs →
We check all the PHP code line-by-line, looking for proper use of Drupal APIs, to verify that functions/methods receive the correct parameters, but also that the correct APIs are used.
Verifying the code does not contain security issues also verifies the Drupal APIs are correctly used. This is an extension of the previous point; it also includes those cases where misusing a Drupal API does not cause any security issue.

emphasis by me.