SBN

The Open Source Cookbook: Prepping Your Kitchen

Over the course of this adventure into the culinary world of software development, we have drawn comparisons between open source software and cookie recipes, and equated open source risks to spoiled ingredients. When cooking, it’s imperative that we prep our kitchen properly, stocking the tools and equipment, getting our timing and steps in order, soliciting any extra hands we may need, and cleansing everything of dirt, dust, and dog hair that may have wafted onto it throughout the day. As you might have guessed by now, I’m going to cleverly connect this to software; just watch.

The Proverbial Software Kitchen

I’ve lived a few places throughout my life, and traveled to a few more. In that time, I’ve used my fair share of kitchens. All had some kind of refrigerator and cabinetry to keep my ingredients before cooking. All had some kind of oven, stove, or heating elements to encourage those chemical reactions that make much of my food marginally more edible. I’d add some pots, pans, utensils, gadgets, and dishcloths for cleaning in the sink. With a little bit of forethought, I was prepared to assemble any recipe my inventive heart desired.

As with cooking, software development requires a well-equipped “kitchen” with tools, methods, and processes firmly established to create stable and secure software from an eclectic mix of custom code and open source components. Perhaps the “refrigerator” and “cabinetry” are your code repositories, which may be internal resources, commercial solutions you’ve licensed, or public resources like GitHub, for example. Maybe your “pots and pans” are package managers and build tools. Maybe your “oven” is your testing or staging environment. Perhaps your utensils are IDEs, and your gadgets might be your application security testing solutions. Regardless, your developers are making use of a rather complex software development environment, with many aspects which must be configured and maintained to produce “edible” software.

As we proceed, consider how your organization and dev teams have structured your software kitchen. Consider, as well, how you go about sanitizing this kitchen, testing the food your chefs put out, and what standards you must adhere to in order to keep that kitchen open and to keep your customers safe.

Kitchen Gadgets for Application Security Testing (AST)

I’m the first to admit it: I can’t walk down the kitchen aisle of the local home goods store, or walk past the nearest shopping outlet’s kitchen supply store, without spending at least ten minutes examining the purpose-built gadgets. I have a tool that ONLY shreds leafy herbs, a manual juicer that has a built-in spray nozzle, a double-sided melon baller for all that melon I thought I’d eat one day; these have proven wildly superfluous. I have a meat thermometer for cooking proteins, a candy thermometer for my ice creams and fudges, and a moisture sensor for delicate pastries and soufflés; these have proven wildly critical to each and every dish. They keep me safe from eating undercooked meat and they keep my dishes stable.

The tools and gadgets your developers, security, and DevOps teams use are instrumental to the performance, stability, and security of the software your organization publishes. Because your software “recipes” use a mix of custom code and open source components, the application security testing “gadgets” you use need to be purpose-built to identify, triage, and remediate any issues in whichever type of software and code they examine.

For many organizations, their software kitchen is stocked with these essential security testing tools:

  • Static Application Security Testing (SAST) – Identifies vulnerabilities and weaknesses in the custom code your developers write. Some SAST solutions (like CxSAST) even recommend the best fix location to optimize the efficacy and efficiency of your developers’ efforts.
  • Software Composition Analysis (SCA) – Identifies open source components used within the scanned software, identifies any associated vulnerabilities that have been published against them, and provides other risk insight and relevant remediation guidance. Some SCA solutions (like CxOSA) integrate and correlate data with SAST solutions to better-assess exploitability, examining if vulnerable components are actually called by the application.
  • Interactive Application Security Testing (IAST) – Examines running software in your testing environments, looking for activities and data processing methods within the software that can leave it vulnerable to exploit or that puts sensitive data at risk of compromise. Some IAST solutions (like CxIAST) leverage source-level knowledge of the software structure to improve the accuracy of the testing results.

These are the essential application security testing tools every organization needs to be confident that they are evaluating their software for the vulnerabilities and weaknesses that put them most at risk. If your software kitchen doesn’t have these, I strongly recommend you get them.

Keeping Your Software Kitchen Up to Snuff

I like my kitchen clean; I think most people do. I may have a slightly uncommon compulsion to clean while I cook, so I have less to take care of after I’ve prepared my meal. But I share a seemingly universal understanding that, for my food to be clean and safe, my kitchen needs to be clean and safe. While I have established standards for my personal kitchen, restaurants and packaged food manufacturers are subject to a presumably superior level of scrutiny from regulatory agencies and governing bodies (e.g., the U.S. FDA). If these commercial kitchens don’t adhere to the established requirements, they can be audited, fined, or even forced to close for an indeterminate amount of time.

Organizations who create software are often subject to similar external and internal standards and requirements. It may be that your organization has committed to upholding SLAs to customers and internals stakeholders. It may be that your organization is subject to data protection requirements (e.g., E.U. GDPR, PIPEDA, etc.). In any case, it’s important that you understand which standards and regulations your organization is subject to, and ensure you have the software security testing solutions in your arsenal to be able to support your efforts.

Use Your Tools While Cooking, Not After

Lastly, take a look at your software kitchen (your development environment, CI/CD pipeline, and DevOps practices) and evaluate how you have integrated those necessary gadgets along the way. You shouldn’t wait until you’ve taken the steak off the grill and plated it to check the temperature. You shouldn’t wait to add your egg/sugar mixture to your warming milk when making ice cream (I did this once and ended up with a lovely batch of French Vanilla scrambled eggs). And you shouldn’t wait until the security testing phase to identify vulnerable open source components within your software. Instead, use the right gadgets (AST solutions) while you’re cooking, not after the dish is complete.


*** 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/10/10/open-source-cookbook-prepping-your-kitchen/