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.2-alpine

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
# Use a lightweight Node.js image based on Alpine Linux
2
FROM node:22.13.0-alpine
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 Node.js dependencies
11
RUN npm install
12

13
# Copy the entire project (including index.js) into the container
14
COPY . .
15

16
# Expose port 3000 for the Node.js server
17
EXPOSE 3000
18

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

I’m using node:22.13.0-alpine here 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.

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.

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@v2
15

16
      - name: Set up Docker Buildx
17
        uses: docker/setup-buildx-action@v2
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/docker@master
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/node@master
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.