A Security Lesson From 1986
The first computer virus appeared in 1986.
It spread through floppy disks passed between people.
No automation.
No scale.
Only trust and habit.
Fast forward.
We still share.
We still click.
We still assume safety.
Most security failures start with user behavior.
Build for that reality.
What stood out to me is how timeless these lessons are. Even today, many failures come from assumptions that no one revisits and systems that work fine until they don’t. The tech changes, but the failure patterns don’t.
True. Most failures come from assumptions nobody revisits.
The tech changes. The patterns stay.
Exactly. What usually changes is the tooling and scale, but the blind spots stay the same. If assumptions aren’t periodically challenged, systems just fail in more complex ways instead of fewer.
This kind of historical perspective is really valuable — the Hacker Manifesto and other events from the mid-80s remind us that security isn’t just about technology, it’s about mindset and understanding attacker thinking.
For developers, one practical takeaway I often see is that trusted assumptions become the weakest link. What we assume is safe often ends up being the first place attackers look, and threat actors often exploit those same assumptions repeatedly.
Curious — in your own work, have you found that specific legacy assumptions (trust models, authentication flows, dependency trust, etc.) were bigger security issues than new vulnerabilities introduced in recent code?
Yes. Trusted assumptions cause more damage than new bugs.
Implicit trust in inputs. Overconfidence in auth flows.
Dependencies assumed safe because they worked yesterday.
Attackers go where nobody looks anymore.
That pattern shows up again and again.
Well put.
I’ve seen the same pattern — once something becomes “invisible infrastructure,” it stops getting questioned, and that’s exactly when it turns into an attack surface.
Security failures rarely come from what’s new — they come from what everyone stopped re-examining.