The Open Source Cookbook: Understanding Your Software Ingredients
As I introduced in my last article, where we explored the variance among open source components, distros, and forks, open source software and modern application development can be equated to baking. This analogy allows us to explore potentially complex topics through the more familiar lens of one’s unique take on popular recipes. This time, I’d like to explore the task of selecting your ingredients; a process which all great bakers are keenly focused to get right, or risk spoiling the dish entirely.
Ingredients are finicky things; some are all natural and some are synthetic, some can serve as reasonable substitutes for others (in a pinch), nearly all go bad after a certain period or under certain circumstances, and bad ingredients can put the people who eat your confections in serious risk. These poetic analogs to open source components should help you understand why it’s important to evaluate the components you and your software development teams incorporate into your applications, and fully understand their potential risks. Let’s explore further.
You’ve likely heard the old adage: one bad apple can spoil the bunch. I grew up in a place known for its apples, and it’s certainly true that my apple pies taste better with fresh apples, although that may be my subjective opinion. Sometimes, when I get my produce from a store, I’ll read the advertisements for the “organic” foods, touting their aversion to pesticides or fertilizers for their “inherent risks.” Moreover, the next time you enter your favorite grocery, look for a bulletin board alerting you of recent recalls or bacterial advisories, and the “risks” associated with the modern grocery supply chain may become a little more apparent.
Along these lines, open source components can have security vulnerabilities; some are more severe than others. It’s important to understand if there are any vulnerabilities in the components you select, because when those components get baked into your applications, they can be potential open doors for attackers. Depending on the source or origin of that component, you may get notified when they’re discovered, or you may not. As an example, components from Red Hat or Apache may yield helpful alerts when vulnerabilities are discovered, or when patches are available to remedy such vulnerabilities. Components from community-driven development groups may not have such proactive alerting, making it your responsibility to your users to identify and fix these risks, whether you have the support of the community or not.
In other words: it’s important that you have a way to identify the vulnerabilities that may be present in the components you select, how you will discover new risks as they emerge after you’ve baked them into your applications, and how you will get your developers the information they need to fix those issues. After all, there may not always be a recall issued on those bad apples in your pie.
Sometimes, a recipe may call for Crisco, while others call for shortening. Perhaps the recipe calls for Cool Whip, instead of a whipped dairy topping. Perhaps you purchase items from a bakery marked “not for retail sale”, or maybe you’ve been known to snag a free promotional sample as you walk through the store. In any event, recipes which call for brand name ingredients, or represent a brand’s special confections, are attributing some amount of success to the brand itself. When you prepare the baked goods, per the recipe, you may be free to share them without giving credit to the brands involved, or you may be obliged to attribute your success to the specific brand names included (e.g., remember the Grandma’s Cookies example I gave in my last article).
While we could equate a software component’s brand to its source or distro (e.g., Red Hat Linux), in this analogy, we’ll say that a component’s “brand” is upheld and enforced by any one of the various licenses that could be associated with them, whether it derives from a commercial open source project or a community-driven one. The licenses commonly fall into two broad categories (with many potential nuances that blur the line between them): permissive licenses, and restrictive licenses. Permissive licenses generally (although not always) place fewer and lighter restrictions and requirements on the use of the components, with which the licenses are associated. Restrictive (often referred to as copyleft licenses) often place more stringent restrictions and requirements on the use of the associated components.
There are thousands of license variants out there. We’re simply exploring the notion that you must understand the requirements established by the licenses applicable to the open source components within your software, since license violations can cause legal headaches, cost you money, or put your intellectual property at risk. Moreover, some licenses conflict, adding a layer of complexity to your software development practices as you bring in more and varied open source components from a wealth of sources.
In other words: Ensure you and your developers have a way to identify licenses associated with the open source components you use, and a way to measure the risk of license conflicts or non-compliance. If you don’t, you many find yourself in a legal battle against Grandma when you try to sell her Pecan Sandies at the local bake sale.
*** This is a Security Bloggers Network syndicated blog from Blog – Checkmarx authored by Steven Zimmerman. Read the original post at: https://www.checkmarx.com/2019/09/24/understanding-your-software-ingredients/