Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
We should have automated monitoring of new public issues as part of our regular triage duty. A daily report of new issues/comments on d.o that mention any keyword. The team member would then review that list and try to find anything relevant.
Some potential keywords:
* security
* insecure
* "sql injection" / sqli
* xss
* csrf / xsrf
* "cross site scripting"
* "access bypass"
If we just start with those that would be a nice improvement
Comments
Comment #1
cjoy CreditAttribution: cjoy commentedwould this also cover updates to *old* issues?
It appears to me that one of the factors that allowed #2146839: Database ExpandArguments placeholder naming issues when using array to remain unnoticed, was the delayed (and somewhat silent) escalation.
Comment #2
gregglesThat makes sense to me. I don't think anyone particularly watches the 7.x-major queue any closer than they do 7.x-normals.
And to be useful, this tool would have to look at all issues including those filed as minor.
Comment #3
kattekrab CreditAttribution: kattekrab commentedGreat suggestion Greg. Something similar crossed my mind when I saw that issue. Some kind of keyword alert would be useful at our scale.
Comment #4
Bojhan CreditAttribution: Bojhan commentedActually, can we not monitor on this - as people are writing it and serve them a message? I would like to aim for prevention first. We've added too many messages for them to be of use for signalling, we need a more active way.
Comment #5
marcvangendBojhan, I think that is a great approach. We could use javascript, or check for those keywords during the form validation, and add a confirmation step if one or more keywords are present.
Comment #6
David StraussOn some systems like Launchpad, the issue tracker specifically asks if something is a security issue as part of the filing process. Now, I know our normal tracker can't handle them directly, but we could disable submission to the normal queues and provide instructions for the right place to send it.
Comment #7
David_Rothstein CreditAttribution: David_Rothstein commentedA problem with this might be that there will be many false positives. If a warning popped up at me every time I typed the word "security" in a comment I would probably get annoyed pretty quickly.
For this reason I think it would be better to start with the initial proposal and see how it goes. Easier to get done, and no end-user UX issues to worry about :)
Drupal.org sort of does that too, although it's probably not noticeable enough: #2358373: Improve clarity of the reporting security issues warning
Comment #8
plach@David_Rothstein:
I think I could live with an extra-confirmation step (form rebuild) if my node/comment content included a problematic keyword. Not sure how you would like to notify the security team, e.g. by mail or by flagging the issue so there's a specific queue to check, but I think this confirmation step would have the potential to highly reduce the number of items that require immediate attention from a security team member. And thus reducing also the risk to devaluate the importance of these notifications.
Comment #9
Bojhan CreditAttribution: Bojhan commented@David but this is only about new issues, and then only core?
Comment #10
mlhess CreditAttribution: mlhess commentedAn easy way to do this it to build a solr query and email it out to the team daily.
As far as old issues, we could run this on project issues only for the X years.
Next step format the results for email. I would guess the title, a link, and the content field as returned by solr will be enough. Looking the results would become part of triage duty.
Comment #11
dokumori CreditAttribution: dokumori commented