A friend told me something in a beer garden in Germany about 12 years ago:
“Florian, don’t overthink whether this specific service is exploitable. The stuff is broken. Plan accordingly.”
He meant software.
Most software looks stable because it runs under normal conditions. Look closer and you find memory leaks, parser bugs, unhandled input, bad defaults, forgotten modules, weird edge cases.
Now we have better fuzzing, better automation, AI-assisted auditing, variant hunting, more exploit dev, more eyes on everything.
So yes, patching matters.
But in a world where every kind of internet-facing software keeps producing fresh RCEs, you also need the boring stuff:
1. Reduce the attack surface
- expose fewer services
- disable unused modules, plugins and features
- don’t publish admin interfaces unless they really need to be reachable
2. Limit the blast radius
- run services with least privilege
- isolate internet-facing systems
- avoid shared accounts and credentials
3. Build visibility and control
- collect useful logs
- monitor weird errors, crashes and “should never happen” events
- keep enough data to investigate later
- run regular compromise assessments
Assume exposed software is brittle.
The stuff is broken. Plan accordingly.
You just patched last month’s Nginx vulnerability that was actively exploited in the wild?
It’s already time for a fresh 0-day RCE.
The whole world is basically “pwned-by-default”, patching vulnerabilities before they’re exploited feels like a Sisyphean task... đź«