Cooking up secure code: A foolproof recipe for open source
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 the ground up.
Indeed, this practice has become so common that today the average application is composed mostly of open source libraries, with these components making up more than 80% of the average codebase.
But the widespread use of open source code has certain 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 to gain access to networks, intercept sensitive data, and influence or impede an application’s functionality. 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 visualize an approach to how to secure software in the age of open source, as a combination of selecting the right recipe, understanding your ingredients, and having the right tools and utensils in your “kitchen” to get the job done.
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 organization 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. A good example of this is the difference between Red Hat Enterprise Linux and Ubuntu. In practice, these slight differences can add up to create a significant impact on functionality, compatibility, and security, and thus must be considered when researching which “recipe” to follow.
Choosing the best ingredients
As mentioned, vulnerabilities in open source components mean vulnerabilities in the software that leverages them. Therefore, just as it is important to know 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. Ingredients that have gone bad can ruin what would otherwise be a perfectly good dish and, likewise, vulnerable open source components can ruin an otherwise secure application.
As with ingredients and food products, some vendors will issue recalls for bad batches. When using open source libraries from known organizations 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 maximize quality. The equipment in a developer’s software “kitchen” is a key factor in whether or not 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 analyzing software, detecting the open source components within, and identifying associated risks, including security risks and license risks. Security risk refers to vulnerabilities that can be tracked in publicly available databases such as the National Vulnerability Database (NVD) or discovered by private security research teams. License risk can be a function of unfavorable license requirements associated with a particular component, the failure to comply with license requirements, or conflicts between unique licenses for different components within the same software project.
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, developers leveraging open source code can be sure that the software they ship will be much more secure.
Secure software and open source: 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. Applications must be reviewed, then reviewed again to ensure that nothing has been missed.
Even if a developer follows all best practices, vulnerabilities can still persist, or new vulnerabilities may emerge for previously released software for where there had been no vulnerabilities. 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, increasing their open source security and serving software masterpieces in no time.