This is why high-assurance security products were&#x2F;are required to have:<p>1. Clear description of every feature and requirement in system.<p>2. Mathematical spec of those where English ambiguity could effect results.<p>3. High level design with components that map 1-to-1 to those.<p>4. Low-level, simple, modular code mapping to that.<p>5. Source-to-object code verification or ability to generate from source on-site.<p>What people in faux security mocked as mere &quot;paperwork&quot; or &quot;red tape&quot; were actually pre-requisites for defeating subversion my mentally understanding a system from requirements all the way to code. A problem like this would&#x27;ve been impossible in such a system because it would be beyond obvious and <i>probably</i> unjustifiable with requirements tracing.<p>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&#x27;s proven to help and reuse tactics proven to fail. It&#x27;s gotta stop.<p>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&#x2F;20 rule. Baseline would look more like Secure64 or HYDRA firewall than shit like Fortinet and Juniper. Hackers would <i>work</i> for exploits. I know Im dreaming, though, as DOD and NSA just dropped mandate to EAL1 w&#x2F; 90 day review for some stuff. (Rolls eyes).