Skip to main content

Open source kitchen: A recipe for security success

(Image credit: Image Credit: Wright Studio / Shutterstock)

Open source code is just about everywhere in modern software. It’s hardly surprising: the mounting pressure to accelerate the delivery of new applications is pushing developers towards ready-made open source components that they can quickly deploy in applications as needed, saving valuable time that would otherwise be spent building a feature from scratch. As a result, it’s not shocking to hear that open source components make up more than 80 per cent of the average codebase.

But as is to be expected, the near universal move to open source code has created novel challenges for developers and security teams alike. Just like with any code, open source components can be affected by vulnerabilities which can then be exploited by cybercriminals looking for ways to infiltrate networks, steal data, or disrupt an application’s functionality. There is a key difference between open source code and custom code, though, in that open source vulnerabilities – and their exploits – are regularly published online, meaning they become a very attractive target for malicious actors.

Today’s software chefs

As any software developer will tell you, oftentimes overcoming a challenge comes down to shifting perspective on how it is being approached. With that in mind, I want to introduce my own personal approach to open source security: the Chef Analogy. Building software is like opening up a cookbook to prepare a good dish. When you’re cooking at home, you most likely employ some of your own cooking knowledge, a smattering of different recipes and methods you’ve researched, and of course, some pre-made ingredients that you wouldn’t make yourself due to time constraints and availability. 

Creating applications that contain open source code follows the same “recipe.” Taking this realisation into consideration and applying it to their work, developers should be able to properly understand the challenge of secure software development in the open source era. It all comes down to choosing the recipe, becoming familiar with your ingredients, and having every tool you need in the “kitchen” to get things done right. Let’s explore further.

Researching your recipe

When you prepare to cook fine cuisine or, in this case, an application, you are almost certainly going to look for some sort of recipe to get you started. And, as you would find while researching your options, different recipes for the same dish can vary greatly, and getting the best result comes down to choosing the best one. The exact same logic can be applied to open source components.

Regardless of whether two components have the same name, they can still be vastly different from one another, based on which organisation or developer community built them, or the various iterations which they have experienced since their initial invention. The components could be similar in purpose or functionality, but you might find there are slight differences which relate to the goals of the people that oversaw their evolution. A classic example to this point is the distinction between Red Hat Enterprise Linux and Ubuntu. While they might seem slight, in practice, these seemingly small nuances can have a massive impact on functionality, compatibility, and security. With that understood, any developer needs to know how important such considerations are when researching which “recipe” to use.

Better ingredients, better software

As noted earlier, open source vulnerabilities mean flaws in the applications that contain them. Because of this, it is absolutely essential to be certain that the “ingredients” you’re adding in when cooking are of high quality. In other words, you need to be aware of any existing vulnerabilities in the open source components you’re employing. Just as bad ingredients can ruin what would otherwise be a perfectly good delicacy, vulnerable open source components can ruin an otherwise secure application.

With any food product, some vendors will issue recalls when a bad batch goes out. That means that any organisation utilising open source libraries from known groups like Red Hat or Apache, for example, needs to keep an eye out for “recall” notices by way of alerts to new vulnerabilities or patches which address security risks. It is very common, though, for developers to find that they need a community-driven component rather than one supported by such large enterprises. In those instances, the onus of identification and remediation of any vulnerabilities can fall on your developers if the open source community is slow or non-responsive. This is no easy task, as taking on the burden of identifying and fixing vulnerabilities by developing a new component version or coding a workaround is altogether different than following a prescribed course of remediation from a software vendor or active community. Handling this process efficiently, one of the most commonly cited challenges for developers, is always going to come down to having the right tools.

Using the right tools for the job

There are countless recipes that call for the use of specialised appliances or utensils while also noting that an alternative can be used at the cost of time, efficiency, and effectiveness. In the same sense, software being developed with open source code calls for its own tools to ensure the best possible result. Thus the appliances in a software development “kitchen” are a major factor in the security and quality of any code being produced. When it comes to cooking with open source code, Software Composition Analysis (SCA) tools are often the best way to go.

SCA is defined as the process of analysing software, detecting open source components, and identifying any associated risks (including security risks and license risks). The term security risk applies to flaws that can be found in publicly accessible databases like the National Vulnerability Database (NVD), or those identified by private research teams. License risk, on the other hand, refers to potentially unfavourable or complicated license requirements for a particular component, and any associated failures to comply with license requirements or conflicts between unique licenses for different components within the same software project.

By providing insights into any associated vulnerabilities and equipping developers with actionable information around risk and remediation, SCA solutions help developers save valuable time and create more-secure software in the process. Of course, these solutions need to play well with other appliances in the kitchen, such as other security, development, and issue management tools. With a good SCA solution on hand, developers leveraging open source code can be sure that the software they serve up will be of significantly higher quality.

Creating a masterpiece

It cannot be said enough that there is no magic fix-all when it comes to software security, and there are no exceptions to that rule when it comes to open source. Securing applications will still require diligence and careful focus. Software needs to be checked, then checked again to ensure no vulnerabilities have slipped through the cracks. Even following each and every best practice, exploitable flaws can still make it into final versions, while new vulnerabilities can emerge from previously released software where there had been none before. 

Still, by heeding the advice and approach laid out above, developers should be able to tackle the challenges associated with open source software with a fresh perspective and understanding, improving application security and creating software masterpieces in no time. Now, let’s get cooking.

Steven Zimmerman, open source strategist, Checkmarx (opens in new tab)

Steven Zimmerman is an open source strategist at Checkmarx, specializing 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 organizations adopting software security best practices across their application portfolio.