Security coverage inconsistency: Stable contributed modules with known vulnerabilities

Maintainer is a known member of the Security Team

May you point out who is this person? From what I can see, none of those project maintainers are part of the Drupal.org Security Team. Even if one of them would be part of the Drupal.org Security Team, the code is developed by five people; a single person cannot be responsible for what the other people do.

Also, the issue is mixing up two different types of review. The issue summary needs to be rewritten to make clear to which review this issue is referring to.

HI, mine is just an example, i'm pretty sure that Security Team can have a look to the projects that are opted-in and the que to request security coverage and there is lot of evidence.
I'm available in case any kind of support needed!

The issue summary is still making confusion between two different types of review.

The issue concerns two processes:

We are seeing security issues in modules maintained by people who have opted into Security Coverage, but these issues are not being reviewed or flagged by the Security Team.

Project application reviews do not verify whether the submitted modules have vulnerabilities or compatibility issues, and no end-to-end testing is performed.

Could you please let me know which part is unclear or causing confusion?

Either this issue is about a specific review (as per title) or it is about one of the other reviews. When it is about a specific review, voluntary people doing the other reviews are not involved, and they should not be mentioned in this issue because they are not involved, which also means there is no conflict of interests.

One of the people in question is your mentee. i see conflict of interests in both processes. Hoping in a transparent management of that issues.

Are there people who list me as mentor and who are part of the Drupal Security Team?
Is any of those people even involved with Security Advisories?

Is the question related with the concerns reported in the issue?

The issue concerns two processes:

• We are seeing security issues in modules maintained by people who have opted into Security Coverage, but these issues are not being reviewed or flagged by the Security Team.
• Project application reviews do not verify whether the submitted modules have vulnerabilities or compatibility issues, and no end-to-end testing is performed.

No, it is about the claim you did in your previous comment, which itself is not related with this issue, since everybody can show another person as mentor.

The conflict of interest is not part of the concern, i'll remove from the summary, in the comment my intention is to mentor properly people that has opt-in security coverage to not publish module that has not deeply tested and that avoid injections, mine are just examples, but you or everyone can found multiple in contrib modules code

None of those people have been mentored; everybody can add another person as mentor.
Reviewing is a volunteered task to which everybody can partecipate; clearly, for each wrong review there will be a comment saying in what those reviews are wrong.

We are seeing security issues in modules maintained by people who have opted into Security Coverage, but these issues are not being reviewed or flagged by the Security Team.

This is not how security coverage opt-in works. If a module is opted in and has stable releases, then security issues should be reported privately, and if appropriate can be released via a security release with an advisory. It does not mean that the security team regularly reviews or scans modules that are opted in for vulnerabilities.

Modules in "Stable" status with known access bypass or injection vulnerabilities remain without Security Advisory coverage.
[...]
Create a public dashboard tracking modules that meet stability criteria but lack SA coverage.

This is not how security coverage opt-in works. The permission allows a maintainer to opt-in a module to security coverage, it does not require that every project they maintain is opted in. So the dashboard would be nonsensical.

Maintainers of these modules are at the same time participating in the review or gatekeeping process for other developers requesting opt-in status.

The opt-in review process is open, anyone can post reviews. If the reviews aren't correct, this will be pointed out by another reviewer, as mentioned by @avpaderno. Same for anything else really.

Enforce consistency: any module marked as "Stable" and maintained by Security Team members must meet the same opt-in standards applied to others.

=Modules are either opted into security coverage or they aren't, the opt-in standard apply to the person, not a specific module (except for the initial review process usually, but that is ultimately an evaluation of the person).

The entire basis for the points in the issue summary is based on misrepresentation of the existing policies, so moving to needs more info.

Enforce consistency: any module marked as "Stable" and maintained by Security Team members must meet the same opt-in standards applied to others.

Since the issue summary contained links to projects, I would point out those projects were not maintained by Security Team members.
This then leads me to ask: Is this an issue about Security Team members or somebody else? Because the issue should be crystal clear about which procedures should be changed.

Introduce stricter self-governance or peer-review policies for contributors involved in the Security Advisory review process.

Security Advisory review process seems part of the work done by the Security Team. I am not involved with security advisories, nor are people who make reviews in the Drupal.org security advisory coverage applications queue.

Introduce a “Needs Security Review” label or flag visible to site builders.

The This project is not covered by Drupal’s security advisory policy → banner is already there for that reason, except is not visible only to site builders.

The issue is about security coverage of contribs modules:

The issue concerns two processes:

• We are seeing security issues in modules maintained by people who have opted into Security Coverage, but these issues are not being reviewed or flagged by the Security Team.
• Project application reviews do not verify whether the submitted modules have vulnerabilities or compatibility issues, and no end-to-end testing is performed.

The issue isn't against someone but about the process to keep modules with stable releases secure.

about the process to keep modules with stable releases secure

The only way to keep stable release secure is reporting security issues to the Drupal Security Team, when a project is covered by the security advisory policy.

catch's comment already shown the misunderstandings in the issue summary, so I will not cover that part again.

If there is no openness to improving the existing process, the issue can be closed.

To propose improvements, you would need to accurately describe the current processes and how what the changes would be.

That has not been done in this issue, only misrepresentation. Categorising the responses you've received as a lack of 'openness' is further misrepresentation of the issue.

I'm not categorizing any response, if we want "as community" we can start talk about improve the process in this issue or wethever is much appropriate from people with exaustive knowledge of process and policies, i don't have exaustive knowledge of d.org policies and process i've raised concern based on my experience and on the fact that is happening frequently that i look to stable modules code and i found potential security issue.

If no one is interested in the discussion or if the place where the issue is reported isn't appropriate please close it. Thank you

i don't neither understand the current status of the issue what mean, what are the needed information from which mantainer?

The status reads: Maintainer needs more info.

Meaning, the moderators need more info from you, the reporter. As we're just circling around about what the goal here really is.

it is in the summary,

The issue concerns two processes:

• We are seeing security issues in modules maintained by people who have opted into Security Coverage, but these issues are not being reviewed or flagged by the Security Team.
• Project application reviews do not verify whether the submitted modules have vulnerabilities or compatibility issues, and no end-to-end testing is performed.

Also tried to clarify more here:

The issue isn't against someone but about the process to keep modules with stable releases secure.

What is not enough clear? there are specific questions by moderators?

See #34 and #39

To propose improvements, you would need to accurately describe the current processes and how what the changes would be.

That has not been done in this issue, only misrepresentation. Categorising the responses you've received as a lack of 'openness' is further misrepresentation of the issue.

Those need to be in the issue summary (hence the tag "Needs issue summary update").

Summary updated

yet they are maintained by individuals who are part of the security review or advisory process.

What exactly is this referring to? People with the vetted role so they can opt-in a module? Let's use correct terminology :)

Updated the phrase but please feel free to correct with more appropriated terminology, my meaning is that the people with stable modules lacking security are active part of reviewing modules that apply for security coverage.

The policy in question is called security advisory coverage meaning projects are being opted into the advisory process which includes a private issue section for potential security related issues.

It is not a guarantee of security of a module. It means a module has opted into using a private queue for security issues.

The only requirements to opt a module in is that it is in a finished state (stable).

The only requirements for a user to opt a module they maintain into security advisory coverage is them demonstrating they know how to write secure code. If they don't know how to do this then security issues being sent to a private queue only delays disclosure as there is nobody there to fix it (don't know how to write secure code).

If a project opted into security advisory coverage doesn't fix reported security issues then it is removed from security advisory coverage and the issues are made public.

If a maintainer has failed to do this presumably they would have the ability to opt-in revoked as well if warranted.

If you feel you were unfairly removed from being able to opt-in modules you maintain into security advisory coverage (private security issue queue) then explain why. Pointing fingers at others does not contribute anything but noise for drupal ecosystem maintainers. Unreported security issues in someone's module are not grounds for removal. Failure to fix REPORTED issues in a timely manner are.

Hi @rhovland,

i'm not pointing to anyone, and i not discuss what happen it is done, i'm raising some concern from my point of view about the process of security related to stable modules (who define stable?). From my point of view security issue in open source might have to be not private, but again this is only my point of view.

Of course was evident that at least to me the policy was not so clear and now that i'm understanding better it i agree to have been removed from security opt-in i'm not arguing that

Please feel free to close the issue if the concerns are only mine.

Thanks

It appears this issue was created due to a misunderstanding by the reporter, so I will go ahead and close it as suggested.

By the way:

From my point of view security issue in open source might have to be not private

Securiy issues are best addressed privately because application owners would not appreciate leaving known vulnerabilities unpatched while waiting for a fix. If fixing security issues in the open were to be standard, most business and private site owners would likely discontinue their use of open source applications altogether for fear of vulnerabilities being exploited immediately after they are reported.

most business and private site owners would likely discontinue their use of open source applications altogether for fear of vulnerabilities being exploited immediately after they are reported.

This seems reasonable to me, i've also experienced companies that after running SAST on an application they choosed to not use it. So my pov is that the security issues are not only disclosed in public or privately inside d.org but also outside. in d.org there isn't minimum test coverage for stable module by policy?

i come out just yestarday on this post on linkedin: https://www.linkedin.com/pulse/new-drupal-vulnerability-just-two-meters-...