In programming language, there is a concept called Type Safety. Type safety means a set of rules that the language enforces to prevent type errors that a programmer may make, which may lead to unintended or unsafe access to memory.

C and C++ are not type-safe languages as the programmer has an incredibly amount of latitude to mix up values and data types. Because of weak type rules, memory attacks like buffer overflow are possible. Type-safe languages such as Java have built-in type checking and type enforcement rules. If you try to assign a value to a wrong type, like an integer to a string, such as:

String one = 1

The complier may throw an error, such as:

// Fails, Trying to put an integer in a string *(example on Wikipedia) 

When the compiler catches an error like that and the programmer fixes it, it’s one less chance for this error to lead to an attack in runtime.

Why are we talking about type safety here? Because we can actually learn quite a bit from the type safety principles and possibly apply that in a context beyond language and memory safety.

The first principle that type safety brings is that certain safety policy decisions are made upstream in development rather than in runtime. If you wait until runtime to decide whether something is unsafe, most likely you’d rely on some detection mechanism that is looking for a needle in the haystack. Even though data science has advanced a great deal, looking for a needle in the haystack is never going to be as efficient or and as effective as not allowing the needle to be in the haystack in the first place.

In other words, we should always strive for security decisions to be made upstream in the application lifecycle rather than relying on firewalls, IPS’s, and anomaly detection in runtime to hopefully spot the error. Of course, this is not always possible. But, I believe as an industry, we are not doing all that we can to push security decisions earlier in the lifecycle. In fact, we are pretty pathetic in doing that.

Containers and containerized computing make these issues more relevant now.

Containers are not new—they came from Solaris Zones and are recently made popular by Docker. What made containers suddenly the darling of DevOps is that its resurgence is perfectly timed with the need for micro-services applications and helped by the maturing ecosystem of cloud computing.

Containers are purportedly immutable, that is, the container stack is built once and run anywhere without being changed in its lifetime - the only way to update a container is to establish a new container with the updated software and kill off the old one.

This is significant because when you make the runtime image statically, encapsulating the system resources (however lightweight) that you might need in runtime and henceforth make the image immutable, you have given developers incredible power over run time behavior. And in the same time, you have in many ways diminished the need for configuration management and anomaly detection in run time. This is very much similar in spirit to type safety where safety decisions are made earlier in the application lifecycle.

Of course full immutability is not possible. It’s naïve to think we could have full immutable systems including ever-changing data and states. That means you’ll still need operational security and configuration management, but, you’ll need much less of it because a wide list of bad things simply will not happen.

Docker built a container management layer that revolutionalized the way developers can build and manage containers. But the positive impact on security, brought by containers and the immutable nature, is almost accidental. That said, many in the DevOps space are true believers that immutability will fundamentally change the game of operational security, just like how type rules changed language and memory safety.

We are probably only seeing the tip of the iceberg in terms of how powerful the Docker technology is.  It already rendered some of the traditional security mechanisms, such as agent-based and inline filtering schemes irrelevant. It may one day fundamentally change how organizations approach security in the production environment – it will be developers (oh my gosh), not your ops team or ops-only technologies, who will be the face of operational security. And that, will be an interesting day to see.