When a breach makes the news, the instinct is to imagine a sophisticated, never-before-seen exploit. The reality is more mundane and more fixable: in the large majority of incidents, attackers used a vulnerability that already had a patch available. The problem wasn't knowledge. It was time.
The window that matters
Every vulnerability has a lifecycle: it's discovered, a fix ships, and, eventually, that fix reaches your machines. The dangerous period is the gap between the fix existing and the fix being deployed everywhere it's needed. Attackers watch patch releases closely, because a released patch is effectively a map of what's now exploitable on anyone who hasn't applied it.
For OS updates, that window is often manageable. For the third-party software that runs on every endpoint, browsers, runtimes, PDF readers, archive tools, it's frequently much wider, because those updates fall outside the tooling most teams rely on.
Why the gap persists
- Fragmented tooling. The OS has one update mechanism; hundreds of apps have hundreds of others.
- Manual packaging. Someone has to find, test, and push each third-party update, so it slips.
- Fear of breakage. Without staged rollouts and rollback, patching feels risky, so it's deferred.
Closing it
The gap closes when detection and remediation are connected and automated: continuously inventory what's installed, prioritize by what's actually being exploited, and ship the fix on a schedule with rings and rollback so it's safe to move fast. That's the loop SecTeer is built around, and, not coincidentally, it's also what NIS2 expects you to be able to demonstrate.
You rarely need to out-run a zero-day. You need to stop losing to the patch that shipped last month.