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

cjoy’s picture

would 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.

greggles’s picture

That 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.

kattekrab’s picture

Great suggestion Greg. Something similar crossed my mind when I saw that issue. Some kind of keyword alert would be useful at our scale.

Bojhan’s picture

Actually, 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.

marcvangend’s picture

Bojhan, 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.

David Strauss’s picture

On 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.

David_Rothstein’s picture

Actually, can we not monitor on this - as people are writing it and serve them a message?

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

On some systems like Launchpad, the issue tracker specifically asks if something is a security issue as part of the filing process.

Drupal.org sort of does that too, although it's probably not noticeable enough: #2358373: Improve clarity of the reporting security issues warning

plach’s picture

@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.

Bojhan’s picture

@David but this is only about new issues, and then only core?

mlhess’s picture

An easy way to do this it to build a solr query and email it out to the team daily.

q=%22access+bypass%22+OR+%22cross+site+scripting%22+OR+xsrf+OR+csrf+OR+xss+OR+sqli+OR+%22sql+injection%22+OR+insecure+OR+security&fq=ds_changed:[YESTERDAY%20TO%20*]

Replace Yesterday with a date stamp in solr format. 

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.

dokumori’s picture

Issue tags: +email notification