Use multi-stage builds

The multi-stage build is a way of eliminating unnecessary contents in the final image. An initial stage can include all the packages and toolchain required to build an image, but a lot of these tools are not needed at runtime. As an example, if you write an executable in Go, it needs the Go compiler in order to create an executable program. The container that runs the program doesn't need to have access to the Go compiler. In this example, it would be a good idea to break the build into a multi-stage build: one stage does the compilation and creates a binary executable; the next stage just has access to the standalone executable. The image that gets deployed has a much smaller attack surface; a nonsecurity benefit is that the image itself will also be smaller, so the time to pull the image is reduced.

Avoid unnecessary code

The smaller the amount of code in a container, the smaller the attack surface. Avoid adding packages, libraries, and executables into an image unless they are absolutely necessary.

GitOps is a methodology in which all the configuration information about the state of a system is held under source control, just as the application source code is. When a user wants to make an operational change to the system, they don't apply commands directly but instead check in the desired state in code form (for example, in YAML files for Kubernetes). An automated system called the GitOps operator makes sure that the system is updated to reflect the latest state as defined under code control.
This impacts security in significantly beneficial ways. Users no longer need direct access to the running system because everything is done at arm's length via the source code control system (typically Git, as the name implies).

To get a real picture of whether the packages installed on a server are vulnerable or not, you would need to reference not just the NVD (National Vulnerability Database) but also the security advisories that apply to your distribution.

Regularly rescanning container images allows the scanning tool to check the contents against its most up-to-date knowledge about vulnerabilities (from the NVD and other security advisory sources). A very common approach is to rescan all deployed images every 24 hours, in addition to scanning new images as they are built, as part of an automated CI/CD pipeline.

Container image scanning tools like Trivy, Clair, Anchore, and commercial options such as Aqua or JFrog help detect vulnerabilities in container images. However, the results can vary depending on factors like the data sources used (e.g., NVD vs. distribution-specific feeds), outdated vulnerability databases, unpatched but known issues, or misunderstandings about installed packages and their components. Some tools also scan for malware, setuid binaries, images running as root, or exposed secrets. Since no tool is perfect, it’s important to choose one that supports your base image, uses up-to-date feeds, and fits your specific security needs.

Incorporating vulnerability scanning into the CI/CD pipeline helps detect and fix security issues early, which is faster and more cost-effective than fixing them after deployment. Unlike traditional deployments where packages are shared across apps, containerized applications bundle their own dependencies, allowing for independent updates and easier scanning. Scanning can happen at multiple stages: on a developer’s machine, right after image build (failing the build if critical issues are found), or regularly in the image registry to catch new vulnerabilities in older images. This “shift-left” approach improves security by making it part of the development lifecycle.

Suppose you have two workloads and you don't want them to be able to interfere with each other. One approach is to isolate them so that they are unaware of each other, which at a high level is really what containers and virtual machines are doing. Another approach is to limit the actions those workloads can take so that even if one workload is somehow aware of the other, it is unable to take actions to affect that workload. Isolating an application so that it has limited access to resources is known as sandboxing.

In an ideal world, there would be a tailored profile for each application that permits precisely the set of syscalls that it needs.

docker run —security-opt seccomp=/etc/profile/custom-profile.json <IMAGE_NAME>