Software Development and the Near-Ubiquitous Acceptance of Mystery Meat

In order for an amusement park ride to operate, it needs to maintain maintenance records and have safety inspections.In order for a restaurant to operate, it needs to pass food inspection processes.Such examples abound everywhere.The world's top chefs covet Michelin stars.The world's best athlete covet Most Valuable Player awards.The world's top filmmakers covet Academy Awards, for which the achievement of or even nomination for immediately and forever becomes an adjective attached to the filmmaker's name.What exactly do software developers strive for?Given the prevalent and rampant presence of vulnerabilities in today's software [1], it would seem that today's software developers aren't even seeking the equivalent of a passing grade by a restaurant safety inspector let alone a Michelin star.But rather than focusing exclusively on fine dining, let's examine a more pedestrian measure: when was the last time that you intentionally ate at a even a hot dog stand that had anything other than an "A" safety inspection rating displayed?With software, when security evaluation occurs at all, how often is it at the outset and continuously performed throughout, before code is even committed to a version control repository, rather than at the very end when the static analyzer reports tens of thousands of alerts, only to be subsequently ignored?And yet, would the head chef wait to sample the Crpes Suzette until after the Grand Marnier has been ignited?There's no question that software development is hard.Nobody would suggest otherwise.But why do most software developers aim so low on actually testing quality?Where are the software developers aiming for true excellence?The best we can often seem to expect of software is akin to a meal from a fast food restaurant: it looks edible and we hope (but we don't have much evidence) that it won't make us sick.But even a comparison to fast food is on the optimistic side -it's not at all clear that even the equivalent of an "A" grade food safety inspection is what we can expect from the average software product.Approaches exist to benchmark and improve security practices used for software development, such as Microsoft's Security Development Lifecycle (SDL) [2] and NIST's Secure Software Development Framework (SSDF) [3].Undoubtedly this guidance helps, to the varying degrees that it is adhered to.But what information do people who use, rely on, or are impacted by software security failures have on that degree of adherence and the way that adherence changes over time?Moreover, these frameworks are often either written at a very high level, raising questions about which specific standards are actually being adhered to, or on the flip side, are in such exhaustive detail, that they raise questions about which elements are being ignored because few organizations are likely to be doing all elements at high levels of proficiency and success.To be sure, there are sectors in which software development is subject to some form of required standards, for example, based on use of the Common Criteria (ISO/IEC 15408) or FIPS 140 for cryptographic modules.However, adoption of such approaches is highly limited to specific sectors and targets, and the level of assurance provided is based on the definition of the Protection Profile,