The Sandpile Theory of Security

Wed, 03 Jun 2026 12:00:00 +0700

Most companies think about security the wrong way.

They think a vulnerability is a thing. A defect. A ticket. A row in a dashboard. Something with a CVE number, a CVSS score, an owner, and a due date.

This is a natural way to think, because it is how security work is usually organized. A scanner finds a vulnerability. Someone triages it. Someone patches it. The number goes down. Progress.

But this view is misleading in the same way that looking at one grain of sand is misleading if what you care about is an avalanche.

In real systems, vulnerabilities are not independent objects. They are connected. They accumulate. They interact with identity systems, deployment pipelines, shared libraries, cloud permissions, abandoned services, developer habits, and organizational incentives. A single bug is rarely the whole story. It is usually the match. The fuel has been piling up for years.

This is why vulnerability management often feels strangely futile. You fix hundreds of issues and still feel unsafe. Then some tiny thing — a forgotten S3 bucket, an exposed token, one dependency in one obscure service — causes a disaster wildly out of proportion to its apparent size.

That is not bad luck. That is the nature of complex systems.

A better model for security is not a checklist. It is a sandpile.

Network-Topology on Napat's Inverse Blog

The Sandpile Theory of Security