#Content Security Policy

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

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?

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.

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

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.

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.

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 :)