Hanlon's Razor

Hanlon’s Razor advises against assuming bad faith when an outcome may be due to human error or ignorance. If a commit introduces a security hole, it’s probably a mistake, not intentional sabotage. So one responds with help and fixes, not with blame.

This doesn’t mean ignoring the possibility of malice when truly warranted (security does consider malicious actors). But for day-to-day development and operations, Hanlon’s Razor keeps you grounded: the build failed likely due to a misconfiguration, not because someone deliberately broke it.

A customer reports that your software “deleted all my data!” It’s easy to panic and think a disgruntled employee planted a logic bomb. But Hanlon’s Razor would have you first check for a mundane bug, perhaps a boundary condition in a delete function that wipes more than intended. Indeed, you find a bug where, when a user’s account name was empty, the cleanup script deleted all records. No malice, just a bug.

In security, consider a sudden spike in server traffic. Before screaming “it’s a DDoS attack!”, check first if it’s a misconfigured client spamming or a known pattern. Most weird behaviors in systems are due to mistakes, not malicious intent.