I ended up implementing this for PHP first, and it was pretty useful! Found T204424, in addition to other security issues that require more involved maintainer analysis.

@Harej @bd808 @Quiddity is there any guidance on sending automated emails to tool maintainers? Here's a real email with the tool's name redacted

Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Subject: Vulnerabilities detected in Toolforge tool: <tool>
To: <tool>.security@tools.wmflabs.org
X-Source: /data/project/<tool>/composer.lock

Security vulnerabilities have been identified in your Toolforge tool:

https://tools.wmflabs.org/<tool>

The following dependencies are reported to be vulnerable:

symfony/http-foundation (v4.0.8)
* CVE-2018-11386: Denial of service when using PDOSessionHandler
  https://symfony.com/cve-2018-11386
* CVE-2018-14773: Remove support for legacy and risky HTTP headers
  https://symfony.com/blog/cve-2018-14773-remove-support-for-legacy-and-risky-http-headers


Please update your dependencies to versions with the vulnerabilities
fixed. If there is a false positive, or the vulnerable code is not
being used by your application, you can ignore this email.

See <https://wikitech.wikimedia.org/wiki/Tool:Vuln-checker> for more
information.

My current plan is to only send out one email per vulnerability (no repeated notifications for the same issue). And at some later point when I (or someone else) have time, integrate this into some web dashboard behind OAuth login.

Sending it to <tool>.security makes it easy for people to set up unique mail filters, and they can use ~/.forward.security to redirect the mail elsewhere if they want to.

The X-Source header is mostly for cases where it's not obvious which folder/code triggered the warning (should not be an issue for most tools).

In T203735#4596371, @Legoktm wrote:

@Harej @bd808 @Quiddity is there any guidance on sending automated emails to tool maintainers? Here's a real email with the tool's name redacted

The use of <tool>.security@ as the email target seems like a good idea. When you create the documentation page you can tell people how to route that to /dev/null if for some reason they really don't want to know what's in need of fixing after the first email. As with anything that could spam a lot of tool owners, an announce on the cloud mailing list before fully turning the service up would be a good idea as well.

In the long term we should probably think about moving the scanner out of the Toolforge space to the actual NFS host if the scan progresses beyond just looking at a few package manager description files per project. There is a really big difference in the load generated by local reads vs reading a lot of files across the NFS mount.

In T203735#4599921, @bd808 wrote:

In the long term we should probably think about moving the scanner out of the Toolforge space to the actual NFS host if the scan progresses beyond just looking at a few package manager description files per project. There is a really big difference in the load generated by local reads vs reading a lot of files across the NFS mount.

My initial attempt recursively searched every tool directory that my unprivileged tool could read, and it took 7 hours, at which point I realized that all the composer.lock files were in relatively predictable directories (a few exceptions that looked more like bots or test things). For JavaScript I expect it to be even simpler (~/www/js/package-lock.json), and something similar with Python.