Container security — how to avoid introducing a 'Trojan horse' into your cloud

When Docker first appeared, it was loved for the slogan: “Build once, run anywhere”. Developers stopped hearing the phrase “it works on my machine, but not on the server.” But along with convenience came a new threat.

A container is not just your application. It’s a whole mini-operating system (OS) with its own libraries, utilities, and system calls. And if you don’t look after that OS, you leave hackers with a huge door wide open.

The “layered cake” problem

A Docker image is built in layers. Every time you write FROM, RUN, or COPY in your Dockerfile, you add a new layer.

What’s the catch?

Most beginners start with FROM ubuntu:latest or FROM python:3.9.

• Size: the base ubuntu itself is relatively small, but once you start installing packages and dependencies, the image can easily bloat to hundreds of megabytes. And the “full” language/SDK images are often heavy.
• Junk: such images may contain (or quickly accumulate) utilities like curl, wget, a package manager, a shell, and other tools your application actually doesn’t need to run.
• Vulnerabilities: the more packages in the system, the more holes it has. An attacker doesn’t need to break your Python code — they can exploit a vulnerability in an old curl version that just “happened to be” in the container.

Line of Defense #1: move to “golden images” (Alpine and Distroless)

The first rule of container security: throw away everything you don’t need. If your application doesn’t need bash, it shouldn’t be in the container.

1) Alpine Linux

This is an ultra-lightweight Linux distribution. The base image is only about 5 MB. It contains almost nothing except the essentials.

• Pro: minimal attack surface.
• Con: it uses the musl library instead of the standard glibc, which can sometimes cause issues with certain specific binary dependencies and building some libraries.

2) Distroless (professionals’ choice)

These are images that contain absolutely nothing except your application and its dependencies. There isn’t even a command line (shell).

Why is this great? If an attacker compromises your application, it’s simply harder for them to “operate” inside the container: they won’t be able to just run ls or curl to download malicious software, because the usual tools may not be present inside the container.

Line of Defense #2: Multi-stage builds

This is a technique that lets you use heavy tools (compilers, SDKs) to build the application, but not carry them into the final image.

Bad example (all-in-one)

FROM python:3.9
COPY . /app
RUN pip install -r /app/requirements.txt  # Здесь остаются кэши и инструменты сборки
CMD ["python", "/app/main.py"]

Good example (Multi-stage)

# Этап 1: Сборка
FROM python:3.9-slim AS builder
WORKDIR /app
COPY requirements.txt .
RUN pip install --user -r requirements.txt

# Этап 2: Финальный образ (только запуск)
FROM python:3.9-slim
WORKDIR /app
# Копируем только установленные библиотеки из первого этапа
COPY --from=builder /root/.local /root/.local
COPY . .
ENV PATH=/root/.local/bin:$PATH
# Запускаем от обычного пользователя (см. ниже)
USER 1001
CMD ["python", "main.py"]

Line of Defense #3: never run as root

By default, many things in containers run as root (the superuser). This is dangerous: if an attacker gains command execution inside the container, root privileges greatly expand the range of possible attacks, and given additional conditions (misconfiguration, a privileged container, kernel vulnerabilities) the damage can be magnified.

What to do?

Always create a user with limited privileges in the Dockerfile and switch to it with the USER command.

Golden rule: an application inside a container almost never needs root privileges for normal operation.

Line of Defense #4: scan images (Trivy returns)

Remember the tool Trivy from the previous article? It can scan not only code but also ready Docker images.

How to do it

trivy image my-app:latest

Trivy will check the layers of your image and show vulnerabilities in packages/components that came with the base image and installed dependencies, and it will also suggest which versions are considered fixed.

Summary: security checklist for your containers

To make your “safe” truly reliable, follow these four items:

Conclusion of the DevSecOps cycle

We covered four powerful tools:

• Git hooks (Gitleaks): so secrets don’t leave your machine.
• SAST (Semgrep): so your code doesn’t contain logical holes.
• SCA (Trivy): so third-party libraries don’t become your problem.
• Container Security: so your infrastructure is lightweight and protected.

Security is not a destination, it’s a process. Start adopting these tools one by one, and in a month you’ll notice how your team’s development culture has improved. You’re no longer just “writing code”, you’re building reliable systems.