Create automated monitoring for new issues in the public queue

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.

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

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.

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.

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.

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

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

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

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.