A typical business application today contains far more borrowed code than written code: frameworks, libraries, plugins, each maintained by someone else and each a potential entry point when a vulnerability is found. This is not a flaw in modern development. It is the deal. The deal only stays good if the borrowed code stays current.
The uncomfortable pattern in real-world breaches is how rarely they involve anything novel. The overwhelming majority exploit vulnerabilities that were publicly known, with fixes published, sometimes years before the incident. The attacker did not out-engineer anyone. They arrived after the fix existed and before it was applied, and that window was left open by a decision, or the absence of one.
Treating updates as security work changes how they are run. Automated scanning flags known-vulnerable dependencies on every code change, not once a year. Routine updates land on a schedule, small and boring. Critical advisories have a defined response time measured in days. None of this is sophisticated. All of it is the difference between reading about an exploit and experiencing one.
If you own software and want a single question to ask your vendor, make it this: when a critical vulnerability is announced in something we depend on, how do you find out, and how fast is it patched? A good shop answers with a process. A shrug is also an answer.
