Since its inception, the use of open source code in modern software has become nearly ubiquitous. It makes perfect sense: facing ever-increasing pressures to accelerate the rate at which new applications are delivered, developers value the ready-made aspect of open source components which they can plug in where needed, rather than building a feature from scratch.
Of course, the widespread move to open source code has not come without consequences. As with custom or home-grown code, open source libraries can contain vulnerabilities, and those vulnerabilities may be exploited by cybercriminals targeting these components as attack vectors. Open source code is distinct from custom code, however, in that its vulnerabilities – and many exploits for them – are published online, making it a particularly attractive target for malicious actors.
Calling All ‘Chefs’
Any software developer knows that sometimes, solving a problem is as simple as changing one’s perspective on the approach, which is why I’d like to introduce the Chef Analogy. It is often said that building software is like cooking fine cuisine. When cooking in your kitchen, you probably use some of your own know-how, a combination of recipes you’ve researched, and some premade ingredients that would simply be impractical to make on your own when you can get a better version right off-the-shelf. Building software that uses open source code follows much the same formula. With this understanding, we can better visualise an approach to how to secure software in the age of open source.
Finding the Recipe
When getting ready to make a new dish, or in this case application, a common practice is to research a ‘recipe’ as a starting point. Not all ‘recipes’ are created equal, and some will yield better results than others. The same applies to open source components.
Even if two components have the same name, they can be very different depending on which organisation or developer community has created them, or the various iterations and forks which they have experienced. While they might share similar purpose or functionality, these components might contain slight changes that reflect the needs or preferences of the people who influenced their evolution.
Choosing the Best Ingredients
Similar to knowing that the ingredients you’re using when cooking have not spoiled, it is essential to understand any existing vulnerabilities in the open source components being used.
As with ingredients and food products, some vendors will issue recalls for bad batches. When using open source libraries from known organisations like Red Hat or Apache, for example, developers may receive “recall” notices by way of alerts to new vulnerabilities or patches which address security risks in the software they provide. It is quite possible, however, that a developer may need a community-driven component rather than one supported by large enterprises. In this instance, the responsibility to identify and fix vulnerabilities falls on the developers. This is much easier said than done, as it is one thing to bear the burden of identifying and resolving these vulnerabilities by developing a new component version, and it is another to communicate the need to address the vulnerabilities to everyone using the vulnerable component version. Getting this done efficiently ultimately comes down to having the right equipment on hand.
Let ‘Utensils’ Help
Just as some recipes will call for the use of a mixer while specifying that a whisk can be substituted at the cost of time, efficiency, and effectiveness, software being developed with open source code calls for its own tools to maximise quality. The equipment in a developer’s software “kitchen” is a key factor in whether the code they produce is secure and of high quality. When open source code is in use, Software Composition Analysis (SCA) tools are preferred for this.
SCA refers to the process of analysing software, detecting the open source components within, and identifying associated risks, including security risks and license risks. SCA solutions help developers by detecting open source components, giving insights into any associated vulnerabilities, and providing actionable information around risk and remediation. They also need to work well with other “appliances,” such as other security, development, and issue management tools. With the right SCA tool on hand, like Checkmarx SCA (CxSCA), developers leveraging open source code can be sure that the software they ship will be much more secure.
Cooking Up a Masterpiece
It is always important to acknowledge that there is no silver bullet when it comes to software security, and open source is no exception. Keeping software secure is always going to take diligence and careful attention. By following the advice laid out above, developers using open source code have a greater chance to be able to approach the challenge with a fresh perspective and understanding, up-leveling their open source security and serving software masterpieces in no time.
Steven Zimmerman is an open source strategist at Checkmarx, specialising in Software Composition Analysis and Application Security Testing services. He is focused on deriving a clear vision for efficient DevSecOps among the world’s leading enterprises, and organisations adopting software security best practices across their application portfolio.
