@Jeffro Here are some aspects of this story that Checkmarx might address:

1.) The method used to select a sample of plugins for the study is unscientific. By selecting "popular" plugins, the sample is unrepresentative in meaningful ways. Although it is mentioned that the findings are applicable (only) to "the most popular plugins", what was found out about this special sample is then used to argue for policies that would be applied to all plugin developers, and to plugins as a whole and their role in the WordPress 'ecosystem'.

The sample-selection method should have been randomized, etc.

It is true & valid that the popular plugin codes will affect more websites, but it's not scientifically legitimate to extend what is found out about popular titles, to unpopular examples as well (which in fact comprise the vast majority of all plugins). Basic observations & inferences about the different liabilities & assets of big-name versus no-name plugins have been recognized & discussed for years ... we already know these 2 groups aren't the same animal.

2.) The study as originally designed & attempted actually failed. It had to be redesigned, in order to be 'doable'. The technical inappropriateness of the original approach and the fact that it had to be abandoned ('Oops - That won't work!'), gives reason to question Checkmarx' grasp of this field.

What is the problem? How did the study fail? As reported at TechNewsWorld:

Six months ago, [Checkmarx] started scanning just the top 50 WordPress plug-ins.

"We were overwhelmed by the sheer amount of results," [founder and CTO] Siman said.

So the researchers limited themselves to the five most critical vulnerabilities -- SQL injection, cross-site scripting, cross-site request forgery, file inclusion and pass reversal.

"Once we limited ourselves to those vulnerabilities, the results were more meaningful -- yet shocking," Siman said. "We found that 30 percent of the top 50 plug-ins were found to be vulnerable to at least one of the vulnerabilities."Automated security-auditing algorithms & programs have been around for a long time. Folks do continue to invent & patent new specific formulations, but the general idea & field is well-known and of long-standing.

Allowed to work 'freely' (as hackers do), such programs tend to churn out 'overwhelming' results. Sure-enough. It's a foible related to the 'garbage-in, garbage-out' phenomenon.

3.) Checkmarx cannot deliver on their promise. They can neither identify the full range of exploits to which plugin-codes might be subject, nor are they physically capable of performing an in-depth analysis of even the mere 50 top WordPress plugins, much less the inventory of 25,000 titles. They are unable to serve as inspector of the ongoing stream of new plugin-submissions from developers great & small (beyond a misleadingly-superficial degree).

They can only succeed, eg, by artificially restricting their audit-targets to 6 specified vulnerabilities. They can offer assurances only that code is free of 'this' or 'that' particular vulnerability ... not that the code is free of vulnerabilities & immune to exploitation.

Checkmarx cannot logistically meet the role they suggest for themselves. Nobody can ... and we've known this for a long time. It's a fundamental "combinatorial" problem. There is 'no end' of ways that code can be exploited.

'If it was really that simple', automated security-auditing would long-since have been a cut & dried done-deal. Vulnerabilities would now be a footnote in the history of computer programming.

The problem is fundamentally similar to that of plugging or denying opportunities to terrorists. That we have our 'junk' inspected at the airport does not prevent the bad guys from selecting 'no end' of other avenues of attack.