Bugs in Open Source Code
The United States software market is a $180 billion industry, and defective software costs 1/3 of that–$60 billion–every year. Software vendors have started to address these problems through the adoption of static analysis and best practices, but these processes often extend only to the code that they themselves author, not the open source they rely on.
Recent data shows that 70% of internally developed software is tested for bugs, but only 35% of third party code is tested.
As software size and complexity increase, reliance upon open source third party libraries is becoming common place. Software is no longer all developed from scratch, but is a combination of private and publicly available code.
9 out of 10 companies incorporate code from open source projects. With 90% adoption of open source, how many outdated versions of these software packages are organizations using?
4 in 10 of these companies have experienced problems related to code defects in open source third party libraries. Are the companies having a hard time staying on top of the updates that are constantly being released from the open source contributors?
Case Study
Coverity recently performed static analysis of the Android kernel and found many defects that carried a medium to severe risk:
- 57 control flow issues plague the kernel
- 36 error handling issues are evident
- 17 incorrect expressions
- 53 incidences of insecure data handling
- 23 issues with integer handling
- 83 null pointer dereferences
Although these statistics are concerning, Coverity stated that the Android kernel is recognized to be of significantly higher quality than many other open source projects which have received the same level of scrutiny.
If you use the Android kernel, your software inherits these flaws. Can you afford to inherent these flaws? If an update comes out, how are you currently staying informed of the update?
Are there bugs in open source software and third party libraries you build your product on?
Embed this info-graphic:
Keep Your Open Source Up-To-Date
SourceNinja keeps your applications optimized, secure, and compliant by notifying you to updates and changes in the open source libraries your application uses. Sign up for SourceNinja Beta and keep your code running as fast and secure as possible.
These results seem kinda one-sided. Wouldn’t it have been more helpful to compare results with closed-source equivalents?
Agreed. One issue is getting all the source code to analyze from the close-source equivalents. Since the open source is by definition publicly available, it is rather easy to scan.
If you have some companies who are willing to make their closed source available to us, we can go ahead and compare.
Its not so much comparing the closed source code, but let’s look at the cost that companies that sell s/w attribute to their defects. I am sure they collect this data.
I’m really interested to know where the nr from the cost come from.
Also what kind of development methodology was used in the projects that had these problems?
A waterfall project or a pure agile project both have a different way of dealing with risks.
Waterfall considers every step t be done perfect and by design has it harder to deal with change request.
Agile considers change part of the process and thus deals much better with changes and bugs.