It is one of the greatest failings of our industry that we are apparently incapable of constructing programs that are in any sense "complete" due to requiring v

It is one of the greatest failings of our industry that we are apparently incapable of constructing programs that are in any sense "complete" due to requiring vast amounts of upkeep just to ensure their most basic possible property: that their semantics are defined completely by their source code and not inputs (as is not the case with programs containing remote code execution or escaping bugs like SQL injections, XSS, etc). This constant upkeep not only has an enormous cost in terms of time spent modifying these programs to move them asymptotically closer to a version with clearly defined semantics, but (unlike other classes of bugs which involve incorrect behavior that do not have implications for security) produce an air of mistrust and a general malaise and lack of confidence in all software. One direct implication of this fact, for programs which must be constantly updated to fix their security flaws, is that because the only semblance of trust and security you can obtain in using this software comes from its popularity and reputation (because these things generally mean a large amount of resources can be spent auditing and testing ("many eyes make all bugs shallow"), and because a large userbase means that any bugs found will be more valuable and more difficult to find, and thus less likely to be used against people who are not profitable to be hacked, which is most people), viably forking large projects becomes impossible without a similar or proportional amount of resources to the original project. Without that, having confidence in the new project becomes much more difficult, because you cannot receive an assurance that bugs found in the original project will be fixed in the fork, and because bugs found in the fork might be easier to find (because of less thorough testing, because of fewer resources) and so of less value, and so have a higher chance of ending up in the hands of low-level skiddies who might use them even less responsibly than e.g. the NSA (who has never directly installed ransomware on anyone's computer, that I know of). None of this of course is mentioning the effect this culture of fear and mistrust (and its basis in reality) has on computer users who truly are valuable targets, and must use computers to do their job knowing full well that they are a mire of both intentional and unintentional security vulnerabilities and that somewhere out there exists a string of exploits that can be used to exfiltrate their IP address and send them straight to the gulags. Another cost of this unfortunate facet of computer programming is that for programs which cannot be directly updated (for example, their source code is not available), modifying them so that they are closer to a version with clearly-defined semantics is extremely difficult, involves specialized skills which are not possessed by most programmers, and generally just doesn't happen very often. Although one could also make this an argument in favor of source code availability, in any case this is a very common occurrence. So, I don't think at all that the problem is this culture of foolishly thinking that we actually know how to write programs - the problem is that we can't. The solution then, at least in the long term, is learning how to write complete programs that do not require constant adjustments in order to ensure clearly defined semantics, not to just figure out how to stay afloat better in this horrifying quagmire of shifting quicksand that we've built the foundations of computer software on.