‘The Immutable Laws of Security’ at 25: 5 corollaries for a new era

This year marks the 25th anniversary of “The 10 Immutable Laws of Security,” a seminal bit of cybersecurity wisdom from Microsoft’s Scott Culp. Written in the era of the ILOVEYOU worm, when cybersecurity was just emerging as a credible tech discipline, the list inspired a whole generation of pathfinding security professionals. 

Much has changed in technology and business since the laws were written. Software ate the world, and AI is eating development. And while endpoints and networks still need strong protections, the emphasis today is more on software supply chain security than on antivirus capabilities. Can “immutable” still describe laws that were written for a nascent industry a quarter of a century ago?

According to veteran security leaders, Culp’s laws remain very relevant but not as spot on as they once seemed. Here’s what you need to know about Culp’s Immutable Laws of Security in the software supply chain security era — and some additions to bring them up to date.

Download Today: The 2025 Software Supply Chain Security Report

Once immutable, always immutable

The more things change, in the famous phrase of Jean-Baptiste Alphonse Karr, the more they are the same. And as a body of work, the underlying principles of the Immutable Laws remain, well, immutable. The application security (AppSec) pro Ross Haleliuk wrote recently in a probing retrospective on the laws:

Running untrusted code, mishandling keys, weak identity practices, insider risk, the illusion of perfect tech — none of the issues Microsoft called out have gone away. 

Haleliuk dove into the laws to show that the security industry still “continues to hope for magic solutions, products, platforms, or compliance checklists that will ‘take care of security’ only to realize that’s not how security works.” 

To Haleliuk and others across the industry, like Chris Hughes of Aquia, the genius of the Immutable Laws was that they succinctly drove home the point that security isn’t a technical problem. 

As Microsoft pointed out way back, the origin of security issues is much more closely related to the nature of systems, people, and trust than to any specific code or bugs, almost like universal laws of nature. What’s ironic is how painfully true they are, but we still counterintuitively violate their principles.

Chris Hughes

Though the principles behind these laws remain true, it’s helpful to reframe them in the context of today’s AppSec risks. What’s more, important corollaries are starting to emerge about AppSec truths in the era of software supply chain security. Here are five adapted to how we deliver secure software and secure systems today. 

1. If a bad guy can alter the code in your software, it’s not your software anymore.

This corollary is based on the principles of Immutable Laws Nos. 1 and 4:

• No. 1: If a bad guy can persuade you to run his program on your computer, it’s not your computer anymore.
• No. 4: If you allow a bad guy to upload programs to your website, it’s not your website anymore.

Attackers still come up with myriad ways to trick users into running untrusted programs on their endpoints and to inject malicious code onto sites and into apps. But possibly even more damaging these days is how easily the bad guys can secretly turn any trusted software, plugin, extension, API, or AI agent into something inherently untrustworthy by subverting the software supply chain.  

The original Immutable Law No. 1 equated running software on your computer to accepting and eating a sandwich. If a stranger hands you a sandwich, you’re probably not going to eat it. But that simplistic trust dynamic seems almost quaint in today’s complicated supply chain. 

We rampantly consume open-source software with little insight into its true provenance and origin or its safety, at a pace that is growing more than ever.

Chris Hughes

Not only is it difficult to enumerate your own code, but it becomes even more complicated when considering the downstream layers of dependencies, said Haleliuk.

To borrow Microsoft’s analogy: it’s like buying a sandwich from a top restaurant you trust, only to get poisoned because the meat supplier, halfway across the country, maliciously tampered with the ingredients. You didn’t eat a stranger’s sandwich, but you still got burned because trust now extends deep into the supply chain.

Ross Haleliuk

2. If a bad guy can compromise the control plane, it’s not your environment anymore.

Immutable Law No. 2 says, “If a bad guy can alter the operating system on your computer, it’s not your computer anymore.” But as Haleliuk points out, the cloud has greatly expanded what we define as an operating system. And of course, much of modern software doesn’t run on our own computers anymore. But they’re still our systems and our environments, so the relevant aspect of this shifts to the control plane.

“In cloud environments, compromise of the control plane or metadata APIs can often have the same effect as altering the OS directly: total takeover of workloads,” Haleliuk said. He explained that the way modern infrastructure is built makes the idea behind the original law more pressing than ever. 

Infrastructure as code can accidentally propagate malicious changes at scale, CI/CD pipelines often have write access to system configurations, and misconfigured agents can be exploited to gain system-level privileges.

Ross Haleliuk

3. A system is only as secure as the admin account is trustworthy.

This corollary is based on Immutable Law No. 6, which states, “A computer is only as secure as the administrator is trustworthy.” That remains a relevant rule of thumb, but we’re expanding it greatly with this corollary because of two prevailing factors. First, the idea of who an admin is has changed significantly in the last 25 years. There’s no longer a singular IT admin or IT admin team. Today, administration, like the systems themselves, can be scattered across many tech teams and many business units, Haleliuk said.

Administrative privileges are scattered all over — across cloud platforms, SaaS tools, CI/CD pipelines, and identity providers, and few organizations have a good grasp of who can do what in their environment.

Ross Haleliuk

Even more difficult: A lot of administrative actions are not directly triggered by people at all. Automation and AI agents, working across development pipelines and beyond, use admin privileges to carry out sensitive tasks constantly. That creates an attack surface ripe for exploitation that is only going to grow in size and complexity as agentic AI takes off. 

Compromised admin secrets are particularly damaging if they’re tied to access to open-source software and code used by many developers. ReversingLabs researchers noted that leaked developer secrets increased across almost every open-source package manager in 2024, exposing access to the building blocks of much of the modern supply chain due to untrustworthy privileges. These kinds of leaks make it trivial for attackers to implant backdoors and take over software at scale. 

As RL research experts recommend in the 2025 Software Supply Chain Security Report:  

To stop the flow of secrets and sensitive information to open-source platforms, development organizations are urged to clean up their code storage, access control, and secrets rotation policies — and to craft a unified secrets management strategy that includes regular code repository audits that look for secrets that may have accidentally found their way into publicly disclosed code.

4. An out-of-date software security tool is only marginally better than no tool at all.

The Immutable Laws were written when cybersecurity was tied up with the arms race that was escalating with antivirus and firewall rules. That’s the environment that gave us Law No. 8, “An out-of-date virus scanner is only marginally better than no virus scanner at all.” 

It sounds archaic now, but the fundamentals behind this law still hold true when broadened to include using any outdated security tools and practices in the developer’s tool stack. Clogging the pipeline with outmoded tooling that doesn’t mesh well with the workflow may even be worse than using no tool at all.  

I couldn’t help but think of the whole shift-left mantra, and how low-fidelity noisy tools we’ve dumped on developers that orient around non-exploited/non-exploitable vulnerability, base CVSS scores, and more feel right at home with this law. They’re purely noise and toil, and next to useless.

Chris Hughes

5: Technology is not a panacea.

Okay, if you’re familiar with the Immutable Laws, you know that this one is not a corollary at all but rather the original Immutable Law No. 10. This one is both immutable and immortal, and it remains relevant to every cybersecurity professional no matter their niche, from AppSec to identity to governance. We’re doubling down by making it its own corollary because it also remains the most ignored of the Immutable Laws, as companies still try to buy their way out of cyber-risk problems, Haleliuk said.

Technology helps, but judgment, process, and ownership still make the difference between a resilient organization and a breached one. That was the case 25 years ago, and I don’t doubt it will be the case another 25 years from now.

Ross Haleliuk