Master Container Security in 2025 — Best Practices & Live Demo

Container Security in 2025#

Why does any of this matter in 2025? Look at the architecture. Microservices are everywhere. A single application might be dozens or hundreds of containers, all talking to each other. That blows up your attack surface.

The reason is simple. Every container is its own little environment, with its own OS packages, libraries, and config. One misconfigured container, or one running unpatched software, is enough. That single weakness can turn into a major breach.

Supply chain attacks are climbing too. Attackers stopped going after your code alone. Now they go after whatever you depend on: base images, external libraries, third-party integrations.

Put plainly, the container image itself is a place where things can go wrong. So we have to pay attention to:

• What’s in our base image
• Our runtime environment
• The pipeline that builds and ships these containers

My goal here is to give you a practical way to shift security left. Catch issues early in development, where fixing them is cheap, and bake the checks into the work you already do every day

Key Best Practices in Container Security#

So how do you actually secure containers? Below are seven core principles. They apply to Docker, to Kubernetes, and to any containerized setup you run.

1
FROM python:3

1
FROM python:3.13-alpine

1
FROM python:3.13-alpine@sha256:sha256:2d9aefe2fef018a7eb2c13064c89c71929800fd2e5dccdbf52ea5da5bb8d929a

1
USER 1000:1000

Docker Scout for Local Image Scanning#

Enough theory. Let’s run Docker Scout for real.

Docker Scout scans your Docker images for security issues and hands you best-practice recommendations.

Before we start, make sure you have:

• Docker Desktop 4.38 or later installed
• A Docker Account, and that you’re signed in using docker login

Say we have a sample Node.js application. This is the Dockerfile.

1
# Pin the base image by digest. The tag is for humans; the digest is what Docker pulls.
2
FROM node:22-alpine@sha256:0a7108bf6c7bf5de370ffb1a3ed6be93d405b43ff159f681a8d18c0e2bc2e402
3

4
# Set the working directory inside the container
5
WORKDIR /usr/src/app
6

7
# Copy only the package files first (for efficient layer caching)
8
COPY package*.json ./
9

10
# Install exactly what the lockfile says, without dev dependencies
11
RUN npm ci --omit=dev
12

13
# Copy the application source
14
COPY . .
15

16
# Drop root: the node image ships an unprivileged "node" user
17
USER node
18

19
# Expose port 3000 for the Node.js server
20
EXPOSE 3000
21

22
# The default command to run the app
23
CMD ["node", "index.js"]

I’m using node:22-alpine, pinned by digest, because it’s smaller than node:22. Better for containers. Smaller doesn’t mean safe, though, so we still scan.

Now build the image.

1
docker build -t my-node-app:1.0.0 .

That packages the application into a Docker image named my-node-app, version 1.0.0.

Next, point Docker Scout at it.

1
docker scout cves my-node-app:1.0.0

Docker Scout analyzes the image and flags whatever looks risky.

When the scan finishes, you get a report. It lists the issues it found, their severity, and how to fix them.

When I re-ran this demo on 2026-10-07, the scan indexed 212 packages and flagged 10 of them, with no critical findings and 12 rated high. Every flagged package was part of the npm CLI that ships inside the base image, not a dependency of the app, which has none. That is a common next step: a multi-stage build whose final stage carries the runtime without the package manager.

Those issues might trace back to system libraries, base packages, or your own application dependencies. Docker Scout will often tell you to upgrade a component or apply a patch.

Why bother locally? Because you catch problems here, before the image ever hits a registry or a production cluster. Fix them now and your environment is more secure immediately.

That’s the short version of using Docker Scout to tighten up your containerized applications.

Updated on 2026-10-07: pinning now uses image digests, the secrets list no longer includes environment variables, and the demo Dockerfile runs as a non-root user and installs with npm ci. The Docker Scout demo was re-run that day with Docker Engine 29.7.2. The video shows the original 2025 version.

Snyk in GitHub Actions#

Let’s take it further and automate scanning in the pipeline with Snyk and GitHub Actions.

Before we start, make sure you:

• Sign up for a free Snyk account at snyk.io.

• Go to your Snyk account settings page, find your Access Token (Key), and copy it.

• In your GitHub repo, go to Settings → Secrets and variables → Actions, and create a new secret named SNYK_TOKEN.

Say we have a Node.js project. The goal is straightforward. A developer pushes code or opens a pull request, and Snyk scans for security issues on its own.

• Snyk will check the container image to detect risks in the base image and OS packages.
• It will also check application dependencies to find security flaws in package.json and other libraries.

1
name: Snyk Security Scan
2

3
on:
4
  push:
5
    branches: ["main"]
6
  pull_request:
7
    branches: ["main"]
8

9
jobs:
10
  security:
11
    runs-on: ubuntu-latest
12
    steps:
13
      - name: Check out the repository
14
        uses: actions/checkout@v4
15

16
      - name: Set up Docker Buildx
17
        uses: docker/setup-buildx-action@v3
18

19
      - name: Build Docker image
20
        run: docker build -t my-node-app:1.0.0 .
21

22
      - name: Snyk Container Scan
23
        uses: snyk/actions/[email protected]
24
        env:
25
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
26
        with:
27
          image: "my-node-app:1.0.0"
28
          args: "--file=Dockerfile"
29

30
      - name: Snyk Code & Dependency Scan
31
        uses: snyk/actions/[email protected]
32
        env:
33
          SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}
34
        with:
35
          args: "--file=package.json"

Wrap-Up and Final Tips#

We got through a lot:

1. Why container security matters in 2025
2. Seven core principles, from minimal images to least privilege
3. A live demo of Docker Scout for local image scanning
4. How to automate security scans using Snyk in GitHub Actions

But here’s the key takeaway: Container security isn’t just about tools or settings. It’s a mindset. Everyone on your team plays a role in keeping things secure.

A few more practical things you can do right now:

• Monitor runtime with tools like Falco or Sysdig to detect suspicious activity.
• Keep everything up to date: patching OS packages and dependencies is one of the simplest and most effective security steps.
• Enforce security policies, like blocking deployments if there are serious security issues. A single rule like this can make a big impact.
• Educate your team: security isn’t just for DevOps or engineers; it’s a shared responsibility across developers, QA, and security teams.

Thank you for reading! Don’t forget to check out the video version for additional insights and visuals.