An important clarification: as the report states, during the period from which this data was drawn, Veracode only supported analyzing mobile JavaScript applications (mobile applications built using cross-platform JavaScript based frameworks like Titanium and PhoneGap). Since this period we've added support for analyzing both JavaScript in the web client (e.g. JQuery based applications) and on the server (Node.js based applications), so the results should be interestingly different next time around. But this limited JavaScript support is a reason that we didn't seek to draw any broad conclusions based on the language in this study.

Good questions, and I suggest downloading the report to confirm your answers. We won't bite.

We report data in this study largely obtained from binary static analysis, run in Veracode's centralized environment where we can tune our engines for low false positive rates.

JavaScript is at the bottom probably because at the time the data was pulled for this study (six quarters from Q4 2013 to Q1 2015), we only supported JavaScript in mobile application use. We have since added support for JavaScript in the web context, specifically with support for JQuery and Node.js, and expect the picture for JavaScript vulnerabilities to change when we do the next report. That's one reason we didn't include JavaScript in our high level conclusions for the report..

I'm an author of this report, so thought I'd offer some feedback.

First, the iOS applications that Veracode scans are written in Objective C (and probably some C or C++). And the Android apps are written in Java. (Yes, you can write iOS and Android apps using portability frameworks like PhoneGap; we separate those findings out into a separate category.) We used iOS and Android as shorthand so that (a) readers would more readily make the connection with what ObjectiveC meant, and (b) we could separate Java used in Android, which has a distinctive risk landscape, from Java used in other applications.

Second, we choose to report on application prevalence, or the number of applications showing at least one of the vulnerability, rather than number of vulnerability occurrences. The application prevalence metric is more meaningful when talking about the overall risk of a large number of applications. There is value in the vulnerability prevalence metric, when it comes to planning remediation effort, but for this study we focused on the former.

Third, we do report average flaw density metrics in the appendix of the study, along with a discussion of some of the limitations of this metric. I suggest reviewing the actual study (it's only about 20 pages) and then posting any additional questions.

Thanks for the questions and keep them coming.

Our cofounders (I'm director of product management at Veracode) helped to coauthor the responsible disclosure standard, and it's linked on our web site. Short version: we don't disclose details about customer findings.

There is an industry effort to define a "watch list" for common mistakes that lead to security flaws. Co-led by the folks behind the Common Weakness Enumeration at MITRE and the SANS Institute, the SANS Top 25 (full listing here) is being used as a requirements document for the security of purchased applications by the State of New York, among others.

It's not perfect--it omits backdoors and other intentional security flaws, among other categories--but it's better than nothing, by a long shot.

Disclaimer: I work at Veracode and was a co-author of the report that the original article was about.

We scan selected open source projects on a pro bono basis and reach out to the project teams to share the findings with them.

Disclaimer: I work for Veracode and was a coauthor of the report.

If you take a look at the full report (registration required), you'll see that the application pool from which the report was drawn was 47% Java, 31% C/C++ (on Windows, Red Hat Linux, and Solaris), and 22% .NET. Other data is provided (industry, supplier type) to help frame the terms of the application pool from which the data was drawn. We acknowledge the inherent selection bias (the applications in the report come from our customers) in the methodology section.

Disclaimer: I work for Veracode and was a co-author of the report.

You can check out the full report online from the Veracode.com website (requires registration).

We disclose the sample size in the appendix (1591 applications).

You can test the quality of code you are developing yourself with a simple source code scanner, but testing third party code is a little more challenging. I don't know too many significant applications that are entirely created in house, with no dependency on third party libraries.

Disclaimer: I work for Veracode and was a coauthor of the study.