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 KitchenI’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 CxSCA) interoperate 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.