Clarify the Drupal Security Team Disclosure Policy

A few notes:

Pulling my comment from another issue: This will (as mentioned in the IS) likely require a D.O. ToS change as it will likely breach the CC Share-A-Like licensing by adding additional conditions on licensed content.

Canges to the policy should be ran past reporters (both D.O. members and not) and maintainers or impact consideration including via a dedicated survey and mailer.

It is possible trying to be stricter here could significantly reduce both reporter and maintainer cooperation with the DST.

While D.O. is often portrayed as a community, it is important to realize that realistically in security reports, reporters controls the situation.

Reporters will work with maintainers when it is made agreeable to them, the Carrot and the Stick scenario.

In the case of Bug Bounty systems there is monetary value in place to encourage reporters to work within strict confines.

D.O. only has 'recognition' by inclusion in the Contrib SA (and even that isn't guaranteed as a recent incident rolled up multiple reports into a Single Advisory without disclosing the faults). This can be useful for individuals with no established history, however once one is established self publishing can provide enough (and perhaps even greater) recognition than the DST acknowledgment ever could

Essentially, for reporters, there is no carrot, and this could add a very large stick into the equation for those of us who are mixed role.

There is a bit more leeway here for those who are added as consultants who are not the reporter as they are possibly gaining a 'carrot' of knowing something others do not, though at extra burden to them.

Maintainers likely have the most to loose, as they could end up with the DST encouraging public disclosure of vulnerabilities in their code.

Personally:
As a reporter who is also a maintainer who wants to protect their ability to not have the DST encourage users to publicly disclose vulnerabilities without first working with me me, I will have to see how this plays out and what is decided before I can truly opine.

However I could see this possibly causing me to only submit future issues via email, requesting to not be added to S.D.O. issues as a reporter or consultant, and possibly no longer providing assistance in reviewing proposed patches, etc.

Each one of those changes will likely increase the burden on the DST.

There are ways to make the stick less harsh such that as a reporter I would be more willing to work with the DST such as clarifying that once the issue is publicly announced that a vulnerability exists that the disclosure policy no longer prohibits discussion (since the issue is public), and having the DST establish timelines for public disclosure as suggested in #3280775: Change policy regarding timeline for resolution and disclosure of security vulnerabilities to be more strict → (alleviates my concern that I may be told to sit on a 5 year old vulnerability). All these should be considered when modifying the policy to be applicable to those who are not DST "staff".