How to Make Your CSO delighted with Your Open Source choices
Choosing the right open source component
It is almost impossible to find developers that do not use open source (or OS) components in their software. According to a report made last year by Synopsis, out of the 1,100 code bases that were audited in 2017, 96% contained OS components, with an average of 257 components per software. Their popularity is a result of the many benefits they hold for developers. Using them can shorten and simplify software development, and they are also free. However, they can pose a significant risk to your software. Keep in mind that 78% of software in the mentioned report contained at least one vulnerability that exposes them to various threats such as denial of service attacks and data breaches.
There is a large variety of OS components out there. Since OS components are such an integral part of software development but at the same time can also carry a serious risk, it is crucial to know how to choose the right components for you. Taking the time to select the right component can save you a lot of trouble down the road.
7 tips for choosing OS components
By properly monitoring and managing the OS components within your software you can make sure they are both effective and secure. However, the best approach to adopt is to avoid risky or poor quality components altogether. You can achieve this by closely examining the components to make the best choice.
We gathered seven tips that will make it easier for you to choose the best OS that will keep your software safe, your development process effective, and your CSO satisfied:
Consider popularity - crowd wisdom is important and there is a good chance that popular components are also in good quality. Additionally, they probably have a lot of support from the community. Still, popularity alone is not a good enough indication for quality. The best example is the infamous Equafix breach. It is one of the biggest data breaches ever made exposing personal information of more than 100 million people. This was a result of a vulnerability in a popular OS component. Despite the well known Apache Struts vulnerability, it is still quite popular today.
Make sure the community is active - a large community that uses a component is good, an active community is better. Look at the number of commits made for it over time. This can be a very good sign of good quality because it means that people not only used it since the time of its release but are actually working to fix and improve it. Remember that once you choose and use a component you will have to regularly update it to avoid problems. An active community will be useful for helping you deal with bugs you will encounter along the way.
Search for documentation - you should look for both user and developer documentation. This will help you better understand the code and more easily modify it for your needs. This is can also be a sign of the efforts made by the developer and the commitment of the community. Look for indications for the quality of documentation like coding examples, clear explanations, bits of codes with helpful comments, etc.
Check databases for reported vulnerabilities - vulnerabilities are more common than a lot of developers think. According to the report mentioned above in 2017 alone, 4,800 OS vulnerabilities were reported. OS communities are very active and fast when it comes to finding and fixing vulnerabilities. Before choosing components, look at databases like the National Vulnerabilities Database and also search the OS community to make sure that there are no reported vulnerabilities in the component you are about to choose, or that previously reported vulnerabilities have fixes available for them.
Look at features - each component you use serves a certain purpose. Don’t let a feature heavy component lure you into using it. A component might have an impressive amount of functionalities that are not relevant for your needs. See what software has features that serve your intentions best.
Be aware of licenses - similar to commercial software, OS components have licenses. Although they are free, in order to use them you will often need to fill out specific requirements. Make sure that you are both willing and able to meet these demands. For example, it is a common OS requirement to publish the software code you developed, which a lot of developers might not agree to.
Examine bugs, don’t just count them - the OS code is not the only thing that is published, the reported bugs are too. Use the available information to look at the published bugs but remember that it is not just about quantity. Try to understand the severity of those bugs and also look at how fast the community managed to issue a fix for them.
You will want to use OS components in your software at some point. It is important to manage and update existing components but the most effective thing you can do is to take the time to examine your options in order to make the right choice. By being aware of the importance of your choice you can easily do it. Examine the different aspects of these components including their popularity, the features they have, and the severity of bugs they contain. These steps are guaranteed to make your CSO delighted with your choices.