The principle of immutability

The other day I was writing about the problems that generate images for us for on cybersecurity monitoring and a person from this network wrote to me privately to say that it was not a problem that they update like the rest of the systems and that's it. Well I don't agree with his point of view and that's why I'm going to try to explain myself.

One of the great advantages that we The principle of immutability is the principle of immutability. It used to be very common for developers to generate their code in a development environment with specific characteristics, it to pre-production, which was not exactly the same as development, and finally it would go to production which also had a different configuration, this whole process meant that developers had to "tweak" their code at every stage.

With the advent of containers this was solved, as an image is the same from start to finish that creates the microservice. The developer downloads the image with certain characteristics, if he has a development environment he hosts it there, otherwise on his own machine. When you have it ready, you upload the image to pre-production where the tests are performed and it is verified that it works and goes to production, all very simple and the magic is that from start to finish the development has been in the same environment. This would be the principle of immutability (note: developers should not install anything different from what comes in the image, even if they beg you to say no 😉).

If we update in production (this would be quite kamikaze) or in pre-production an image, we will encounter the same old problems, the code may have to be reworked, and if the image the developer is working with was not secure from the beginning, the problem is inherited.

So what I was trying to convey is that, in an ideal environment, companies should have a repository of approved and certified images, with an image update lifecycle that allows them to go into production with a optimum safety level. This would mean that every time a code or service is updated it would arrive at a new image to already patched production, as the developer would always be obliged to build the new version on the latest repository image. Developments are usually alive and improve/grow over time, which is why this life cycle is proposed.

There is no alternative text for this image

This is in the ideal world, which will hopefully soon be less ideal and more real.

José María Pulgar

José María Pulgar

CISO & Cybersecurity Tech leader at Bosonit

You may be interested in

Take the leap

Contact us.