1. Clear description of every feature and requirement in system.
2. Mathematical spec of those where English ambiguity could effect results.
3. High level design with components that map 1-to-1 to those.
4. Low-level, simple, modular code mapping to that.
5. Source-to-object code verification or ability to generate from source on-site.
What people in faux security mocked as mere "paperwork" or "red tape" were actually pre-requisites for defeating subversion my mentally understanding a system from requirements all the way to code. A problem like this would've been impossible in such a system because it would be beyond obvious and probably unjustifiable with requirements tracing.
Every story like this further validates the methods that consistently produced systems without all the security problems plaguing modern security products. Situation isnt inevitable or even necessary: merely an inversion of scientific method where security companies and professionals consistently refuse to use what's proven to help and reuse tactics proven to fail. It's gotta stop.
That it wont is why I favor liability legislation tied to a reasonable baseline of practices. We can use an inexpensive subset of what worked in highly assured systems. 80/20 rule. Baseline would look more like Secure64 or HYDRA firewall than shit like Fortinet and Juniper. Hackers would work for exploits. I know Im dreaming, though, as DOD and NSA just dropped mandate to EAL1 w/ 90 day review for some stuff. (Rolls eyes).