In reading publications recently released by FS-ISAC and SAFECode on vendor management and third-party risk, I am pleased that the industry is finally coming together. We seem to finally agree on the obvious need to assess the processes under which software is made and not a particular end result. If “penetrate and patch” had any positive effect on software quality, we would have no defects left on planet Earth given how much testing has been done over the past 50 years.
Two years ago, Synopsys created a nonprofit, the Software Security Vendor Assessment Center (SSVAC), to help FS-ISAC members share vendor assessments. The SSVAC Board also agreed that the only way to really determine the health of software is to measure the process under which it is made.
Think of it this way, the food safety inspector wouldn’t go to a restaurant and taste the food to tell if it was safe. Instead, they would verify that all the controls in the kitchen have been followed. They would check the logs on the refrigerator for consistent temperature, make sure staff are following the hand washing requirements, check the food preparation area to ensure the chefs are using best practices, and so on. As they learn new ways to keep customers safe and find flaws in old ways, the food safety industry will update their process assessments. But they would not just taste the food and see if they spend the next few days in the restroom as a way to tell if the restaurant has solid, repeatable processes.
The same holds true for software. Testing the end result as the only means of verifying software quality makes no sense. Proper, mature, secure SDLCs test throughout their process using methods such as dynamic and static scanning, penetration testing, architecture analysis, and other controls to ensure a high quality and secure product emerges from the assembly line. Both the SAFECode and FS-ISAC publications encourage these types of controls along with proper policy, standards, and governance. So we have moved from tasting the food to verifying how it is made. Woohoo!!
I could not be happier that all three groups, the SSVAC, SAFECode, and FS-ISAC see the benefits in verifying the process under which software is built—the secure SDLC.
I’m also glad to see that all three reference the BSIMMsc as a measuring stick to help with that verification. Although I understand SAFECode would like to go broader and find a way to measure against an international standard such as the evolving ISO 27034, we could use the BSIMMsc as a neutral starting point. It is not founded in any prescriptive methodology, but is purely a measuring stick to measure any methodology.
Now that we have a common stake (or should I say measuring stick) in the ground, we can all come together and make it better. Given that we all agree on what to measure, it shouldn’t be too hard to do process improvement on the stick.