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.
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.
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.
I agree that there's a contrast, but it's not a contradiction.
WP:Verifiability and WP:RS, as the original article states, seek to anchor Wikipedia articles with externally verifiable touchstones. But there's a difference between providing an independent source for a claim made in an article and linkspamming.
There are certainly administrators who err strongly to one side or the other, but there are mechanisms to correct against admin bias.
These features in Windows were intended to blunt the severity of buffer overflows by making it much more difficult to exploit them consistently. Breaking it returns Vista and Windows Server 2008 systems to the same level of vulnerability to buffer exploits and other attacks that stomp on protected memory.
In other words, these attacks make Vista as vulnerable as older versions of Windows, but not more so.
According to a resolution just passed by the House, the House Judiciary Committee is now empowered to sue the White House to get Mukasey to enforce the contempt citations. Which means the prospect of a trial with testimony under oath on the subject.
Can't believe no one's posted this yet--in a posting on the SiliconValley.com roundtable Wednesday, Craig Mundie responded to criticism of the EULA under which the Mobile Internet Toolkit is being offered. He said,
"Both panelists and non-panelists laid out some concerns. Brett Glass pointed out that this is only one of many Microsoft licenses, but that doesn't close the topic. I have been thinking through the comments and have gone back and talked with the team that is managing the Mobile Internet Toolkit. We recognize that the license can be reworked to make it clearer. The license right now pertains to beta code - we will revise the license terms, based on your feedback, prior to RTM."
Thought this was interesting enough for comment. Still doesn't indicate how the license will be revised, but is it a step in the right direction?
An MBA is a skill set, a set of connections, and (to a certain extent) a way of looking at the world through a particular point of view. Entrepreneurship is a burning desire to build something new. They aren't opposite skill sets.
Certain MBA programs, e.g. MIT's (disclaimer: I'm currently at MIT's Sloan School of Management), can expose you to as much of the business environment around entrepreneurship as you want so that you can develop the skills to deal with VCs, patent attorneys, market analysts, companies who want to acquire you, etc. An MBA program also exposes you to business fundamentals like accounting, organizational theory, strategy, etc. so that you can develop an effective business plan--or at least know enough to recognize when your business plan goes wrong and how to fix it.
I agree with your assessment that the degree doesn't have anything to do with the spark. But I think the NASDAQ has already suffered enough from an overdose of people with good ideas and not enough business skills to build good businesses around them.
OK, I've got my flaming gloves on, so someone may want to moderate me down now.
Every commercial software development project, by which I mean one that is developing a product that will be put out by a commercial company with a considerable amount at stake, cares about three things. One is cost. One is quality. One is schedule.
Regardless of what you might believe, one cannot have infinite quality and timely software delivery at a reasonable cost. Netscape/AOL product managers have an extremely difficult choice to make. Do they release Version 6.0 sometime this millennium and fix bugs later, or do they delay the release indefinitely and go on fixing bugs, adding features, and so forth until no one cares any more?
For heavens' sake, folks, you wouldn't even KNOW if IE had the same problems! Why? Because they haven't opened their bug databases!! You're hoisting the Netscape managers because you have information that Netscape, or the Mozilla project (remember, the open source project that was started by Netscape in the first place) chose to give you.
I thnk that most folks who have worked in a commercial organization would support me as I make this assertion: like any other manager, a product manager must chose to make tradeoffs between quality and the schedule. In the case of the Netscape/Mozilla project, we (the community) are farther ahead than in any other commercial software project I know: we can find out about the bugs, we can fix them, and we can make the next bugfix come out sooner as a result.
Let's stop talking about abandoning the only open-source, major-league, standards-embracing browser out there, and start pitching in and helping. And don't forget to vote tomorrow, while you're participating in the process.
Actually, that assumes that you need all the VB, COM and ADO machinery to do data collection and validation. You really need to do a value analysis of whether the ease of directly addressing this COM machinery outweighs the cost to the user of deploying it. Not an issue if they already have PocketPCs or WinCE machines; a problem if they have to throw away their Palms to run your application.
Your app could probably be written to address DCOM versions of your application objects via a lighter-weight protocol such as XML-RPC (aka SOAP), so that you wouldn't need client-side COM. That could make your app a lot more flexible, so that it could run on other platforms that don't use COM, such as WAP-enabled phones...
I know, as a programmer, that using reusable services and app development frameworks is awfully tempting. You have to keep the proper perspective about whether those frameworks and services are really appropriate on the platform and for the purpose that you are trying to target.
Part of the issue is the desire to make obscure and abbreviated directory names such as "usr/local/src/m18-src/mozilla/extensions/transfor miix/source/examples/mozilla/Transformii x/locale/en-US/" readable. "usr" and "src" are not so bad, "local" for a neophyte doesn't convey a lot of information; "m18-src" might be more readable if it were spelt out "Milestone 18 Source." Likewise "en-US."
I realize that in this case I'm picking on source code paths, which are usually set by whoever originated the source code. However, if all distributions have the same types of directories, it becomes unclear what is for what.
The trend on the MS platforms (starting with Win95) has been to spell out the software developers' name in creating a subdirectory under the "Program Files" directory...
When you don't have a CLI as your primary file system access method, so you don't have to worry about repeatedly typing the same directory name over and over, short directory names start to look a lot less attractive...
Slashdot Mirror
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.
I agree that there's a contrast, but it's not a contradiction.
WP:Verifiability and WP:RS, as the original article states, seek to anchor Wikipedia articles with externally verifiable touchstones. But there's a difference between providing an independent source for a claim made in an article and linkspamming.
There are certainly administrators who err strongly to one side or the other, but there are mechanisms to correct against admin bias.
Address space layout randomization and data execution prevention are meant as a protection against buffer overflow attacks, in which an attacker seeks to overwrite a known address space in memory so that they can execute their own code on your machine.
These features in Windows were intended to blunt the severity of buffer overflows by making it much more difficult to exploit them consistently. Breaking it returns Vista and Windows Server 2008 systems to the same level of vulnerability to buffer exploits and other attacks that stomp on protected memory.
In other words, these attacks make Vista as vulnerable as older versions of Windows, but not more so.
According to a resolution just passed by the House, the House Judiciary Committee is now empowered to sue the White House to get Mukasey to enforce the contempt citations. Which means the prospect of a trial with testimony under oath on the subject.
Well, Amazon is making clients now. Is it possible that this is related to what Amazon is doing with Kindle?
Philip, I maintain the BoycottSony blog and would love a pointer to anything you might have to back up that statement.
Very nice--too bad there aren't other Newton users in the discussion to appreciate the joke.
Hey, that's my site! Here's a faster version of that article from my new server.
Note that I've updated the article (over two years old) to point to the Internet Archive version of the Apple salute to Jimmy Carter.
Thought this was interesting enough for comment. Still doesn't indicate how the license will be revised, but is it a step in the right direction?
An MBA is a skill set, a set of connections, and (to a certain extent) a way of looking at the world through a particular point of view. Entrepreneurship is a burning desire to build something new. They aren't opposite skill sets.
Certain MBA programs, e.g. MIT's (disclaimer: I'm currently at MIT's Sloan School of Management), can expose you to as much of the business environment around entrepreneurship as you want so that you can develop the skills to deal with VCs, patent attorneys, market analysts, companies who want to acquire you, etc. An MBA program also exposes you to business fundamentals like accounting, organizational theory, strategy, etc. so that you can develop an effective business plan--or at least know enough to recognize when your business plan goes wrong and how to fix it.
I agree with your assessment that the degree doesn't have anything to do with the spark. But I think the NASDAQ has already suffered enough from an overdose of people with good ideas and not enough business skills to build good businesses around them.
Every commercial software development project, by which I mean one that is developing a product that will be put out by a commercial company with a considerable amount at stake, cares about three things. One is cost. One is quality. One is schedule.
Regardless of what you might believe, one cannot have infinite quality and timely software delivery at a reasonable cost. Netscape/AOL product managers have an extremely difficult choice to make. Do they release Version 6.0 sometime this millennium and fix bugs later, or do they delay the release indefinitely and go on fixing bugs, adding features, and so forth until no one cares any more?
For heavens' sake, folks, you wouldn't even KNOW if IE had the same problems! Why? Because they haven't opened their bug databases!! You're hoisting the Netscape managers because you have information that Netscape, or the Mozilla project (remember, the open source project that was started by Netscape in the first place) chose to give you.
I thnk that most folks who have worked in a commercial organization would support me as I make this assertion: like any other manager, a product manager must chose to make tradeoffs between quality and the schedule. In the case of the Netscape/Mozilla project, we (the community) are farther ahead than in any other commercial software project I know: we can find out about the bugs, we can fix them, and we can make the next bugfix come out sooner as a result.
Let's stop talking about abandoning the only open-source, major-league, standards-embracing browser out there, and start pitching in and helping. And don't forget to vote tomorrow, while you're participating in the process.
Your app could probably be written to address DCOM versions of your application objects via a lighter-weight protocol such as XML-RPC (aka SOAP), so that you wouldn't need client-side COM. That could make your app a lot more flexible, so that it could run on other platforms that don't use COM, such as WAP-enabled phones...
I know, as a programmer, that using reusable services and app development frameworks is awfully tempting. You have to keep the proper perspective about whether those frameworks and services are really appropriate on the platform and for the purpose that you are trying to target.
Part of the issue is the desire to make obscure and abbreviated directory names such as "usr/local/src/m18-src/mozilla/extensions/transfor miix/source/examples/mozilla/Transformii x/locale/en-US/" readable. "usr" and "src" are not so bad, "local" for a neophyte doesn't convey a lot of information; "m18-src" might be more readable if it were spelt out "Milestone 18 Source." Likewise "en-US."
I realize that in this case I'm picking on source code paths, which are usually set by whoever originated the source code. However, if all distributions have the same types of directories, it becomes unclear what is for what.
The trend on the MS platforms (starting with Win95) has been to spell out the software developers' name in creating a subdirectory under the "Program Files" directory...
When you don't have a CLI as your primary file system access method, so you don't have to worry about repeatedly typing the same directory name over and over, short directory names start to look a lot less attractive...