Borrowing the words of @JamesOakley from: https://www.drupal.org/drupalorg/blog/goodbye-project-applications-hello...
"So we now have two statuses for a project: (i) known to be secure [in the sense that there's a proper disclosure and resolution process for vulnerabilities] and (ii) not monitored / checked for security. We have a positive / neutral security status.
I believe we also need negative security status = "This module has had a vulnerability reported for it. The project author has chosen not to have their module vetted by the security team. We therefore advise against using this module until the code has been checked by the security team and the alleged vulnerability patched if necessary."
The only way to remove that flag would be for the maintainer to apply for vetted status if necessary, to opt in to be covered by the security team's processes (which would not be shown on the module page straight away), and to work with the security team to co-ordinate a security release. When that goes live, the project moves to show the shield.
We could see problems where someone maliciously reports a module as insecure, but that is less likely in the FOSS world than it would for a commercial module. More possibly, someone mistakenly does that.
But we need some process to prevent modules with long-standing known vulnerabilities sitting there indistinguishable from modules that have simply never been vetted."
In summary - we should try to make it clear when projects that have not opted into the security team advisory coverage process have public, open security issues.
This is difficult, do we monitor this by simply looking for the 'security' tag on the project's issues? Are we concerned about users maliciously reporting security issues that are not really security issues?
Comments
Comment #2
drummComment #4
drummThis has been deployed. For example, https://www.drupal.org/project/database_backup
Comment #5
jamesoakleyExcellent
What's the mechanism by which an unsupported project would be reported / found insecure and then left in that state? [Or, is this not the place to describe that?]
Comment #6
drummThis uses the same criteria as #2862603: Block security advisory opt-in if there is an open security issue in the public queue of a module, an open issue tagged “security”.
Comment #7
drummProject pages have a “Report a security vulnerability” link which goes to the security.drupal.org issue tracker if a project is covered. If the project has not been opted in, then it goes to the public queue with that tag pre-filled.
Comment #8
jamesoakleyI think that works - it certainly covers the bases.
I don't know what the "right" answer is for the next bit, but: What happens if the maintainer closes that issue?
[Part of me thinks it should remove the "vulnerable" state: that they need to be able to self-fix; that's then not a guarantee the module is secure, but simply back to where it was before. Part of me thinks the "vulnerable" state should remain until they've liaised with the security team to come under their supported status.]
Comment #9
drummA good portion of security reports tend to be false positives and other noise. Since the security team won’t be actively reviewing these issues, it is up to the maintainer and anyone else watching the issue queue to decide.
When the maintainer closes the issue, either marking it Fixed or any other closed state, the extra notice will be removed from the project page immediately.