I like a lot of the stuff Daniel Miessler thinks about.
He has an interesting essay about "why software remains insecure". By insecure, he means released software with known functional and technical bugs at release, and even far beyond release 1.0 and 2.0 and on and on.
Why should this be?
Miessler opines:
"... the existence of insecure software has so far helped society far more than it has harmed it"."Basically, software remains vulnerable because the benefits created by insecure products far outweigh the downsides. Once that changes, software security will improve—but not a moment before".
And if you buy that idea, then you probably understand his point that there is no real business or user incentive to repair things to a higher standard of quality. Users put up with it; projects are bound to the clock.
This process will do nicely: Develop, quickly test, release, rinse, repeat.
Domain sensitive
Of course, there are significant and manifestly important project domains where such slack in quality would not be tolerated -- could not be tolerated -- or even understood. Think: space launches of all sorts; command and control systems that are kinetically fatal in outcome; even self-driving systems.
It's not SEI Level 5!
Without a maturity model as a regulatory tool for systemic quality, other priorities dominate.
The cart and horse are in a mixed order: release, measure the temperature of users and regulators, and then fix it -- just enough. Sort of Agile that way: do enough, just enough, to pass the sprint test and move on.
Like this blog? You'll like my books also! Buy them at any online book retailer!
