Containers are a revolutionary application packaging and runtime technology.

On the packaging front, we conveniently bundle application code and dependencies into an image. As well as code and dependencies, the image contains the commands required to run the application. This has allowed containers to hugely simplify the process of building, shipping, and running applications. It has also overcome the infamous “it worked on my laptop” issue.

However, containers also make running dangerous code easier than ever before.

With this in mind, let’s look at some ways we can secure the flow of application code from a developer’s laptop to production servers.

Image repositories

We store images in registries, and registries are either public or private.

Note: Each registry is divided into one or more repositories, and we actually store images in repositories.

Public registries are on the internet and are the easiest way to download images and run containers. However, it’s important to understand that they host a mixture of official images and community images. Official images are usually provided by product vendors and have undergone a vetting process to ensure certain levels of quality. Typically, official images will; implement best practices, be scanned for known vulnerabilities, contain up-to-date code, and be supported by the product vendor. This is not the case for community images. Yes, there are some excellent community images, but you should practice extreme caution when using them.

With all of this in mind, it’s important that you implement a standard way for developers to obtain and consume images in your environments. It’s also vital that any such process be as frictionless as possible for developers – if there’s too much friction, your developers will look for ways to bypass them.

Let’s discuss a few things that might help.